Reverse Engineering “Secure” HTTP API’s with an SSL Proxy (OWASP AppSecUSA Presentation Review)

Mark HaaseThis is a continuation of my series on the talks I attended at OWASP AppSecUSA in October of this year.

Presenters:

Alejandro Caceres, Computer Network Operations Engineer – Lunarline Inc.

Mark Haase, Sr. Security Software Engineer – Lunarline Inc. (Follow him on Twitter, @Mehaase)

The thesis of this highly valuable talk was that SSL does a fine job with the traffic being transmitted/received by the endpoints but does not protect against hostile endpoints. A general security maxim is proffered: make the cost of getting through the security more expensive than the assets protected by the security. I have well learned to think in these terms myself. Security is indeed an odds game.

SSL uses certificates with public/private key encryption but clients may not necessarily validate against the Verisign-issued certificate. In that case, such as with Apple Game Center (a mobile phone app), one can create a proxy that intercepts the traffic, lets the server think it is talking to the game center client, and create different certs to pass the traffic along to the client. Then the traffic can be snooped unencrypted.

In the case of Apple Game Center, this traffic is JSON packets. The application as it turns out does not validate inputs and so it is quite easy to stuff INT_MAX into the high score and thus cheat your way to a score that it is impossible to surpass. Countermeasures include implementing extra encryption on top of SSL.

The speakers were careful to note that it is wise to call the highest level API in whatever crypto library you are using since crypto is way too easy to screw up implementing it yourself.  This affirms my experience with crypto. The other more common countermeasure which is mentioned in other talks is cert pinning. Simply write the client app to insist on a very specific cert. The disadvantage of that is that any change on the server mandates a redeploy/update to all clients that are to work with the new cert. These are things to think about before you promote your app openly to the public.

I had heard of other man in the middle attacks, specifically the one where the server allows negotiating the cert and that gives an interceptor an opportunity to negotiate for a contrived cert and thus snoop arbitrary (on thusly insecure) SSL traffic. It rattles one’s conceits and is an admonishing splash of cold water to not get into the mindset of thinking that SSL security is solely about the strength of the cryptos it is using.

About M. J. Power 22 Articles
Connect with Mike on Google+

Be the first to comment

Leave a Reply

Your email address will not be published.


*