December 16, 2012

Sqlmap plugin for BurpSuite - make it work on Windows

I was looking for a good solution to use Sqlmap in BurpSuit and found the post in bugBlog. After this great discover, I decided to check how it works on Windows.. guess what... It doesn't.

Anyway, I figured out how to make it work. The steps are:
1. Install pre-requirements: Python 2.7.x (not newer), Download latest  Burp and Sqlmap.
2. Extract sql map to folder, e.g. c:\Toolz\sqlmap
3. Download Gason (the plugin for burp) and save it in the path with the Burp.
4. Gason won't run if the Sqlmap is not binary in Windows, Therefore, download Py2Exe according to your version (Python + operating system) and install it.
5. Use Py2Exe tutorial to create binary files (store the file "setup.py" in Sqlmap folder,  and replace the name in the script from "hello.py" to "sqlmap.py").
6. Navigate to the Sqlmap folder and run the commands from the tutorial.
7. Now the Sqlmap should be ready in the folder "dist" under Sqlmap's folder. Copy all files from "dist" to the root folder of  Sqlmap, e.g from c:\Toolz\sqlmap\dist to c:\Toolz\sqlmap.
8. Run the following command from Burp's folder: java -classpath burpsuite_pro_v1.5.jar;gason-0.9.5.jar burp.StartBurp (replace your Burp\Gason versions)

Now it should work!!

Disclaimer: if you want to use the Sqlmap to test SOAP requests by using the "-r" parameter, then it is impossible in Gason\Burp. In this case (as mine), I still should use the CLI.

December 12, 2012

Connection strings encryption (in)security

One of the most common best practices to handle connection strings security is encryption. The reason is well known - to protect from connection string disclosure in case that malicious user has access to the web.config or app.config files.
In this post, I would like to explain why it is good to encrypt connection strings, but only in specific case.


DPAPI to be protected

To make a long story short, connection strings are usually encrypted during the installation using DPAPI (Data Protection API). The command line that encrypts the data is defined below:
 The result of running the command above is illustrated in the screenshot below:


DPAPI to be unprotected

DPAPI mainly protects from user that has LOCAL access to the operating system (remote access to config files is prohibited by default in IIS). In this case, since DPAPI encrypts the data using user's\machine's store, the decryption can be executed as follows:
1. If the data encrypted in the user store, then it can be decrypted using the same user credentials.
2. If the data encrypted in the machine store, then it can be decrypted in the local operating system only. 

Henceforth, the malicious user is able to execute the following command in order to decrypt the data:
See the result below:



DPAPI is good, but only in specific case

In order to protect connection strings, it is important to understand that the protection should be based on both application settings and operating system's hardening. 
If the operating system is not hardened, the following (but not limited) bypass methods can be executed:
1. Direct access to DB server.
2. Ability to run "aspnet_regiis" to decrypt the connection string.
3. 3rd party heap inspection tools can be executed in order to see the cleartext connection string in the memory (unless it overloaded somehow to SecureString value).

Thus, I recommend to harden the operating system, specially in the authorization section. In addition, I think that using white listing application control (e.g. Bit9 Pairity) can protect against the 3rd attack from above. 

In addition, I recommend to read the nuclear solution in the code.




October 29, 2012

The dark world of mobile payments

In the OWASP 2012 Israel conference I explained about retail security issues. You can see my presentation in the following link.

August 13, 2012

IBM MQ FTE Vulnerabilities

In the past month I established penetration test on IBM MQ File Transfer Edition, as result I found two main vulnerabilities: CSRF and insufficient access control to files of other users.

I would like to share the vulnerabilities that I found:
1. Insufficient access control - CVE 2012-2206 (ibm), Exploitation methods (exploit-db).
2. CSRF - CVE 2012-3294 (ibm), Exploitation methods (exploit-db).


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.

Limitations
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.


June 18, 2012

Bypass VoIP physical access controls

Lately I was performing penetration test to a physical access control, which based on VoIP. From a little research that I done, I see some resembles between physical access controls:
1. The functionality is pretty low, e.g. not supporting secure authentication.
2. No ability to use SRTP, which can protect against MiTM attacks.
3. Based on security mechanisms in the PBX.
As far as you may already understand, these endpoints are not secured by design.

What is DTMF?
In VoIP telephony systems, the tones that are dialed called DTMF (Dual-Tone Multi-Frequency). These tones are sent over the RTP (Real-Time Protocol) session, which is generated following SIP negotiation.

Privileged physical access scenario
When visitor arrives to a door, he needs to call the reception in order to allow him the access. The technical explanation behind the scenes is that the physical access control calls the reception, then if the reception picks up the phone, a SIP negotiation is performed and RTP session is started. In this session, the reception phone sends a DTMF (mostly the tone that represents the number 0) to the physical access control, which opens the door if it receives the specific DTMF.

Attack scenario #1 - Forged call
If the PBX in the organization allows calls to the physical access control, then a malicious user can call this control and send the required DTMF in order to open the door. It is not enough though, is many cases the physical access control allows automatic answering mechanism. If this mechanism is disabled, in most cases there is nothing to do. Hence, in this case I would suggest blocking calls to the physical access control using the PBX.

Attack scenario #2 - MiTM
This scenario can be accomplished in case that the VoIP network is not separated from the LAN or in case that the malicious user can connect to the VoIP VLAN on the organization. In this case, a man in the middle attack can be useful following RTP session is initiation. Note: Many physical access controls include multiple choices for dialing (stored numbers).  In this case, the call will be initiated and then the DTMF will be sent over this session, which will open the door, even though the recipient does not agree to open the door. This attack requires resources, e.g. develop filter for the EtterCap or write a short C# program using TAPI (Telephony API).

