RSS
 

Elliptic Curve Cryptography: A Case for Mobile Encryption

28 Feb

It is needless to start this article explaining about the rise of mobile devices in the last few years. We all know about how smart phones have swept the world. But with mobiles you always look for concepts or solutions which are computationally cheap. For example, Android OS uses a dex compiler to convert the Java Byte code to .dex files before compiling them. Why? Because dex files are optimized code for low memory and low processing systems. Similarly when it comes to encryption on mobile devices we look for solutions which are computationally cheap and yet secure. ECC (Elliptic Curve Cryptography) provides exactly the same. This article explains about the why and how ECC is different from the other encryptions.

What is the need for an alternative encryption scheme when you have RSA?

Mobile phones have 2 main limitations:

  1. Computational limitations – Because the processors used on mobile devices are less capable compared to the ones used on a desktop system. Although there are a few devices which use dual core/quad core, most of the mobiles in general are not equipped with these kinds of CPU’s. 2.
  2. Battery Life – Mobile devices run throughout the day and battery consumption is one of the important aspects for the success of a device. The more computations a device has to perform the more battery life is consumed.

Consider a normal user who visits a banking site on his mobile device to transfer money to his friend. A low processing powered mobile device would struggle with the 1024 bit computations of RSA. With major financial institutions, the smallest key size allowed for RSA is 1024 bits. This activity not only takes time to complete but also eats into the battery life of the device.

What is ECC?

Elliptical curve cryptography (ECC) is a public key encryption technique based on elliptic curve theory that can be used to create faster, smaller, and more efficient cryptographic keys. So let us analyze the ECC algorithm by considering 2 factors – Security & Efficiency.

Security:

When we talk about public key encryption algorithms, the first things that come to mind are RSA and Diffie-Hellman. Both these algorithms use 1024 bit keys for major transactions. But it’s important here to note that NIST (National Institute for Standards and Technology) has recommended 1024 bit parameters only till the year 2010. The RSA algorithm is into its 40th birthday and probably regarded as the standard public key exchange on the Internet. After 2010, NIST believes that the existing systems be upgraded to a different set up to provide more security (although we no longer believe NSA or NIST :)). One option is to simply increase the key size used with these algorithms. However you are not quite sure as to what is the safe key size. Other option is to switch to a different set up which is more secure. ECC here comes to rescue. ECC generates keys through the properties of the elliptic curve equation instead of the traditional method of generation as the product of very large prime numbers.

RSA’s security is based on the principle that factoring is slow and hard i.e. it is difficult to factor a large integer composed of two or more large prime factors. With the improvements in technology, the gap between factoring and multiplying is slowly reducing. In the coming years, certainly this is bound to break. Switching to a larger key size is one option but it would only give the breathing space for a few more years.

An elliptic curve is represented as a looping line intersecting two axes. ECC is based on properties of a particular type of equation created from the mathematical group derived from points where the line intersects the axes. Multiplying a point on the curve by a number will produce another point on the curve, but it is very difficult to find what number was used, even if you know the original point and the result. For elliptic-curve-based protocols, it is assumed that finding the discrete logarithm of a random elliptic curve element with respect to a publicly known base point is infeasible –this is called as the elliptic curve discrete logarithm problem or ECDLP. Equations based on elliptic curves have a characteristic that is very valuable for cryptography purposes: they are relatively easy to perform, and extremely difficult to reverse. Despite almost three decades of research, mathematicians still haven’t found an algorithm to solve this problem. To state in simple words, for numbers of the same size, solving elliptic curve discrete logarithms is significantly very much harder than factoring. ECC was developed by Certicom, a mobile e-business security provider. RSA has been developing its own version of ECC. Other manufacturers, including Motorola, Cylink, Siemens, and VeriFone etc have already included support for ECC in their products.

The curious case of Angela Merkel’s phone tapping :)

A few months back, the news that German Chancellor Angela Merkel’s phone was tapped by the US government has created quite a scene. Amid this controversy there was also news that Merkel used 2 phones – one BlackBerry (encrypted) and the other Nokia (not encrypted). In September, new government phones which were manufactured by the Canadian company BlackBerry were delivered to all government officials (including Merkel) after being updated by the German company Secusmart. They contain a special encryption card that scrambles speech and data before transmitting it. So this Secusmart card used the Elliptic curve cryptography to encrypt and decrypt the mobile speech. And just because it is encrypted doesn’t mean its safe. It all depends upon how difficult it is to crack the key.

Efficiency: 

In terms of efficiency, ECC wins the race by large margin. The below table explains it all. The following table gives the key sizes recommended by the National Institute of Standards and Technology to protect keys used in conventional encryption algorithms like the (DES) and (AES) together with the key sizes for RSA, Diffie-Hellman and elliptic curves that are needed to provide equivalent security.

crypto key sizes

For instance to protect 128-bit AES keys using RSA or Diffie-Hellman you need to use 3072-bit parameters. The equivalent key size for elliptic curves is only 256 bits. Also, as the symmetric key size increases, the corresponding RSA/Diffie Hellman key size increases at a much higher rate compared to ECC key size. This is particularly a strong case for moving towards ECC on low powered environments like mobile devices, wireless devices, smart cards etc.

Real word ECC – is it safe?

The reports leaked by Edward Snowden suggested that Dual Elliptic Curve Deterministic Random Bit Generation (or Dual_EC_DRBG) had been included as a NIST national standard due to the influence of NSA, which had included a deliberate weakness in the algorithm and the recommended elliptic curve. RSA Security then issued an advisory recommending that its customers discontinue using any software based on Dual_EC_DRBG. Wikipedia mentions “Implementations which used Dual_EC_DRBG would usually have gotten it via a library. At least RSA Security (BSAFE library), OpenSSL, Microsoft, and Cisco has libraries which included Dual_EC_DRBG, but only BSAFE used it by default. According to the Reuters article which revealed the secret $10 million deal between RSA Security and NSA, RSA Security’s BSAFE was most important distributor of the backdoored algorithm. There was a flaw in OpenSSL’s implementation of Dual_EC_DRBG that made it non-working outside test mode, from which OpenSSL’s Steve Marquess concludes that nobody used OpenSSL’s Dual_EC_DRBG implementation”. All these point out the dark side of the NSA :)

