July 26, 2012

AntiDef command-line tool

Defacement attacks are not common in the world; I found in few sources an average of 6700 defacements in the past year. Hence, I would like to share a tool that I developed in order to protect against these defacement attacks. 

Defacement scenarios
1. RFI (Remote File Inclusion) attack, which enables the attacker to include remote file on the web site.
2. Exploitation of file upload vulnerability that includes directory traversal.
3. SQL injection on systems that hold the dynamic data on database, e.g. CMS (Content Management Systems).
4. CSRF on administrative actions, e.g. commit edited changed in CMS.

How AntiDef works?
AntiDef compares two directory paths - the web application and its backup foder. Then, it performs hash (MD5 - we need performance) on each file in the folders and a final hash on all hashed files. The final hashes of the source and the destination are compared. If they are different, then defacement is found. In this case, only the defaced files are moved (by default) to pre-defined "Defaced" folder and then replaced by the backup legitimate files. Then "Defaced" folder includes the malicious files, a timestamp of the defacement and a log.
AntiDef compares the two paths above every 60 seconds, but it can be defined differently.
The full manual is described by running the tool without parameters, i.e. java -jar AntiDef.jar

Open source
The tool written in java and it shared in SourceForge as a jar and as a source code. You can use it, open tickets, make it better etc. This tool has been written as "fast-and-dirty", but it works pretty good on files\folders only, meaning that database protection is not supported by this tool.
Source: https://sourceforge.net/projects/antidef/ 

July 24, 2012

Back-end database denial of service

One of the more common attacks I have stumbled upon in the course of working with information security is denial of service - an attack which causes the system to stop responding due to  exhaustion of resources and connections.
There are many types of denial of service attacks, each targeted at a different application and network level, and the new ones appear all the time; However, one such attack that I would like to share with you targets back-end databases.

How does it work?
This attack is based on the inability of the database to handle with big results in a short period of time due to running a query from the application server. For example, a malicious user or bot is able to query the web application for a search result, which will be translated to the following query in the back-end database:
SELECT id, subject, data FROM objects WHERE subject LIKE '%' + $search + '%'
The query gets the parameter $search from the application server and uses wildcards ('%') in the search result. Thus, if the database returns many rows in the result, then it might take some computing time, nevertheless it is still fast in our terms.
If a malicious user is able to query the application server many times in such way that each query will respond with many results, then the attack can be executed successfully. As a result, the database server will not be able to supply resources to send back the result since the CPU will be overloaded or the RAM will be full.

Most of the important\critical internet servers are found behind load balancers, with clusters and another application security products (Web Application Firewall, DB Firewall). If the application security products are able to perform statistics on the requests, then the attack can be restrained partially.

Query methods
1. Activate a bot to send HTTP requests to application server.
2. Malicious\Exploited web sites can include an IFRAME that posts the request.
3. User can perform multiple requests from the browser using multiple IFRAMES or JavaScripts.

July 16, 2012

MDM security testing

I would like to share my experience with mobile devices security that I have been testing lately. MDM products became one of the strategic products that organizations would like to implement, since nowadays mobile devices store business data and allow remote access to the internal resources.

Choosing a vendor
In order to choose the right vendor, the organization required to map the network architecture, the applications that should be published and the types of the devices that should comply to the security baselines and policies. For instance, the not all MDM vendors support Domino architecture.
Anyway, I suggest to perform the proof of concept stage with 2-3 vendors. As a reminder, see link to Gartner's report from the last month.
In addition, it is required to define the success criteria before performing and functional or security testing.

Security testing
This is where real fun begins. I would like to share with you the attack vectors for MDM systems.
1. White box testing
In this case, a full security architecture should be implemented since MDM should only be an additional security player. For example, the email services might be protected by smtp relay filters as TMG.

2. White\Black list
Most of the MDM products support white and black lists. However, the common way to handle mobile devices is to allow BYOD (bring your own device), hence on one hand, white listing is not a good solution from user's experience. On the other hand, black list is not a security best practice, actually it is a bad practice. In this case I would suggest to give employees a company's device and then enforce white list or do not enforce anything in case of BYOD. It is important to mention that even white list can be bypassed since mostly the mobile applications send requests to mobile websites, which can be accessed by browsers, e.g. there is no difference between entering the site http://touch.www.linkedin.com/ using mobile browser and using the official LinkedIn application.

3. Jailbreaking\Rooting
It is well known that hacking the mobile device could lead to information leakage between applications, e.g. by bypassing the sandbox. In this case, the risk is that a mobile rootkit\malware will harm or steal business information. MDM products can prohibit jailbroken devices, however, sometimes it is not working. In my case, the MDM product installed its security profiles on my iPad and then I uninstalled the MDM application and followed by jailbreaking the device. As a result, the security profiles left on my device and I could work with the published applications. In order to avoid this exposure, the MDM administrator added mitigations such as smtp relay filters and defined that profiles will be removed due to a jailbreak. My general conclusion form this case is that mostly MDM products have "bugs" that we call them "exposures".

4. Tampering
MDM agents and their following configurations mostly communicate with web services. It is pretty simple to use proxy and check what data can be tampered. In addition, don't forget that if malicious user can perform tampering, it might harm the internal resources that the device has access to them (but it depends on internal application's security).

5. Password protection
Don't worry, I don't mean lock screen password. It is important to verify if applications or profiles can be removed by the user, e.g. if iOS profiles can be removed without password requirement, then it might be a security issue.

6. Policy enforcement
It is important to validate whether the policy is enforced de facto. From my experience, there are cases that the policy is not enforced, e.g. the server can require to save a mail history of two weeks, but the mobile device will save everything. Additional examples can include device encryption, remote wipe etc. Policies can be discussed further, but not in this post.

7.  Remote support
It is important to verify that if remote support is enabled, then user should approve it. By default, from my experience, remote support notifications are not required by default.

8. Authentication issues
The most common way to authenticate users is by username and password from the Active Directory or other LDAP server (BTW - RODC did not work for me). However, I tested the ability to use an authentication certificate. My conclusion is that this type of authentication can be seriously dangerous since the certificate enrollment process requires access to the CA\RA, which mostly placed in internal networks. Therefore, MDM products perform this action on behalf of the user, which conflicts with the right certificate enrollment process since the private key should be exported, or worse, the user will get the certificate of the MDM with specific additional attribute in the certificate. Hence, it is recommended to test in detail how authentication works and even consider to add a new external mobile domain in order to protect the organization. Of course, administration considerations should be taken into account.

In conclusion
MDM implementation is not a simple process and it requires both infrastructure and application security testing. It is important to mention that MDM products are not matured enough, thus we will always find security vulnerabilities in these products.