Multi tier web architecture

It is easy to build an application these days. You can find kids developing mobile apps, websites, etc, and playing around with them. Running an application, with a business logic, and a nice, cool look, would make the application interesting. But there is the element of engineering is missing in it. And it is inevitable in case of large applications, especially distributed ones. 

When you are building an application, a large system, say for managing a company’s employees’ details or a search engine like Google, or even a student management system in a University, etc, the development is no more just the logic and the looks. There are so many more details to be considered. How many people can use the system at the same time? What is the maximum server load? How do you perform software updates while the site is already running? How to connect  the server,  the database, the user? How to handle multiple servers, shutdown one without affecting the other? What to do in case of a catastrophic failure of a system ?etc … It is found that software developers prefer component based frameworks, where a component is a separate element, which could be used for executing an abstract functionality. There are some techniques used by the web tier to handle the distributed application by dividing the whole application to multiple components, and interacting with each other using interfaces, and remote method invocations. 

Multi-tier deployment

Multi-tier deployment

Enterprise JavaBeans, or EJBs are used for deploying server side distributed components meant to perform server side operations.  It performs tasks different from the client side operations like rendering GUI’s, performing client side validations, deal directly with end user or end application. EJB’s on the other hand, perform activities like executing complex algorithms, access the database (eg: JDBC API), integrate with other systems etc. A distributed component, also called as a remote object is callable from a remote system. It means that it is not only accessable to an in-process client but also to an out-of process client that is located somewhere in the network. Some of the clients that access distributed objects are : 

  • Application clients that execute on users desktop and connect to EJB though network.
  • Web servers, that manage dynamically generated web pages. These web servers need to connect to the EJB server to get the actual business logic to generate the web page. 
  • Web services – There are no human users, but instead there is a system trying to access the distributed components via a web application. Here, the EJB’s can act as a web service client. 

My next post explains more about remote method invocations, and distributed components. 

Naming Services and JNDI

A naming service provides the facility to find an object based on a name. Whenever we need to associate name to things, we can use a naming service. It is similar to the idea of telephone directory that we use. JNDI and registries are other examples to a naming service.

During development, if is useful to have the powerful containers like Glassfish. It contains the web server, like tomcat, the application server, embedded in it. The user is not aware of the embedded features in a big container like JBOSS or glassfish.

But, during actual deployment, you want to have, DMZ – Demilitarized Zone.  We need to separate everything, like the web tier and persistence tier, and logic tier and put firewall in between so that web tier and persistence layers are separated. It gives more security and granularity. When you learn the technology, you use just one machine! But in real world scenarios, we need to split up the whole application to different modules that essentially runs on different machine.

JNDI becomes more relevant in such scenarios. It acts as the binding between different tiers by providing API’s that can connect and look up for things or data in each other.

Naming services are made with a hierarchical organisation similar to the structure of a tree. The leaves are the actual data in the structure. JNDI is also having a tree structure.

JNDI consists of a set of set of APIs that allows us to interact with directory services like LDAP, NIS etc. Some of the advantages of using JNDI are as follows:

  1. You can use multiple frameworks. All we need to change is the binding.
  2. You just have to learn one API, and hides you from protocol and implementation details.
  3. You can save java objects using JNDI
  4. You can also link different directory services using JNDI.

Directory services like JNDI and relational databases are used for storing data. But there are significant differences between the two.

  1. Directory services are hierarchical in structure and not relational.
  2. Before relational db, we had hierarchical db, which had an internal model similar to that of directory service.
  3. Most of the operation in directory services is read and we rarely perform write.
  4. As a result, dir services are more optimised for read and writing works slower in a directory service.

Now we take a look at the API part of JNDI. It has a set of APIs.

The term binding in JNDI is the association of a name with an object. To use JNDI, we need to acquire a context. A context is a set of bindings. In the hierarchical structure that I mentioned above, each leaf is a collection of pairs – <name, object>. A context can contain many leaves of the type above. JNDI names look like urls. There is a special prefix as java:. Java is a special token that represents a scheme and in this scheme there are some predefined locations. In order to acquire a context, you need to provide IP address of server, port number, the starting location within JNDI trees. It might be protected by password as well.