However there are several different standards which propose ways of selecting curves for use in elliptic-curve cryptography (ECC). Each of these standards tries to make sure that the elliptic-curve discrete-logarithm problem (ECDLP – the problem of finding an ECC user’s secret key, given the user’s public key) is difficult. Below are some of the standards in use:

  • ANSI X9.62
  • IEEE P136
  • SEC 2
  • NIST FIPS 186-2
  • ANSI X9.63
  • Brainpool
  • NSA Suite B
  • ANSSI FRP256V1

Hence selecting the right curve and parameters is also important to ensure real world ECC security. More information can be found at the link: http://safecurves.cr.yp.to/.

To summarize,

-> ECC employs a relatively short encryption key. It is faster and requires less computing power than other first-generation encryption public key algorithms such as RSA, Diffie-Hellman. For example, a 160-bit ECC encryption key provides the same security as a 1024-bit RSA encryption key and can be up to 15 times faster, depending on the platform on which it is implemented.

-> Extremely helpful for use on low memory and low computing environments such as mobile devices, wireless devices etc.

-> Elliptic curves are supported by all modern browsers, and most certification authorities offer elliptic curve certificates.

Elliptic curve cryptography has proven to be a promising solution for the implementation of public-key cryptosystems. As widespread use of the internet and mobile devices continues to increase, transferring data the information with less computation and in a more secure manner has been the primary focus. With smaller key sizes and lower processing requirements, elliptic curve cryptography serves the purpose on mobile devices.

 
No Comments

Posted by rohit

 

Advanced Exploitation using XSS-SHELL

29 Jan

Before getting into XSS Shell, let us recollect few basics of XSS (Cross Site Scripting). XSS is one of the most common vulnerability that exists in many of the web applications today. XSS is a technique through which an attacker tries to compromise the web application by executing a malicious script. The attacker does this by breaking the Same-Origin policy of the web application. Same–Origin policy defines that the script which is coming from the foreign site or the script that doesn’t belongs to the same domain (i.e document.domain) should not be processed by the application.

Once if an attacker finds XSS in a web application, he can perform different kinds of attacks.
- Stealing Credentials
- Stealing Session tokens
- Defacing the Website
- Causing DOS
- Installing Key loggers and many more….

Cross-Site-Scripting exists in three different forms:
- Reflected
- Stored
- DOM Based

Reflected XSS:
This kind of vulnerability exists in the application that uses dynamic pages to display the content to the user. Normally these applications take the message into a parameter and renders back to the users.

For Example, consider the URL: http://www.[sample].com/error.html?value=learn+hacking

This shows the message learn hacking in the response of the application. Which means the application is extracting the message from the URL, processing it and displaying it to the user. So the URL processes user supplied data and inserts it into the server’s response. If there is no proper sanitization then the application is vulnerable to Reflected XSS.

The URL can be crafted as: http://www.[sample].com/error.html?value=<script>alert(1)</script>

When you click on the above URL it executes the script and pops up an alert box.

Stored XSS:
This type of vulnerability exist in applications which takes input from the user, store it and later displays to other users. For example, consider Facebook application which allows commenting on any picture or status update and then displays to all other users. If the application doesn’t sanitize the input properly then an attacker can write a script in the comment area, so that the users who visits or views particular page or post will be effected.

So Stored XSS consists of two things to do. Initially the attacker enters the malicious script into the application. Secondly the user visits the crafted page and the script is executed in the back-end without the knowledge of the user.

DOM Based XSS:
DOM stands for Document Object Model. It is quite different from the other two attacks described earlier. In DOM Based XSS when the user click on the crafted URL, server response doesn’t consist of attacker’s script. Instead the browser executes the malicious script while processing the response. This is because the Document Object Model of the browser has a capability to determine the URL used to load the current page. Script issued by the application may extract the data from the URL and process it. Then it uploads the content of the page dynamically depending upon the script executed through the URL.

XSS Shell

XSS Shell is a powerful tool developed in ASP .NET which runs as a XSS backdoor between the attacker and the victim. With XSS, attacker has only one shot to execute any kind of attack on victim. Once the victim navigates from the malicious page the attacker’s interaction or the communication with the victim ends, whereas using XSS Shell help the attacker to open an interactive channel with the victim and communicate with him by sending its commands. Here, even if the victim navigates from the vulnerable/malicious page the attacker can continue his communication as the XSS Shell re-generates the page.

The interactive shell or the communication channel which was established by the attacker with the victim is called “XSS Tunnel”. XSS Tunnel is used for tunneling the HTTP Traffic between two machines opened by XSS. Technically it is developed using AJAX and that can send requests and receive responds and has an ability to talk cross-domain.

Attack Process:
1. Setup XSS Shell Server.
2. Configure XSS Tunnel to use XSS Shell Server.
3. Inject malicious script into a vulnerable Website.
4. Launch XSS Tunnel and wait for victim.
5. Configure the browser or tool to use XSS Tunnel.
6. When victim visits the vulnerable page, start using XSS Tunnel.

How XSS Shell works:

xss shell process 1

As shown in the figure, initially attacker establishes a connection with the XSS Shell and injects malicious script into the web Application using Stored or Reflected XSS. Once the victim clicks or visits the vulnerable application with the malicious script a request will be sent to the XSS Shell Server. On the basis of the request server establishes a channel to interact with the victim.

