MAN IN THE MIDDLE ATTACK ON MOBILE APPLICATIONS

MAN IN THE MIDDLE ATTACK ON MOBILE APPLICATION BECOMES SERIOUS THREAT

WHAT IS MAN IN THE MIDDLE ATTACK?

Man in the middle attacks (MITM) is one of the attacks where the attacker interrupts between the sender and receiver and gathers the sensitive data. MITM attacks, which are a form of session hijacking are not new. However, what might not be known is that mobile devices are vulnerable to MITM attacks too. It is quite complex for the attacker to inject the MITM attack on mobile applications than on web applications.

HOW DOES A MAN-IN-THE-MIDDLE ATTACK WORK?

A man-in-the-middle attack (MITM) is like eavesdropping. Data is sent from point A (Mobile) to point B (server/website), and an attacker can get in-between these transmissions. They then set up tools programmed to “listen in” on transmissions, intercept data that is specifically targeted as valuable, and capture the data. Sometimes this data can be modified in the process of transmission to try to trick the end user to expose sensitive information, such as login credentials. Once the user has fallen into the trap, the data is collected from the target, and the original data is then forwarded to the planned destination unaltered.

MAN IN THE MIDDLE ATTACK ON MOBILE APPLICATIONS

For mobile apps to prevent these types of attacks it is important to look at how the mobile app performs authentication. Using certificate pinning within the mobile app helps ensure that the mobile app is communicating with the device it is expecting to communicate with.

TYPES OF MITM ATTACKS

• ARP Poisoning
• DNS Spoofing
• Port stealing
• Invisible Proxy
• Certificate Forgeing

In this blog, we will discuss the major attack (SSL PINNING)

SSL PINNING

Certificate pinning is hard-coding the certificate known to be used by the server in the mobile application. The app can then ignore the device’s trust store and rely on its own, and allow only SSL connections to hosts signed with certificates stored inside the application.

The client makes a connection to the server and the server responds with its SSL certificate. If that certificate was issued by a Certificate Authority that is trusted by the OS, then the connection is allowed.

 CERTIFICATE PINNING FOR ANDROID AND IOS APPS

When we, developers, are working in the development of any kind of software, we can’t forget about security. The minimum security measure we should use is HTTPS as the protocol to share information between a client (in this case, an Android/iOS app) and a server, followed by an updated cryptographic protocol like TLS 1.2 (SSL 3.0 is vulnerable!)

You may think that using an HTTPS is enough but in some cases like banking applications, where sensitive data may be sent between our client and our server, could be risky.

By default, when making a TLS connection, the client check two things:

• The server’s certificate matches the requested hostname.
• The server’s certificate has a chain of truth back to a trusted root certificate.

What it doesn’t do is check, if the certificate is the specific certificate you know your server is using, and that’s a possible security vulnerability, if the client is compromised and an unsafe certificate is installed(certificate forging), someone could do a man-in-the-middle attack.

Root CA, intermediate CA and Medium certificate

The solution to this problem is certificate pinning. Storing a certificate on our client application to ensure that any SSL request made matches the server’s certificate provided by a trusted CA (certificate authority). Let us see how to do it on both Android and iOS apps.

ANDROID

OkHttp lib provides a CertificatePinner class to be added to an OkHttpClient instance. The easiest way to pin a host is turned on pinning with a broken configuration and read the expected configuration when the connection fails.