Some of the operations in JNDI are as follows:

  • list() – list the directory structure as in a file system
  • createSubcontext() – creates a sub context, similar to creating a folder in a directory.
  • bind() – creates an association, write a pair,name value in the current context
  • rebind() — forces binding something that is already in the tree.

 

Is OpenID secure?

OpenID, as the name suggest is an open identification solution, that helps for authentication with a single ID. There are thousands of websites that asks for authentication, and it is irritating register in all of them, creating an account for each with unique usernames and passwords. Most of the times, the requested username wont be available and users needs to come up with something new which is more likely that you forget it the next time you use the website. 

OpenID tries to solve this issue by providing one idetity provider, namely google, facebook or yahoo etc, to provide credentials for registering to a new website. The following steps describes how OpenID works in a step by step manner with an example.

Consider the three actors coming in the scenario:

  • Alice (end user)
  • Google (identity provider)
  • travelplan.com (consumer) – A website that helps you to make a travel plan.

 OpenID workflow:

  1.  Alice visits the website, travelplan.com, and finds that she needs to make an account to start using it. 
  2. Alice also finds an option to login using her gmail credentials. 
  3. She clicks on the “login using gmail” option.
  4. travelplan.com send a request to Google to verify the user Alice, and get the user identification details for Alice.
  5. Google checks for user, and prompts Alice to enter the credentials for her google account. 
  6. Here the password is not shared!!
  7. Once google identify the user, it asks for user’s authorization to allow the website, travelplan.com to use the identity details like name, emailId etc.
  8. If user clicks allow, then an authentication token is send to travelplan.com, that contains user identity details with which the user can proceed in travelplan.com 

The idea is really interesting due to the special feature that the user credentials like password is not shared with the consumer, the travelplan.com website. This makes life easier as you don’t have to remember usernames and passwords for hundreds of websites and can manages with one single identifier provider like Google or Facebook. But there are so many security issues related to this functionality of OpenID. Some of them are mentioned below:

Phishing attacks:

It is more likely that the websites could be a phishing site. Users could be redirected to malicious page containing what looks like a regular OpenID page. When user clicks on that, he/she might be redirected to another page that might look very similar to the user’s identifier’s page (eg:-Google, Facebook). If user enter the password of his Gmail account in this malicious page, he is at the risk of losing security over the n number of other websites that he had connected with OpenID and of course including the identifier site. 

Man in the middle attacks:

OpenID uses Diffie-Hellman which is subject to interception attacks. Thus the limitations and attacks possible on DH are all applicable to OpenID as well.

Denial of Service attacks:

In the steps mentioned above, we need to notice that there are two requests generated. One from user to website, another from website to the identifier provider. Thus there is a high chance for DoS attacks through OpenID if it is not handled properly in the implementation by providing delays in multiple requests coming from an IP, or other usual methods used to prevent DoS.

Session related atatcks: 

When a user used openID, there are many active authenticated sessions in his browser. So attacks like session swapping, CSRF, and XSS are possible, making your browser more vulnerable. 

Privacy breaching:

OpenID can cause a major blow to your privacy. Your OpenID provider can keep track of every single site that you log in using it. The protocol doesn’t provide a way to hide this information from the provider. 

 There are few other attacks like replay attacks, silent authentications also associated with OpenID. 

Thus, it is important to make sure that the user uses this openID, only for websites with minor information compromise, even if a security breaching happens. Also, it is more likely to have a good number of identifier providers, for eg:- a dummy email account, which could be used through OpenID to login to websites. That makes your life more secure in the cyber world. 

References:

[1] http://en.wikipedia.org/wiki/OpenID

[2]https://sites.google.com/site/openidreview/issues

[3] http://www.untrusted.ca/cache/openid.html

[4] http://wiki.openid.net/w/page/12995216/OpenID_Phishing_Brainstorm

Volatility – A python framework for forensics

