1

I work for a large company and we are trying to judge the safety of some proprietary information that is being sent and received in a new application we are developing.

After our initial testing we realized that we could easily do a MitM attack with Fiddler over WiFi in no time in all - leaving a bunch of information in the open. Since then we changed it so that our company's proprietary information can't be sent over WiFi but instead over network only.

So the question is, is it possible for someone to decrypt our HTTPS packets over the mobile network (QXDM Possibly)?

Understandably if they get our private keys they could do it with wireshark but we are going to assume that it wont be the case.

If you know of any methodologies - we would like to test them against our app.

Edit: Adding More Info

It's an Android application that is sending important company information to and from our servers. We are not worried about people losing personal information (someone else listening in for example), we just dont want our company information decrypted (a situation where an end user decrypts our application's https packets). We were able to decrypt it easily using wifi and fiddler (since changed), we need to know what a user can do to decrypt packets that are sent simply over the network between our app and our server.

S.L. Barth
  • 5,504
  • 8
  • 39
  • 47
Nefariis
  • 111
  • 4
  • You don't provide enough information. What's sending this information? An App? A user in front of a browser? What? If you're using an app, are you properly verifying the certificate? You shouldn't be able to conduct a MiTM attack on properly implemented https. So the question I have is how are you implementing this? – Steve Sether Jan 27 '15 at 22:26
  • Of course, updated. – Nefariis Jan 27 '15 at 22:43

3 Answers3

1

First things first:

If the app is prone to a mitm via wifi, changing the communication media will not solve the problem. If communication channel was the only change made, i can promptly state that yes, your app is still vulnerable to mitm attacks, the only thing the attacker needs is to have access to the carrier's network (and judging by the way they choose their passwords, i wouldn't say that it would be THAT hard to accomplish to a sufficiently motivated individual...).

One of the ways you can protect the smartphone app is to implement Certificate Pinning. OWASP has a very extensive page about the subject and a more mobile-oriented cheat sheet on the topic.

So, you should not focus your efforts on where your data flows through, because the vulnerability does not depend on that.

Also keep in mind that certificate pinning is not a panacea, as it will not protect you from mitm attacks that target the mobile phone, but it is effective against network-based mitm attacks.

EDIT:

If we forget about proxy interception for a minute, we will talk about pure SSL decryption and it depends on the possible SSL attacks that apply to the established tunnel. You should check the TLS version (SSL should be forbidden) and the supported ciphers. There are LOTS of attacks that target SSL packets for tunnel decryption. Oneof them was discovered a few months from now, the security market became aware of POODLE not only in SSL, but in TLS also. Researchers even found it to be able to exploit TLS v1.2, depending on the ciphers used to establish the encrypted tunnel.

If you are worried about insider threats, a critical concern is the clear text storage of sensitive information. From shared preference files to open sqlite databases, this is one the top mobile vulnerabilities nowadays. Also keep in mind that source code can be trivially reversed, depending on the platform (Android, for example).

Community
  • 1
DarkLighting
  • 1,513
  • 11
  • 16
  • How could you do an MitM attack over mobile network? wouldn't you need to set up a proxy of some sort or route the information to a third party system? Say this is on Verizon or ATT - how could a hacker intercept and decrypt HTTPS? ... I need to write a report, so all this is good info. Thank You. – Nefariis Jan 27 '15 at 21:49
  • I should note that we are not worried about someone hacking someone else's info, we are more worried about someone "hacking" themselves and seeing the proprietary information that is being sent and received. So how could someone decrypt our https packets that are being sent over a network? – Nefariis Jan 27 '15 at 22:01
  • You should note that the medium where the information travels does not matter. Changing it to enforce mobile networks is just a workaround, as someone is still able to tap into the carrier network and repeat the exact process you made with Fiddler. What you have to do is enforce certificate checking. – DarkLighting Jan 28 '15 at 14:50
1

If you were able to MiTM an SSL session it means that your application isn't checking the certificate is issued by a trusted authority. Tools like Fiddler use self signed certificates, which should be rejected by a properly configured SSL layer. Unfortunately application writers often times ignore the need to check certificates and blindly trust that SSL protects them without understanding how SSL works.

But there's another, deeper problem. If you're trying to protect your data from the user, and the user has physical access to the device the data is displayed on, it's game over. You can't protect that. The nuclear option would be to just fire up a debugger, dump the device memory, and sift through it for whatever your proprietary information is. I'm sure there's more sophisticated attacks than that that'd be easier, but that's the most obvious one that comes to mind that I know 100% would work.

But the point is, you can't simultaneously give a user access to data and prevent them from getting at it. If the data is of any value to launch an even semi-sophisticated attack, someone will.

Steve Sether
  • 21,530
  • 8
  • 50
  • 76
0

You must carefully select:

  • The Cipher Suites allowed by your software, some are very strong and should be privileged, some are less strong and should be enabled only if there is some compatibility concern with your service, some are weak and should be disabled at all cost.
  • The version of SSL/TLS you allow, actually I should say the version of TLS since, following Poodle attack, SSL v2 and v3 are being progressively disabled on a general basis.

The main kind of attack that someone may take against an SSL-secured connection when he is in MiTM position would be to try to downgrade the handshake negociation to force the hosts to use weak protocol version or cipher suites, that's why it is important to explicitly disable them.

Moreover, I do not know if your specific case could be open to such threat, but do not oversight the threat caused by final users who blindly click on the "OK" button when prompted for an alert of unknown server certificate, in such case the "someone" just have to generate its own certificate and decrypt the communication locally...

WhiteWinterWolf
  • 19,142
  • 4
  • 59
  • 107
  • We are actually the most worried about the final user. The information we are trying to protect is proprietary information that is being sent and received. So how can someone "hack" themselves and decrypt https packets that are sent over the network? – Nefariis Jan 27 '15 at 22:00