xss shell process 2

Once a channel has been created between the victim and XSS Shell Server, attacker can control the communication through XSS Shell Admin Interface. XSS Shell Admin Interface is nothing but a GUI environment which provides definite set of commands which the attacker can execute to perform certain actions.

On executing a command, necessary function or the script will be called at XSS Shell Server level and it is sent to the victim. The script will be processed and executed at victim browser and it sends corresponding results to the XSS Shell Server. XSS Shell Server stores the results in MS-Access database which is normally used by it to store the data. Attacker can extract the results from the database and look at it whenever he wants.

Some of the commands that XSS Interface provides are:
- Get Cookie
- Get Current Page
- Get Clipboard
- Get Key-logger data
- Crash browser

One more advantage of using XSS Shell is, it is an Open Source and quite easy to implement new commands.

Requirements:
- An IIS Server where you can host .asp files.
- Microsoft Access database (.mdb)
- A Website which is vulnerable to XSS
- A vulnerable site to perform attack

Setting up the environment:
- Download the XSSShell from: http://labs.portcullis.co.uk/download/xssshell-xsstunnell.zip
- Configure IIS to host the site
- Installation
- Configure XSS Shell

Configuring IIS:
In-order to configure IIS in windows 7 or above, follow the steps given below:

1. Click on Start Menu and goto Control Panel.
2. Click Programs and then click on Turn windows features on or off.
3. A new Windows Features dialog box will appear. Expand Internet Information Services.
4. Select default features that has to be installed with IIS.
5. You can expand the additional categories and install any additional features if required.
6. It is recommended to install additional features if you want to use IIS for evaluation purpose.

Now IIS has been configured in the machine and can be accessed using http://localhost/

IIS 7 default page

Installation:
XSS Shell uses ASP .NET and MS-Access database. So just make sure that you have installed .NET framework and MS-Access db on your machine.

Configuring XSS Shell Admin Interface:
- After downloading the XSSShell.zip file, extract the file and you can see two folders – XSSshell & XSSTunnel.
- XSSshell is admin interface and you need to configure it in your machine. Copy XSSshell folder to your web server.

xss shell folder

- You can see a sub-folder named db in the XSSShell folder as shown in the above image. Copy that to a secure place because XSSshell stores complete data in that db, whatever it is either victim’s session cookies or any other attacked data that belongs to victim.
- After moving the db folder to a secure place, configure the path in db.asp file under XSSshell/admin folder. So that the interface can know where the db is and interact with it.

xssshell source 1

- Edit the path to the location such that it should point to the place where db folder is present in your machine.xssshell source 2The above image, shows default password to access shell.mdb file. You can edit to whatever you want.
- Now you can access admin interface by using the localhost url or the domain name that you have given. Ex: http://localhost/xssshell (or) http://yourhostname.com/xssshell
- By default it uses port 80, but if you change the port number while configure the domain you need to access the site by embedding the port number.

Configuring XSS Shell:
- Open xssshell.asp from XSSshell folder.
- Configure the server path. i.e to the place where XSSshell folder is located.

xssshell source 3

- Above figure shows the configuration of server path in xssshell.asp file. Edit he parameter SERVER to the place to the location of XSSshell folder in your machine.
- Now access your admin interface from the browser, which would contain three sections.

xss shell admin interface

Commands:
As mentioned earlier XSSshell has pre-defined commands which make attacker’s life easy to perform any attack on the victim. Commands section contains all the commands supported by the shell. As it is a open source you can edit it and add your own functionalities there.

Victims:
Victims section shows the list of victims.

Logs:
Logs show the list of actions performed on the victims.

XSS Tunnel:

XSS Tunnel is just like a proxy tool which runs on attacker machine and captures traffic through xss channel on XSSshell server. In-order to do this XSS Tunnel should be able to understand where XSSshell server is running. We can configure the XSSshell information (i.e where it is running) in XSS Tunnel from Options tab. Enter the server address and password. Then just to make sure it is working fine click on Test Server. You get a success message if the configuration is proper.

xss tunnel - connection success

Once done with configuration, click on Start XSS Tunnel on the top of the window.  Then you can see all the actions performed by the victim from XSS Tunnel’s Dashboard. The below image shows all the pages visited by the victim and actions performed.

xss tunnel - traffic capture

Conclusion:

XSSshell is an interface or a tool which opens a gateway to the attacker through which he can perform various attacks on the victim without losing the connection once established.

References:

http://labs.portcullis.co.uk/tools/xss-shell/
http://www.slideshare.net/clubhack/xss-shell-by-vandan-joshi

 
No Comments

Posted by kamalb

 

SSL Attacks

31 Dec

In the last few years, we have witnessed a wide range of attacks on the SSL/TLS mechanism. In this article, we will try to cover various attacks that were prominent in the field of cryptography. Transport layer security (TLS) ensures integrity of data transmitted between two parties (server and client) and also provides strong authentication for both parties. The attacks launched in the last few years have exploited various features in the TLS mechanism. We are going to discuss these attacks one by one.

Browser Exploit Against SSL/TLS Attack (BEAST)

This attack was revealed at the Ekoparty Security Conference in 2011. BEAST is based on a type of cryptographic attack called the “chosen plain text attack”. Before I jump into explaining the details of this attack, let us take a look at some of the basic concepts to be understood.

Background

There are two types of encryption schemes:
1. Symmetric key encryption: Encryption and decryption keys are the same.
2. Asymmetric key encryption: Encryption and decryption keys are not the same.

Symmetric-key encryption can use either stream ciphers or block ciphers. A stream cipher encrypts one bit at a time, while a block cipher encrypts plaintext in chunks. Let’s talk about block cipher. How is a message encrypted using block cipher? You don’t use the block cipher on the message directly but instead you first need to choose the “mode of operation” CBC (cipher block chaining) is one such mode used by the block ciphers.