I recently came across Volatility which is an advanced forensic framework implemented in Python. This is an effective tool for digital artifacts extraction from volatile memory or the RAM. Volatility can analyze raw dumps, crash dumps, hibernation files, VMware .vmem, VMware saved state and suspended files (.vmss/.vmsn), VirtualBox core dumps, LiME (Linux Memory Extractor), expert witness (EWF), and direct physical memory over Firewire

There are a set of plugins that could be used with Volatility, that makes it really special. There are some of the plugins that I found really interesting.

  1. dlldump: Extract specified dll from the memory
  2. pslist: Prints all the process by following the EPROCESS lists.
  3. psscan: Find process that were previously terminated or unlinked by a rootkit. It has the ability to list hidden/unlinked process.
  4. dlllist: Display every dll that a process calls.
  5. file_scan: List file_object in physical memory
  6. malfind: Finds hidden or injected code and injected dlls useful in analysis of malware. It also displays process, flags, memory segments etc. 
  7. svsscan: Scans for windows services
  8. API hooks: Detects API hooks in process and kernel memory.
  9. callbacks: Display instance of software listings for callbacks.
  10. iehistory: Reconstruct Internet Explorer cache/history. 

If you are interested in exploring more about Volatility, these are some good tutorials that helped me to get started:

Kernel Datastructures

Kernel data structures are those data structures that exist in physical memory and are accessible only by the kernel and its subsystems. Like other datastructures, these contain pointers, data, addresses of other data structures or addresses of routines etc. Here are some of the major kernel ds in Windows:


typedef struct _ACL
{
      UCHAR AclRevision;
      UCHAR Sbzl;
      WORD AclSize;
      WORD AceCount;
      WORD Sbz2;
} ACL, *PACL;

This data structure is associated with access control lists that manages the permissions of various users to objects like files etc.

This link mentions about a set of data structures in Windows Vista. 

Every data structure has a purpose and although some of them are used by several kernel subsystems, they are not very hard to understand. There are many research going on where a process signature is obtained by analyzing these kernel ds during the execution of a current process. This kernel based signatures are made to detect attacks like rootkits where processes are hidden from the list of processes in the system by manipulating the process header. The kernel datastructure that maintains the processes is called EPROCESS.  

If you are interested to explore more about kernel data structures, this could be a good place to begin with. 

Simple Mail Transfer Protocol

Simple Mail Transfer Protocol (SMTP) which is a mail delivery protocol.  SMTP is capable of transporting mail across various networks via a relay or gateway process accessible to both the networks. SMTP was designed as  a mail transport and delivery protocol. But it is also used as a mail submission protocol for split UA (user agents) mail reading systems and mobile environments.

Email

Working of SMTP

When an SMTP client has a message to transmit, it establishes a two- way transmission channel to an SMTP server. The responsibility of an SMTP client is to transfer mail messages to one or more SMTP servers, or report its failure to do so. The servers could be intermediate or the final destination.  An SMTP client determines the address of an appropriate host running an SMTP server by resolving a destination domain name to either an intermediate Mail eXchanger host or a final target host.

SMTP commands are generated by the SMTP client and sent to the SMTP server. SMTP replies are sent from the SMTP server to the SMTP client in response to the commands.

In short, there could be a single hop between sender and server, or multiple hops before the final destination. However,  the protocol requires that a server MUST accept responsibility for either delivering the message or properly reporting the failure to do so.

The main strength of SMTP is its simplicity.

SMTP Protocol

The SMTP – Procedures

The major procedures are as follows:

  1. Session initiation:  An SMTP session is initiated when a client opens a connection with an SMTP server and the server responds with an opening message.
  2. Client initiation: After the client receives the greeting message sent by server, client sends its identity to the server with an EHLO command.  (EHLO indicates service extensions are supported and the list of supported extensions are indicated. )
  3. Mail transaction: Starts with MAIL command that gives sender information. The receiver information is given my a series of RCPT commands. Then DATA command initiates the transfer of mail data which is terminated by “end of mail” data indicator.
  4. Forwarding mail: Servers may forward a message when they are aware of an address change. When they do so, they may provide address-updating information or may forward silently. Also, servers may reject messages as non-deliverable in case it cant deliver to the prescribed address. 
  5. Verifying mailbox names: The VRFY and EXPN commands are used for verification. A server returns a 250 code when the verification is performed successfully.
  6. Session termination: An SMTP connection is terminated when the client sends a QUIT command. The server responds with a positive reply code after which it closes the connection.