Attack scenario #3 - DoS
Most of the physical access controls are based on weak computing resources. If the malicious user has a network connection to this device, then he can perform DoS pretty easily, e.g. by sending a lot of requests (I did this with approximately 500 requests to the administration interface in few minutes). As a result, the door won't open by the physical access control, however until the reset of it, employees would have to keep the door open.

In conclusion, the physical access controls should be security tested in order to minimize the attack surface of them.

June 13, 2012

Recursive bot herder attack

DDoS attacks are known as massive attacks that are controlled by the C&C (command & control) center, A.K.A bot herder. These bot herders control thousands of bots, hence I believe that they might be a good attack target for "smarter" attackers.

What is recursive DDoS?
The perspective of infecting endpoints is well known, however I believe that the real targets that should be attacked are the bot herders. The main idea of this attack illustrated in the following image:
The main idea behind the attack is that the "recursive bot herder" infects the "bot herders" in the internet, which leads to control of many bot networks. The scenarios of infection will be explained later in this post.
Moreover, I called this attack "recursive" since not only bot herders can be controlled by the recursive bot herder, but also the recursive bot herders can be controlled by other recursive bot herders, see example below:


Scenarios
On one hand, The C&C centers are mostly distributed to many IP addresses, which most of the times are also changed. In this case, the infection of the bot herders should be accomplished in a specific period of time. On the other hand, if the IP addresses of the bot herders are not changed (too bad), the attack surface is bigger since there is more time to attack the server.

Bot herders attack vectors
There are many ways to infect bot herders, starting from the traditional ways to spread bots and ending with administrative console attacks (part of them are web-based).


In conclusion, this attack is theoretical but not as a science fiction since technically it is possible. In addition, I believe that this attack has been partially (without controlling recursively) executed already without knowing that.

May 27, 2012

LinkedIn "Invite to connect" CSRF vulnerability

I was browsing in my LinkedIn iPhone app and tried to add a friend. As far as I remember, I need to fill a form regarding my relation to the user that the request is directed to him, i.e. business, education, other (need to enter an email) etc. It is important that the receiving user will know the relation in order to ignore spam and unwanted people in his network.

I noticed that the iPhone application sometimes does not request to enter the email address of the requested contact. In most cases - it does.
In case of not requesting an email address, after clicking on "invite to connect" the invitation would be sent, see screenshot of the button below:
This is a security breach since no email is verified and no connection is selected. In this case, the policy of adding a connection is bypassed.

In case of requesting the email of the potential connection, the following screen should appear:
By sending the email, the following request is generated:
POST /li/v1/messages HTTP/1.1
Host: touch.www.linkedin.com
User-Agent: iphone3_1
Content-Length: 99
Accept: application/json
X-UDID: REMOVED-BY-NIRVALTMAN
X-System-Version: 5.0.1
X-System-Name: iPhone OS
X-Device-Model: iPhone
Cookie: lim_auth=REPLACED_BY_NIRVALTMAN
X-LI-Track: {"clientVersion":"4.0.3","sessionId":"REMOVED-BY-NIRVALTMAN","carrier":"orange Israel","osVersion":"5.0.1","locale":"he_IL","osName":"iPhone OS","language":"en","model":"iphone3_1"}
X-App-Version: 4.0.3
X-User-Language: en
X-User-Locale: he_IL
Content-Type: application/x-www-form-urlencoded
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Pragma: no-cache
Connection: keep-alive
Proxy-Connection: keep-alive

type=invt&subject=Join%20my%20network%20on%20LinkedIn&to=AnyM@il.com&body=Any%20Message
A malicious user can create an HTML page to post this request and then get the connection request directly to his mail. The victim would not know about the invitation that he sent to the malicious user. In this case, the vulnerability in the request is CSRF (Cross Site Request Forgery). In order to illustrate the attack, I sent the email by using CSRF attack from my personal account to the test account, the result can be understood from the screenshot below:

In conclusion, malicious user can create a large network without the knowledge of his "new" connections (unless they review their updates recently).

Note: This notice has sent to linkedin on December 2012, I really hope that they fixed it. After all, I've been waiting for 6 months for this fix.

February 13, 2012

iPhone 4S Siri security breach

While I was playing with my new iPhone 4S I tried to bypass Apple's built-in security. The following lines was sent to apples security email:
General
While I was working with Siri on my iPhone 4S, I found a security breach that can compromise the privacy of users if their iPhone has been stolen\taken by unauthorized person.

Requirements
iPhone 4S with passcode lock enabled.
Siri is enabled.
Siri is allowed even of the lock-screen is locked (default setting).

Issue
If Siri is enabled in the lock screen settings, an unauthorized user can perform multiple actions without unlocking the iPhone:
1. Send email\SMS to someone within the contacts.
2. Disclose contacts by asking "find people named [any_strange_name]".

Risk description
An unauthorized user can use the iPhone to steal the contact list by using multi-verbs while asking to find people. In addition, the unauthorized user can produce spoofing attack by sending rogue emails to people in the contact list.

Recommendation
It is well known that any user can set a full restriction for Siri or disable it from appearing in the lock screen, however the usability is important for iPhone users. Therefore I recommend to add a menu that can set specific restrictions for email\SMS sendings and looking for people.

See the response below:
Thank you for contacting the Apple Product Security team. We take every report of a potential security issue very seriously. This message is being sent to you by a security analyst who has reviewed your note.
After examining your report we do not see any actual security implications. Users can disable Siri access at the lock screen.
We are tracking your report as an enhancement request. If you have any questions or concerns please feel free to let us know.

In conclusion, Apple's security team recommend us to disable Siri at the lock screen if we want to be protected. From my personal perspective, I think that no one would disable Siri from the lock screen since that's the all point of Siri.
Think about it...