In CBC mode, to make each message unique, an initialization vector (IV) is used in the first block. An IV is a random string that is XORed with the plaintext message prior to encryption. Each block of plaintext is XORed with the previous cipher text block before being encrypted. In other words, each cipher text block depends on all plaintext blocks processed up to that point as shown in the figure below. It’s important to note that here IV is not a secret; it only adds randomness to the output. IV is sent along with the message in clear text format. With this background information, let us know focus on how the BEAST attack is accomplished.

cbc mode

How Is the Attack Accomplished?

It was noticed that TLS 1.0, when dealing with multiple packets, allows the following packets to use an IV that is the last cipher text block of the previous packet. In other words, an attacker who can see the encrypted traffic can note the IV used for session cookie (Why? Because the cookie’s location is predictable). Simply put, an active attacker will be able to gather the IVs for each record just by sniffing the network. So if the attacker can “guess” a plaintext message, he can make a guess at the session cookie and see if the cipher text matches. [Note that, since this is a MITM attack, the attacker can mix his traffic with the victim traffic to see the results].

Practical Example

Now let us consider the message: JSESSIONID=Gxs36NepewqeMI763Hej31pkl.

This is a plaintext and will have to be XORed with the IV (which is cipher text of the previous block). The attacker has this IV value in his hands. Now if he can “predict” this plaintext value and XOR with IV, he can check whether it corresponds to the cipher text value. Understandably, it’s not easy to predict such a random value, but he can guess it a single character at a time. For example “JSESSIONID=G” can be guessed by trying different characters. Once the first character is recovered, he can shift the attack to the next character. This way he can guess one character at a time and accomplish the attack. This attack is not so straightforward and has some limitations:

  1. The attacker has to be in the same network and play a MITM attack.
  2. The attacker has to modify the traffic to see if the results match; as a result, multiple requests have to be sent in this process.
  3. The attacker can guess only one block at a time.

Solution

This is a vulnerability in block ciphers that use the CBC mode of operation. It was identified in TLS 1.0. However it was addressed in TLS 1.1 and TLS 1.2 by the use of “explicit IVs” for each block. Hence, TLS 1.1 and TLS 1.2 are not exposed to this attack. Some of the browsers have attempted to implement a solution to address the vulnerability while still remaining compatible with the SSL 3.0/TLS 1.0 protocol. Apple’s Safari, even though it has released a mitigation, has chosen to keep it disabled by default.

Google: Update to Chrome 16 or later.
Microsoft: Apply the patch MS12-006.
Mozilla: Update to Firefox 10 or later.

SSL Renegotiation Attack

A vulnerability was discovered in the SSL renegotiation procedure that allows an attacker to inject plaintext into the victim’s requests. For instance, it allows an attacker who can hijack an HTTPS connection to add their own requests to the conversation the client has with the web server. Note that the attacker cannot decrypt the client-server communication.

Background

SSL renegotiation is helpful when the routine SSL session is already established and the client authentication has to take place. For example, say you are browsing an online shopping site which uses SSL, i.e., HTTPS. Initially, you browse through the site anonymously, add items to the cart, etc. But when you decide to purchase you will be asked to log in to the site, so now the SSL connection needs to be adjusted to allow the authentication. Whatever information is gathered prior to this authentication (e.g., items added to the cart) has to be maintained even after the authentication. So the new SSL session that has to be established uses the already existing connection. Note that renegotiation can be requested either by the client or by the server at any time. For the client to request renegotiation the client sends a “Client Hello” message in the already-established encrypted channel and the server responds with a “Server Hello” and then the negotiation follows the normal handshake process. The server can initiate the renegotiation by sending the client a “Hello Request” message. When the client receives the request, the client sends the “Client Hello” message and the handshake process takes place. This explains the basic SSL renegotiation process.

How Is the Attack Accomplished?

Using the renegotiation attack, an attacker can inject commands into an HTTPS session, downgrade a HTTPS connection to a HTTP connection, inject custom responses, perform denial of service, etc. That explains to some extent how serious the problem is. It is easier to understand how the attack is accomplished through the following example.

Practical Example

The action corresponding to each of the numbers present in the below figure are explained in the order below:

SSL renegotiation attack

  1. Assume that a client wants to connect to a online banking site. He initiates the routine TLS handshake process
  2. The client blocks the request and holds the packets.
  3. The attacker initiates a new session and completes a full TLS handshake.
  4. The attacker sends a GET request (asking to send money to his account) to the bank application.
  5. Server asks for renegotiation.
  6. The TLS handshake initiated at step 1 and blocked by the attacker will now be forwarded to the server, which a new TLS handshake over the previously established encrypted TLS session 2. So the client now is authenticated and has a valid cookie.
  7. Due to this renegotiation, the server now assumes that the previously sent request in step 4 was actually sent by the client. Hence the request which goes to the server is as follows; it will be interpreted by the server as a legitimate request and then executed.

    GET /bank/sendmoney.asp?acct=attacker&amount=100000
    Ignore the rest: GET /ebanking
    Cookie: validcookie 

Solution

One way to fix the renegotiation vulnerability for SSLv3 is to completely disable renegotiation on the server side. As a permanent fix for the vulnerability, a renegotiation indication extension was proposed for TLS that will require the client and server to include and verify information about previous handshakes in any renegotiation handshakes.

Compression Ratio Info-leak Made Easy Attack (CRIME)

This is a side-channel attack on SSL/TLS that can be used to predict sensitive information, such as the session tokens, etc. This is done based on the compressed size of the requests. This attack is known to work against SSL compression and SPDY, which use deflate/gzip data compression techniques. SPDY is not widely used, but SSL compression is one technique which is very much in use.