CertificatePinner certificatePinner = new CertificatePinner.Builder()
          .add("mydomain.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
          .build();
      OkHttpClient client = OkHttpClient.Builder()
          .certificatePinner(certificatePinner)
          .build();

After a request is executed, you’ll see this message on the console:

javax.net.ssl.SSLPeerUnverifiedException: Certificate pinning failure!
    Peer certificate chain:
      sha256/afwiKY3RxoMmLkuRW1l7QsPZTJPwDS2pdDROQjXw8ig=: CN=mydomain.com, OU=PositiveSSL
      sha256/klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=: CN=COMODO RSA Secure Server CA
      sha256/grX4Ta9HpZx6tSHkmCrvpApTQGo67CYDnvprLg5yRME=: CN=COMODO RSA Certification Authority
      sha256/lCppFqbkrlJ3EcVFAkeip0+44VaoJUymbnOaEUk7tEU=: CN=AddTrust External CA Root
    Pinned certificates for mydomain.com:
      sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
    at okhttp3.CertificatePinner.check(CertificatePinner.java)
    at okhttp3.Connection.upgradeToTls(Connection.java)
    at okhttp3.Connection.connect(Connection.java)
    at okhttp3.Connection.connectAndSetOwner(Connection.java)

The exception will provide you the server’s certificate public key hashes. Paste them on the CertifinatePinner and done! Once the certificate pinner function is enabled in the Android app it will have protection against        SSL MITM attacks

CertificatePinner certificatePinner = new CertificatePinner.Builder()
        .add("mydomain.com", "sha256/afwiKY3RxoMmLkuRW1l7QsPZTJPwDS2pdDROQjXw8ig=")
        .add("mydomain.com", "sha256/klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=")
        .add("mydomain.com", "sha256/grX4Ta9HpZx6tSHkmCrvpApTQGo67CYDnvprLg5yRME=")
        .add("mydomain.com", "sha256/lCppFqbkrlJ3EcVFAkeip0+44VaoJUymbnOaEUk7tEU=")
        .build();

IOS

The iOS solution is not so straightforward because you need to store the certificate itself inside your app. In my case, I’ve used Alamofire as HTTP client lib for Swift.

First, you need to get the server’s certificate in .der format and add it to your iOS project.

openssl s_client -showcerts -server name mydomain.com -connect mydomain.com:443 </dev/null | openssl x509 -outform DER > mydomainCert.der

And now, let’s enable certificate pinning: to do it we need both ServerTrustPolicy and SessionManager objects. The first one will define the hostname and certificates that will be used in the process:

var serverTrustPolicies = [
     "mydomain.com": .pinCertificates(
     certificates: ServerTrustPolicy.certificates(),
     validateCertificateChain: true,
     validateHost: true
   ),
 ]

ServerTrustPolicy.certificates() will return all stored certificates and the booleans will validate the certificate chain and the hostname.

Lastly, create a SessionManager object using this trust policies:

var sessionManager = SessionManager(serverTrustPolicyManager: ServerTrustPolicyManager(policies: serverTrustPolicies!))

Done! Just use this sessionManager object to execute request

sessionManager.request(“https://mydomain.com/api”, method: .get, headers: headers)…

Conclusion:

Since MITM attacks are stealthier and it does not need any physical access to the victim device, a robust protection mechanism is required to prevent it. Hence SSL pinning is a much needed robust protection as it protects the application against MITM attacks by only allowing the connections to the server based on the trusted CA certificates.

Session fixation Attack with example

Description:

Session Fixation is an attack that permits an attacker to hijack a valid user session. The attack explores a limitation in the way the web application manages the session ID, more specifically the vulnerable web application. When authenticating a user, it doesn’t assign a new session ID, making it possible to use an existent session ID. The attack consists of obtaining a valid session ID (e.g. by connecting to the application), inducing a user to authenticate himself with that session ID, and then hijacking the user-validated session by the knowledge of the used session ID. The attacker has to provide a legitimate Web application session ID and try to make the victim's browser use it.
The session fixation attack is a class of Session Hijacking, which steals the established session between the client and the Web Server after the user logs in. Instead, the Session Fixation attack fixes an established session on the victim's browser, so the attack starts before the user logs in.
There are several techniques to execute the attack; it depends on how the Web application deals with session tokens. Below are some of the most common techniques:
• Session token in the URL argument: The Session ID is sent to the victim in a hyperlink and the victim accesses the site through the malicious URL.
• Session token in a hidden form field: In this method, the victim must be tricked to authenticate in the target Web Server, using a login form developed for the attacker. The form could be hosted in the evil web server or directly in html formatted e-mail.
• Session ID in a cookie:
o Client-side script
Most browsers support the execution of client-side scripting. In this case, the aggressor could use attacks of code injection as the XSS (Cross-site scripting) attack to insert a malicious code in the hyperlink sent to the victim and fix a Session ID in its cookie. Using the function document.cookie, the browser which executes the command becomes capable of fixing values inside of the cookie that it will use to keep a session between the client and the Web Application.
o <META> tag
<META> tag also is considered a code injection attack, however, different from the XSS attack where undesirable scripts can be disabled, or the execution can be denied. The attack using this method becomes much more efficient because it's impossible to disable the processing of these tags in the browsers.
o HTTP header response
This method explores the server response to fix the Session ID in the victim's browser. Including the parameter Set-Cookie in the HTTP header response, the attacker is able to insert the value of Session ID in the cookie and sends it to the victim's browser. 

Example 1

The example below explains a simple form, the process of the attack, and the expected results.
(1)The attacker has to establish a legitimate connection with the web server which (2) issues a session ID or, the attacker can create a new session with the proposed session ID, then, (3) the attacker has to send a link with the established session ID to the victim, she has to click on the link sent from the attacker accessing the site, (4) the Web Server saw that session was already established and a new one need not to be created, (5) the victim provides his credentials to the Web Server, (6) knowing the session ID, the attacker can access the user's account.

Figure 1. Simple example of Session Fixation attack.

---------------------------------------Thanks to OWASP--------------------------------------

External Security Assesment is important for all Network and applications

The most common solution to external network security assessments is scan, scan, scan…and then scan some more

One of the most common vulnerability assessment activities for all companies of all sizes is an external scan, typically targeting internet-facing websites. Because we service the vulnerability assessment and penetration testing needs of large enterprises, we know “you know” that scanning external-facing network resources is important, and an obvious high priority. But we also challenge you to understand that scanning alone is not enough, unless all you really want is a checkmark for an audit of one kind or another.

A complete job of assessing the hardness of your external network includes multiple steps. Here are four of the main steps that you should be familiar with:

1. Anonymous information gathering to discover all Internet-facing assets a hacker could identify as potential entry-points into your network
2. Scanning of your internet-available network access points and web servers for known vulnerabilities (non-credentialed)
3. Verifying scan-result findings through in-depth manual pen testing attack techniques (both credentialed and non-credentialed)
4. Providing deeply informed remediation guidance and advisory services for identified/verified vulnerabilities

Why is BriskInfoSec approached to discuss external vulnerability assessment work with large enterprises?

BriskInfoSec is approached by our large enterprise clients to assess the security of their external-facing network assets for many reasons, but chief among them are dissatisfaction with their own internal tools, their present provider, and/or their own internal team’s ability to effectively manage all of their external testing work efficiently over time in a consistent and professional manner. These kinds of situations frequently result in an assignment for someone in a company’s security staff to search out alternatives; which then open up an opportunity for BriskInfoSec to present our highly-disciplined, in-depth approach to assessing the security of their external-facing network assets as compared to their present approach.

What do these companies discover when comparing BriskInfoSec approach to external security testing with their own present approach?

Because BriskInfoSec is driven by an across-the-board corporate culture that’s passionate about delivering the highest-value findings and recommendations possible, we do more than the basic steps, we do all the steps on your behalf; and then even more than that. If you assign mid-to-low-level-importance projects to others, fine, we see that frequently. But if you have a set of high-value software assets or critical points-of-entry into your network, working with BriskInfoSec always begins with an education about scanning versus penetration testing:

• Scanning and penetration testing are not the same thing, no matter how much the marketing folks working for the scanning tools manufacturers and scanning service providers make it sound that way
• Scanning is never enough, it is only an initial step in the entire assessment process
• Just the scanning step alone done effectively needs multiple scanning tools and multiple over-lapping scans run against the same resources in order to accomplish a thorough job of the scanning step
• Scanning the same resources  with different tools (as just recommended) naturally returns different results in different data formats
• Correlating and normalizing all this desperate scanning data requires special technology: like our proprietary CorrelatedVM™ platform that’s used by all of our pen testers and available (in part) to you through our CorrelatedVM Portal at no additional cost
• Scanning identifies potential vulnerabilities, and the different scanners may recommend different remediation actions – but BriskInfoSec’s CorrelatedVM platform fixes that problem as it correlates and normalizes all the scanning data from multiple scanning products and multiple rounds of scanning into the best set of recommended remediation actions
• Potential vulnerabilities identified by the initial scanning effort need to be verified by experts to eliminate false positives, and to thoroughly analyze the remainder, while also probing for any unidentified vulnerabilities the scanners could not find – this is work that only an expert pen testing company like BriskInfoSec can deliver 

In-depth pen testing to final reporting of findings and recommendations is what sets BriskInfoSec apart, and why we are given the critical responsibility of assessing the security of your most high-value/high-risk external-facing network assets.

The power of CorrelatedVM comes at no cost to you and provides real benefits that only BriskInfoSec can deliver

CorrelatedVM™, our proprietary vulnerability assessment and pen testing management platform, will be utilized for your external network penetration testing service when you hire BriskInfoSec. The CorrelatedVM platform and your complimentary access to its SaaS-based customer portal set our deep-dive pen test work and customer-facing deliverables light years apart from all other pen test services. This one-of-a-kind, powerful platform has been continually enhanced and used exclusively by BriskInfoSec’s elite team of pen test consultants on every pen test engagement for over a decade now.


Once you see our team in action with the CorrelatedVM platform, and what CorrelatedVM can offer your organization in the way of automating and disciplining your external vulnerability assessment efforts, you’ll realize how it solves presently unsolvable problems that will profoundly benefit all of your vulnerability management programs going forward.

Contact us for conduct external security testing against your applications and Network with affordable price info@briskinfosec.com

OWSAP WebGoat - vulnerable web application Attack

WebGoat Week 9

Exploit Unchecked Email
This lesson has two steps: first you are to send a malicious script to the website admin and second you are to send a malicious script to a ‘friend’ from OWASP.
So the first thing you are going to do is put the input shown below into the Questions or Comments textbox and click send:
<script>alert(“XSS”)</script>


Next we need to send it to a ‘friend’ from OWASP.
Again put the script into the same textbox as before but before you click Send open up Tamer Data and start the tamper service. Intercept the request and change the to field to another email address.

You can see here that the email was going to webgoat.admin@owasp.org (40 is the ASCII for @, you need to put the % for URL encoding). So let’s send this to friend@owasp.org. You will need to enter this:
Friend%40owasp.org

Click the OK button and you should see this:

Bypass Client Side JavaScript Validation
For this lesson you are given seven JavaScript validation mechanisms, all of which must have valid values in to submit successfully. You are told that both client-side and server side validation occur on these mechanisms; break the client-side validation.

Open WebScarab and check off request intercepts make sure to have everything highlighted.  Now go the page and hit submit. Go to the WebScarab window and check the encoded url tabbed, and you will see the values. Simply modify them, in the screenshot below I simply added the @ to each field and then press accept.


Session Management Flaws
Hijack a Session
For this lesson you are attempting to gain access to a user’s session.
You will need the jhijack tool available at http://sourceforge.net/projects/jhijack/.  Go head and startup WebScarab and set your proxies. Turn on request intercepts, view hidden fields and finally launch the Jhijack.  Now reload the page and we will look at webscarab.

Let’s take a moment and configure out jHijack. We need put our Host, and port into it first.  In the example below we see the IP address of this particular VM and port number, yours maybe different. Now we need to find a success message of some kind. So far we have noticed in Webgoat, that every time we complete a mission we get a “Congratulations” so let’s use that in our Grep (it’s case sensitive).  The last part we need to fill in is the URL.  See below.

Now we need to go back to WebScarab and select the Session ID tab (if you don’t see it make sure you are using WebScarab in it’s full version. Select previous requests and choose the appropriate url (picture below).  Now select the cookie weakid and remove it.

Go to the bottom of the screen and hit test. You should receive this success message.

Now we need to collect some data. Set the fetch number to 50 and hit fetch. Go up to the Analysis tab and set the session ID and you should receive the list of cookies out there.  We want to look specifically at the Session ID numerical value. Not that it is incrementing by 1.  Now, there is a gap there, between 19400 and 19402. That’s an open session so let’s focus on that.

The second part of the values has a large gap between them so we need to “guess” at what that value is, but we have JjHijack to make this really simple. Copy out the one above and below the target and  paste them into a notepad. Doing this makes it easier to see and copy.  See the example below. Notice the [] is a range.

Now it’s simply filling in the missing information in jHijack. Go back to WebScarab and gather the JsessionID, parameters and  enter them in. Note we want to place a $ at the end of our WEAKID value. Finally, take the range and enter that in.  Then hit hijack. See below.

We refresh the page one last time and go back to the WebScarab intercept and swap out the weakid.

And hit accept and we have our congratulations message.

Spoof an Authentication Cookie
For this lesson you are told to login using either webgoat/webgoat or aspect/aspect as the username/password combination. Next you are told to edit the cookie to change your identity to alice.
So first off log in as webgoat and click the Login button.

On the top of the webgoat page you should see a link that says Show Cookies. Click on the Show Cookies option and you will see the cookie that was created when you logged in as webgoat.

The authorization cookie or the user webgoat is 65432ubphcfx as shown above.
Go ahead and click the Logout button and then login with aspec/aspect next:

Click on the Show Cookies link again (might have to click twice) and you should get your authorization cookie:

For this authorization cookie we see that aspect has a value of 65432udfqtb.
So the different between the two logins is the letters after 65432.
The key to this attack is that the username is a really basic cipher. Let’s take a look at these authorization cookies versus their usernames:

The first thing that I noticed was that both the aspect and webgoat ciphers both start with u as the first character. The second thing that I noticed is that both webgoat and aspect both end in t. Next you can see that the last character of the webgoat cipher is x and x is one letter ahead of w. Also u is one character ahead of t which explains why both ciphers tart with u. The cipher pattern is a reverse of the login name and all letters are shifted up one. Now that we know this we can begin editing the cookie to change our login name to alice.
To do this lets first do the cipher by hand:

Ok now open up Firebug and edit the cookie value so that it is 65432fdjmb
To do this right click on the AuthCookie value when the menu for it is expanded and click Edit:

You will see a popup window called Edit Cookie. Change the value to the one we determined for user alice:

Click the OK button and refresh the page.