Klimax – A tool for memory and execution profiling at kernel level

Malwares are of various kinds. Privacy breaching malwares are those that attempt to steal confidential data. For eg:- Keyloggers are those malwares that eavesdrop and harvest user issued keystroke. Klimax is a behavior based detection model tailored to detecting privacy-breaching malware containing any form of keylogging activities. It is a kernel level infrastructure for memory and execution profiling. The system supports proactive and reactive detection and can be transparently deployed online on a running Windows platform.  Proactive detection is activated directly by the user. In reactive mode, the behavior analysis is automatically activated on demand whenever a candidate malicious application is recognized at runtime.

The basic idea is to analyze the correlation between the distribution of user-issued keystrokes and the resulting memory writes performed
by the malware to harvest sensitive data. Following this intuition, we inject a carefully chosen keystroke stream and observe the memory write patterns of the analyzed application. High correlation values translate to immediate detection.

Components of Klimax

The main idea is to ascertain the correlation between the stream of issued keystrokes and the memory writes a process exhibits.  In case a high correlation between those is found, the monitored process is flagged as malware with key-logging behavior.

The three components are the monitor, the injector, and the detector, of which only the first two are designed to run in kernel space. The monitor exposes a memory write performance counter to the injector, and is divided into two sub-components, the shadower and the classifier.

Detection Technique

We assume that a process is given to be analyzed for keylogging activity.

The detector instructs the monitor to intercept the memory writes of the target process. The classifier classifies the memory regions of interest. Based on the instructions of the monitor, the shadower intercept memory access. The detector establishes the nature and pattern to be used. After that, it send stream representation to the injector. The injector has now knowledge of the number of keystrokes it has to inject for each time interval. The detection process can now start: for each sample the injector issues the determined number of keystrokes to system, and notifies the monitor that the sample has been injected. The monitor then replies with the memory writes that took place.

pic

Once all the samples are injected, the injector replies to the detector with all the memory write counters.  The detector transforms the write counters into patterns, and it computes their respective correlations against the pattern previously injected. If any of the correlations is statistically significant, the process is flagged as a keystroke-harvesting malware.

Detector

Generating a pattern is the major task of the detector. Once the injection is completed, the detector  receives a detailed report of the memory writes the process performed. The report includes a set of write patterns classified per code segment and thread. Each of these patterns is further categorized basing on the written memory regions (data, stack, or heap). The detection process terminates with a correlation test against all the output patterns found. The process is then flagged as malicious when at least one of those shows a value above minimum threshold.

Injector

The injector consists of a set of samples that are injected as data similar to streams of keystrokes. It is run in kernel space to keep a limited TCB and high priority injection. Another component called the monitor, which will be discussed later, will keep track of write counters that are retrieved my injector to inject sample code. Once the whole injection is terminated, the output results are transmitted to the detector.

Monitor

A monitor consists of a shadower as well as a classifier. The shadower implements the memory protection and handles all the memory accesses. Memory access are monitored by manupulating interrupts, like page fault interrupt (0X0E) and debug interrupt (0×01). KLIMAX installs two customized interrupt handlers for both 0x0E and 0×01 interrupts by modifying the processor’s Interrupt Descriptor Table. (IDT) . These two handlers are the only entry points needed to selectively unprotect and protect the accessed memory regions. As soon as we instruct KLIMAX to monitor a process, the shadower asks the classifier which memory regions shall be protected, and hence mon-
itored. The classifier reports back the corresponding set of page table entries (PTEs). The shadower creates a shadow copy of all the PTE’s Owner bit, i.e. it sets their bit to 0. It then flushes the translation look aside buffer (TLB). This is mandatory in order to cope with the TLB caching address linear-to-physical resolutions.

The classifier is invoked in two different courses of action: when the shadower needs to determine whether a PTE shall be protected, and to update the performance counters after a write took place.