Background 

Before we see the details of the actual attack, let me explain a few things about “compression.” Web pages are generally compressed before the responses are sent out (this is called HTTP compression), primarily to make efficient use of available bandwidth and to provide greater transmission speeds. With compressed data, we can send the same amount of data to the destination but using fewer bits. The browser usually tells the server (through “accept-encoding” header), what compression methods it supports and the server accordingly compresses the content and sends it across. If the browser does not support any compression, then the response is not compressed. The most commonly used compression algorithms are gzip and deflate.

Accept-Encoding: gzip, deflate

When the content arrives, it is uncompressed by the browser and processed. So, basically with SSL-enabled web sites, the content is first compressed, then encrypted and sent. But you can determine the length of this compressed content even when it’s wrapped by SSL.

How Is the Attack Accomplished?

A CRIME attack is based on observing how the compressed length changes for different input values. Initially the attacker observes the size of cipher text sent by the browser and then makes multiple requests to the target website to observe the compressed response sizes. The attack primarily works by taking leverage of the “compressed size” of the text when there are repetitive terms. The attack can be best understood by following the below example, which demonstrates how an attacker can exploit it in real time.

Practical Example

Consider the below POST request made by a valid user.

Request:
POST / HTTP /1.1
Host: testing.com
User -Agent: Mozilla /5.0 (Windows NT 6.1; WOW64; rv :14.0) Gecko /20100101 Firefox /14.0.1
Cookie: secretcookie =5db98j64wa23pq1cb4cb0031ln481nx1
Accept -Language: en -US ,en;

<—–body——–>

As mentioned earlier, this content is first compressed and then encrypted and sent. But note that the size of this encrypted piece can still be found out just by sniffing the network traffic. Now the attacker’s target is to get the value of “secretcookie.” The attacker now can make the victim click on a link and, using JavaScript, he can trigger the below request.

Request triggered by the attacker:

POST /secretcookie =0 HTTP /1.1
Host: testing.com
User -Agent: Mozilla /5.0 (Windows NT 6.1; WOW64; rv :14.0) Gecko /20100101 Firefox /14.0.1
Cookie: secretcookie =5db98j64wa23pq1cb4cb0031ln481nx1
Accept -Language: en -US ,en;

<—–body——–>

In the above request, “secretcookie =0″ is the attacker-controlled input. When repetitive terms are encountered during the compression, instead of displaying it a second time the compressor says “This text is found 67 characters ago.” So this reduces the overall size of the compressed output. In the above request, since the word “secretcookie” is repeated, the compression is done accordingly by taking note of it. Now the attacker sends the below POST requests and observes the compressed sizes.

POST /secretcookie =0….
POST /secretcookie =1…
POST /secretcookie =2…
POST /secretcookie =3…
POST /secretcookie =4…
POST /secretcookie =5…

Now can you guess which POST request would be best compressed, i.e., which POST request would have the smallest compressed size? The one with “secretcookie =5″ would compress the best. This is because it has more repetitive characters. In other words, “secretcookie =5″ is repeated twice and hence the compressed size is less. Thus the attacker can confirm that 5 is the first character of the secretcookie. Going ahead with this logic, he can brute-force the other characters as well and extract the entire cookie value.

Solution

CRIME can be remediated by preventing the use of compression at the server end. It can also be prevented at the client end by disabling the compression of HTTPS requests. This is because, in TLS 1.2, the client sends the server a list of compression algorithms that are supported by it and the server picks one of them. If the client sends no compression algorithm, then the data cannot be compressed.

Timing Info-leak Made Easy Attack

In spite of being a very interesting attack, CRIME majorly suffers from two drawbacks:

  1. The attacker must be the man in the middle (to be able to read the messages) and he must also control the plaintext (which is sent as input to the application).
  2. CRIME was very soon mitigated by disabling the TLS compression.

The TIME attack overcomes both of these problems. So this attack doesn’t need an attacker to sniff the network. Instead of focusing on the HTTP request, it focuses on the HTTPS responses. To explain this attack in simple terms, all an attacker needs to do is redirect a user to a malicious website that will run some JavaScript to get the encrypted secret data.

Background

The basic concept here is that, in order to find out if there is difference in the length of two messages, we can observer the time it takes to send these messages across the network. The larger the difference, the more time it’s going to take.

How Is the Attack Accomplished?

The basic goal of the attacker is to force the length of compressed data to overflow into an additional TCP packet. The attacker then pads the remaining data. When the maximum size is crossed, any additional packet created (due to wrong guess), introduces an additional full round trip with a significant delay. Consider a simple user input (say “secret = data”). Assume that the value is reflected in the response along with the “secret.” In other words, whatever the user inputs is reflected in the response. Let us say in the first request, the user sends “secret = anything” and receives a response with a size of 1024 bytes. If the user input is “secret=a” in the second request, the response size will be less and hence it will take less time to reach than the first request. Likewise, it is possible to predict the every character in every position of our payload by observing the response times (to be precise by observing the “shortest response times”). This attack is little difficult to comprehend and so I have mentioned a video link here which could give you a better insight for the folks who are interested.

Black hat video link: http://www.youtube.com/watch?v=rTIpFfTp3-w&noredirect=1

Solution

Including CSRF, CAPTCHA tokens in the request could avoid the multiple requests that an attacker makes using the JavaScript. Adding random timing delays to the decryption for any timing attack can be reasonable to disrupt this attack, but it may not be completely helpful. The application should take care of the reflection of user input in the response.

 
No Comments

Posted by rohit

 

BREACH Attack Explained

30 Nov

