Introduction and Background
In the previous article of the series, we have discussed how to intercept Universal Windows Platform apps traffic on Windows 10 Desktops. That has given us a glimpse of to add and remove certificates to/from your machine’s trust store. In this article, we will discuss some of the common checks we need to make while testing application traffic.
Setting up the lab
First, you need to get required files from Downloads section.
- Test Server with Self-Signed Certificate Installed (Ubuntu 16.04 Server).
- Challenge Application
Setting up the server:
- Download and install Virtual box.
- Import the OVA file into your virtual box and make sure that network adapter is set to Bridged.
- Install the App on your Windows 10 Desktop (You can also install it on your Windows 10 mobile/emulator if you wish).
Understanding Application Functionality:
Following is the expected functionality of the application. When you launch the application, we will see the following screen.
Let us assume that, we are developing an application that communicates with a server, whose SSL certificate is signed by a trusted CA. Since we cannot afford to have a similar certificate in a test environment, we will test our connections against a self-signed certificate. That’s the reason why we have the Ubuntu Server with us.
Let us enter the IP address of the Ubuntu server in the text field and check the results when each button is clicked.
Note: You may uninstall and install the app each time you click a button to avoid inaccurate results due to caching.
Clicking the first button will send a request to the server over HTTP, and you should get the following response.
Next, let us click the second button to send a request to the server over HTTPS. You should get the following output without any errors.
Finally, let us click the third button to send a request to the server over HTTPS once again. This should throw the following error saying, “The certificate authority is invalid or incorrect.”
Well, we now understand how the app works. These are the three common ways developers build apps to work with SSL connections.
Testing and identifying flaws in real world
The test app is intentionally developed in a way that it shows the verbose error messages so that we will understand what is happening when the app is making connections. In the real world, the apps won’t show us these verbose messages (well, in most of the cases). So, we need to have a way to determine if they are vulnerable in any way.
Note: In the next few sections, we assume that the app is sending sensitive data over the network, though it is not sending.
Let us begin:
Let us configure Edge browser’s proxy settings to point to Burp Suite. In my case, Burp is running on a different machine on the same network.
Case 1: Testing for Lack of SSL protection
Let us launch our test app once again assuming that the app is built to connect to www.google.com in its production version.
Let us enter www.google.com into the text box and click the first button. This should send the request to Burp as shown in the figure below.
If you notice the scheme http://, it is clear that the app is making connections over the network in clear text. The app is potentially vulnerable to MiTM attacks if it sends any sensitive data in clear text over the network.
Case 2: Testing for insecure SSL Implementations
Restart the app and enter www.google.com into the text box and click the second button.
If you intercept the request in Burp proxy once again, you should see the following.
Notice the scheme. This time, it is HTTPS. Though we are making connections over HTTPS and intercepting traffic using Burp, the app is happily receiving the response from https://www.google.com when you forward this request, without throwing errors. The response looks as shown in the following figure.
Ethical Hacking Training – Resources (InfoSec)
If you come across a similar scenario while testing an app in production, possibly you found a flaw in the app’s SSL implementation.
Let us try to understand why using our test server.
Originally, when you access the IP address of the server over HTTP using a browser, you will see the following.
The same IP address, when accessed over HTTPS using a browser, will show you the following message.
If you don’t trust the server, you will have to go to your homepage. But, if you trust the server’s certificate you will click continue. This means, you are ignoring the SSL warning manually and continuing to access the page. Then you will be landed on the following page.
Developers exactly do the same within their app in an automated fashion to ignore SSL warnings for their app to function without any problems while connecting over SSL. It is commonly seen that developers do it while testing the apps against self-signed certificates, and push the same code into production often by mistake.
What’s wrong with it?
It will defeat the whole purpose of having SSL connections. Anyone can provide a self-signed certificate to the app, and it will make connections with it without showing any warnings.
In Windows 8.1 and UWP apps, developers can use the following piece of code to ignore SSL warnings.
When you have access to the source code or when you decompile the app to obtain the source, you can check for the similar instances of code to figure out if the app accepts Self-Signed Certificates.
Case 3: Testing for Lack of SSL Pinning
Restart the app and enter www.google.com into the text box and click the third button. You should notice the following in the Alerts tab of Burp.
You should also see the following error in the application.
Now, follow the steps shown in the previous article to add PortSwigger CA certificate to your machine’s trust store. After that, we should be able to see the SSL traffic without any errors.
Though we have safely implemented SSL in our app this time, it is still possible for the attacker to intercept the traffic if the CA certificate is added to our device’s trust store.
Though, it may minimize the chances of remote attackers performing MiTM attacks, attackers who are targeting the application can still analyze the traffic of the application which is one of the key elements during an assessment.
If the developers want to minimize the chances of attackers being able to analyze their app traffic, the next option is to implement SSL Pinning. We will discuss more about SSL Pinning in a later article.
In this article, we have discussed some of the common checks we need to make while testing Windows application traffic. Though we have explained with the examples of Windows UWP apps, these concepts will also apply to other platforms such as Android & iOS.