Back in 2012, when Juliano Rizzo and Thai Duong announced the CRIME attack, TLS / SSL Compression attack against HTTPS, the ability to recover selected parts of the traffic through side channel attacks has been proved. This attack was mitigated by disabling the TLS / SSL level compression by most of the browsers. This year at Black Hat, a new attack called BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) was announced which commanded the attention of entire industry. This presentation which came up with the title “SSL Gone in 30 seconds” is something that is not properly understood and hence there seems to be some confusion about how to mitigate this. So I felt this article would give some detailed insight into how notorious the attack is, how it works, how practical it is and what needs to be done to mitigate it. So let’s proceed and have a look at the same.

BREACH Attack:

Unlike the previously known attacks such as BEAST, LUCKY etc, BREACH is not an attack against TLS. BREACH is basically an attack against the HTTP. If you are familiar with the famous Oracle Padding attack, BREACH is somewhat easy to understand. A BREACH attack can extract login tokens, email addresses or other sensitive information from TLS encrypted web traffic in as little as 30 seconds (depending on the number of bytes to be extracted). The attacker just needs to trick the victim to visit a malicious link for executing the attack. Before going into the details, let me explain a little bit more about the basic things to know. Web pages are generally compressed before the responses are sent out, which is called HTTP Compression, primarily to make better use of available bandwidth and to provide greater transmission speeds. Browser usually tells the server (through ‘Accept-Encoding’ header), what compression methods it supports and server accordingly compresses the content and sends it across. If the browser does not support any compression then the response is not compressed. The most commonly used compression algorithms are gzip and deflate.

Accept-Encoding: gzip, deflate

When the content arrives, it is uncompressed by the browser and processed. So basically with SSL enabled web sites, the content is first compressed, then encrypted and sent. But you can determine the length of this compressed content even when it’s wrapped by SSL.

How it works?

The attack primarily works by taking leverage of the ‘compressed size’ of the text when there are repetitive terms. So here is a small example which explains how deflate takes advantage of repetitive terms to reduce the compressed size of the response.

1. Consider the below search page which is present after logging into this site:

http://www.ghadiwala.com/catalogsearch/result/?q=

Breach example - search page

2. Observe that the text highlighted in red box is the username. Now enter any text (say ‘random’) and click search.

URL: http://www.ghadiwala.com/catalogsearch/result/?q=random

Breach example - search page2

3. So you can control the response through the input parameter in the URL. Now imagine what if the search term is ‘Pentesting’ (which is the username in this case).

URL:  http://www.ghadiwala.com/catalogsearch/result/?q=Pentesting

Breach example - search page3

Now when deflate algorithm is compressing the above response, it finds that the term ‘Pentesting’ is repeated more than once in the response. So instead of displaying it second time the compressor says ‘this text is found 101 characters ago’. So this reduces the size of the compressed output. In other words, by controlling the input search parameter you can guess the username. How? The compressed size would be least when the search parameter matches the username. This concept is the base for the BREACH attack.

Practical Attack:

Now let us see how an attacker would practically exploit this issue and steal any sensitive information. Consider the below site and assume a legitimate user has just signed in.

Breach Sample search page

[Before signing in to the application]

Breach Sample search after login

[Search page which is accessible after logging in]

As shown in the above figure, also assume that there is some sensitive data which is present in the Search page for example let card number be one such sensitive data in the application. When the user searches for something (say ‘test’) below is the message displayed.

Breach Sample search page2

Now an attacker, using all the social engineering techniques, could lure this currently signed in user to click on a link. The link would be simple html page that has a JavaScript in it which will request searches continuously for search terms ‘100-1000’. For example the JavaScript would request the below URL’s.

http://localhost/demo/Search?p=100

http://localhost/demo/Search?p=101

………

http://localhost/demo/Search?p=10000

Now the attacker can also get the corresponding compressed sizes of the responses for each of these requests. Can you guess why the compresses sizes for each of these responses would differ and can you guess which request would have the smallest compressed size? Below would be the request with the smallest compressed sizes.

http://localhost/demo/Search?p=4545

http://localhost/demo/Search?p=5454

http://localhost/demo/Search?p=4543

http://localhost/demo/Search?p=5433

Below is the explanation as to why the above requests have least compressed sizes. Now take the first request. Below would be the response from the server.

 URL: http://localhost/demo/Search?p=4545

Breach Sample search page3

As shown above, when the deflate algorithm encounters this, it makes an easy representation of the repetitions and thus results in a least compressed size. So by analyzing the compressed size for each of the requests from 100-10000, an attacker can simply deduce what the card number is in this case. This the beauty of this attack lies in the fact that we did not decrypt any traffic but just by analyzing the size of the responses we were able to predict the text.

To summarize in simple steps, for an application to be vulnerable to this breach attack, below are the conditions that it must fulfill:

1. The server should be using HTTP level compression.
2. A parameter which reflects the input text. (This will be controlled by the attacker).
3. The page should contain some sensitive text which would be of interest to the attacker.

Remediation:

Turning off the HTTP Compression would save the day but that cannot be a possible solution since all the servers rely on it to effectively manage the bandwidth. Here are some of the other solutions that can be tried:

  1. Protect the vulnerable pages with a CSRF token
  2. Adding random bytes to the response so as to hide the actual compressed length.
  3. Separating the sensitive data from pages where input text is displayed.

 

 
No Comments

Posted by rohit

 

Android Master Key Vulnerability POC

28 Oct

A few weeks back, a vulnerability dubbed as ‘Android Master key vulnerability’ was revealed. This vulnerability allows attackers to inject malicious code into legitimate Android applications without invalidating the digital signature. It’s very easy for hackers and attackers to take leverage of this vulnerability and exploit it. The news is already out that there are apps currently in the market which are taking advantage of this vulnerability.  So let’s find out  what the issue is, how hackers can exploit it and what needs to be done to fix it.

How Android apps work?

Android applications are .APK files (Android Packages) which are nothing but a collection of ZIP archives. For easy understanding let us try to open an APK file for an application and find out the same. Consider the application MyFirstApp.apk application which is signed by own my certificate. Before we go ahead, let us spend some time on android’s signing process.

It is mandatory that all installed applications in android be digitally signed with a certificate whose private key is held by the application’s developer. The Android system uses this certificate as a means of identifying the author of an application and establishing trust relationships between applications. The Android system will not install or run an application that is not signed. Hence after building an application and signing it with a certificate, you have an apk file at the end.

MyFirstApp.apk

Assume that MyFirstApp.apk is any random application and looks like this when installed on the emulator.

Sample Android app

APK files are nothing but collection of zip files. So if you rename an .apk extension with .zip you will be able to see the contents of the file.

apk file contents

As shown in the above figure, the APK file consists of subdirectory called META-INF, which contains signed checksums for all the other files in the package. Now if you modify any of the files in this package, Android will block the package to prevent the users from harmful activities. Android does this by verifying the checksum. Now in order to verify the checksum of each of these files, android has to extract each of these files from the APK archive. This is accomplished using the Java unzipping library which will parse the ZIP-format APK file, extracts each file object and matches it up with the corresponding checksum mentioned in the manifest file in META-INF:

Android app meta-inf folder

Now try to modify any of these files, for example, try to modify  the launch image file present inside MyFirstApp.zip\res\drawable-hdpi , rebuild it and try to install it on the device using the adb and you will find that android rightly notices that and shows the below message.

Android app signature mismatch

How the attack is accomplished?

The attack successfully bypasses this verification process and installs the application with any changes the hacker embeds in the code. The attack is based on the concept of placing two different files in the APK archive with the same name. Regular ZIP software generally do not allow you to have two files with the same name in one archive. But the ZIP format itself doesn’t prevent duplicated filenames, and you can take advantage of this to create an archive with repeated file names as shown below. The ic_launcher.png file is something that I have added to the existing file and created a new apk file named HackedFile.zip.

zip with duplicated filenames

Now rename this file to HackedFile.apk and try to install it and observe that android accepts it this time. It runs successfully without any complaints. Observe that I was able to replace the launch image successfully without using any certificate and android happily accepts the same.

Android app with modified image

How is this even possible?

This is possible because Android verifies the first version of any file in archive but the installer verifies and extracts the last version of the file. Thus the legitimate file is checked by the cryptographic verifier and the one added by the hacker is installed by the installer. In simple words, what gets installed is a fake but what gets verified for signature is legitimate part.

What are the implications?

The implications are huge. Most important thing to note is almost all version of Android are vulnerable to this attack. The impact of this vulnerability and its exploitation is only limited by imagination of an hacker. For instance he can spy on your communication or he can go a step further and send premium rate sms without the users knowledge, make background calls,  take pictures and forward to mails etc.

Some of the built in apps which come along with the phone have higher privileges than the other applications which are installed from the play store. So an attacker can take leverage of this and create apps which would have system level privileges. Bluebox team has successfully demonstrated this and changed the name of the kernel etc.

Pic7

Google has already released patches for this but as everyone knows it will certainly take some time for the handset makers to update all of their models. Google is now verifying all the applications in the play store to check for the master key vulnerability. But the other third party stores and the side loading of apps aren’t going to help the cause.

References:
http://www.saurik.com/id/17

 
1 Comment

Posted by rohit

 

Penetration testing of iPhone Applications – Part 6

12 Sep

In the First part of the article, we have discussed about the iPhone application traffic analysis. Second partThird part and Fourth part of the article covered in-depth analysis of insecure data storage locations on the iPhone. Part 5 covered runtime analysis basics with Cycript. In this part we will take a look at in-depth analysis of application runtime using cycript and GNU debugger.

Runtime analysis with Cycript:

With cycript we can hook into the application runtime, access & modify the instance variables, invoke the instance methods and override the existing methods. In the previous article we have discussed on how to access instance variables from the application runtime. In this article we will take a look at how to invoke & override the application instance methods. 

Invoking the instance methods with Cycript:

Cycript allows invoking the application instance methods directly from runtime. This helps in bypassing the validation mechanisms implemented in applications. For the demo, I am using a photovault application and you can download the IPA here. Photovault application will help to keep the photos securely by protecting with a passcode. When the application is launched for the first time, it prompts the user to set a passcode. Later on, the user has to enter the correct passcode to view the private photos. Below steps explains how to bypass the photovault passcode protection using cycript.

1. Launch the photovault application and it prompts for a passcode.

photovault login screen

2. Connect to the iPhone over SSH and find the application process id using ps ax command.

photovault ps id

3. Hook into the application process using cycript –p [PID] command.

hook with cycript

4. On the cycript prompt, grab the application delegate instance using UIApp.delegate command.

photovault UIAppdelegate

5. Obtain the photovault class dump using class_dump_z. Search the class dump for AppDelegate & look for the @interface of it.

photovault classdump

6. Looking at the class dump reveals an interesting method called – pinLockControllerDidFinishUnlocking. The method does not take any arguments. So we can invoke it directly using [UIApp.delegate pinLockControllerDidFinishUnlocking] command. 

method invocation with cycript

7. Bingo!. It logs you into the application without entering the passcode and gives access to the private photos.

photovault passcode bypass

Overriding the instance methods with Cycript:

The objective-C runtime allows modification & replacement of the existing methods code dynamically. This technique is known as method swizzling. For this exercise, I have created a demo application called HackTest and you can download the IPA here. HackTest application prompts the user for a password and displays the welcome screen upon entering the correct password. Below steps explains how to bypass the HackTest password validation mechanism by overriding the existing methods using cycript.

1. Launch the HackTest application and it prompts for a password.

hacktest password

2. Enter any value (ex: abcd) and click on Enter button. It displays invalid passcode message.

hacktest invalid passcode

3. Connect to the iPhone over SSH and grab the application process id using ps ax command.

hacktest ps id

4. Hook into the application process using cycript –p [PID] command.

hacktest-hooke with cycript

5. On the cycript prompt, grab the application delegate instance using UIApp.delegate command.

hacktest UIAppdelegate

6. Obtain the HackTest class dump using class_dump_z. Looking at the class dump of HackTest application reveals an interesting method called validatePasscode. The method takes no arguments and returns a Boolean value. The application probably uses this method to check for a valid passcode and takes the authentication decision based on its return value. Now using the method swizzling technique we will modify the validatePasscode method to always return true.

hacktest classdump

7. validatePasscode method is declared in the ViewController interface and the ViewController instance is present in the AppDelegate interface. So grab the ViewController instance using UIApp.delegate.viewController command.

hacktest viewcontroller

8. To override the validatePasscode method, run the below command.

UIApp.delegate.viewController->isa.messages[‘validatePasscode’]=function (){return 1;}.

It overrides the function to always return 1. isa is a pointer to the class structure and gives access to the method implementation.

cycript metod override

9. Bingo!. It logs you into the application without entering the password and displays the welcome screen.

hacktest passcode bypass

The above examples shows how one can easily manipulate the runtime and circumvent the security checks implemented in iOS applications using cycript.

Runtime analysis with gdb:

Gdb – gnu debugger is a powerful tool to analyze and alter the runtime behaviour of iOS applications. Debugging is an interactive process and allows setting breakpoints in the application execution which in turn gives more control on the application. For this exercise, I am using a photovault application and you can download the IPA here. The photovault application keeps the private photos securely by protecting with a password. When the application is launched for the first time, it prompts the user to set a password. Later on, the user has to enter the correct password to access the private photos. Below steps explains how to grab the photovault password from runtime using gdb.

1. Launch the photovault application and it prompts for a password.

photovault-3 password

2. Connect to the iPhone over SSH and find the application process id using ps ax command.

photovaut-3 ps id

3.  Attach gdb to the application process using gdb –p [pid] command.

photovault-3 gdb hook

gdb attaches to the process and reads the symbols for shared libraries.

photovault-3 gdb

4.  Obtain the photovault class dump using class_dump_z.  Looking at the class dump reveals an interesting method called btnLoginClicked. This method takes no arguments and probably gets invoked upon pressing the login button. Let’s inspect the method by setting a breakpoint.

photovault-3 classdump

5. Set a breakpoint for the btnLoginClicked method using b or break command. A breakpoint pauses the program execution whenever a certain point in the program is reached.

gdb breakpoint1

6. At this point the application gets freezed and does not accept any input. In order to continue the execution type c in the gdb prompt.

gdb continue execution 1

7. Enter some value in the photovault password and click on login button.

photovault-3 enter password

8. As expected it hits the breakpoint in gdb and the application execution is paused.

photovault-3 breakpoint

9. At this point, disassemble the btnLoginClicked method to look at the next executable instructions using disas or disassemble command. As iPhone binaries are compiled for ARM processors, gdb displays the ARM based assembly instructions.

gdb disassemble

10. In the disassembled code you will see a lot of dyld_stub_objc_msgSend instructions. Objective-c is based on the messaging framework, hence methods aren’t invoked or called, instead messages are passed between objects using objc_msgsend method. An attacker can tap into these messages and look for sensitive information. On gdb terminal, we can setup breakpoints for all the objc_msgsend calls and inspect for the important information. As there are too many objc_msgsend calls in the disassembly, it would be difficult & time taking process to inspect each and every call. In the btnLoginClicked disassembled code, dyld_stub_objc_msgSend located at 0x0000618a is followed by a cmp instruction (conditional execution) which probably means it checks for a login state. So let’s set a breakpoint at 0*0000618a and inspect the objc_msgsend call.

photovault-3 breakpoint2

11. Continue the application execution and it hits the breakpoint.

gdb continue execution2

We can inspect the breakpoint by looking at the register values. To see register values at the breakpoint use info reg command. iPhone uses ARM based processors which contain 15 general purpose registers (r0 – r14), program counter (r15) and current program status register (flags). The standard ARM calling conventions allocates the 16 ARM registers as:

r0 to r3 – holds argument values passed to a method (r0 is also used to store the return result from a method)
r4 to r11 – holds local variables
r12  ( ip) – Intra-Procedure-call scratch register
r13  ( sp) – stack pointer
r14  (lp) – link register
r15  (pc) – program counter

ios - gdb registers

objc_msgsend method contains 3 arguments -

Receiver (r0): A pointer to the called object. That is, the object on which the method should get invoked. x/a $r0 command is used to examine the address located at r0 and po $r0 command is used to print the object located at r0.

photovault-3 r0 reg

Selector (r1): String representation of the method that handles the message. x/s $r1 command is used to examine the string value stored in r1 register.

photovault-3 r1 reg

First argument passed to the objc_msgsend is stored in r2. Po $r2 command is used to print the r2 register value.

photovault-3 r2 reg

Looking at the register values explains that r0 contains the original password and the application is trying to compare it with the user entered value in r2. Bingo ! Now we know the password and can log into the application directly.

photovault-3 password bypass

The above example shows how one can easily manipulate the application runtime using gdb. The application security can be improved further by adding anti-debugging techniques which would prevent malicious users from using a debugger. Though they won’t provide 100% security, it works as an additional layer of security and delays the attacker attempts.

Penetration Testing For iPhone Applications is going to be covered in a series of articles. In the Part 7, we will take a look at push notifications, URL schemes and few automation tools.

 
 
Page 1 of 1312345...10...Last »