Sunday 4 November 2012

Using SAST technology on Android to detect SSL implementations issues

Arvind called my attention to this pdf Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security which (looks like) is a great read and it includes this really interesting paragraph:

8. COUNTERMEASURES
8.1 OS SolutionsMalloDroid 

Installation Protection. (page 59)
MalloDroid could be integrated into app installers, such as Kirin [9], to perform static code analysis at install time. This analysis performed directly on a phone could warn of potentially unsafe applications. Users would then have to decide whether they wish to install the app irrespective of the warning.

I ABSOLUTELY agree with this!!!!!

There is a point where the complexity level of what is being implemented is so high and there are so many moving parts to take into account (or to do them consistently in deployment) that we need a way to codify what is (or should) happen.


That is why SAST (static code analysis) is SO important. SAST is a way for the expert to codify best practices!

SAST allows non-expert consumers (which is 99.9999% of the target audience) to have access to expert security guidance in a way they can consume it.

Yes there are still challenges on how to present the information in a way that the consumer (developer, user, manager) is able to make good/informed security decisions.

And I long for the day where the discussion is "What rules should we use", "How to write rules to detect XYZ" , "What is the risk profile of XYZ", "What happens when XYZ is used in an environment that also has a (detected via SAST) issue ABC" , etc...

But first we need infrastructure in place (like the MalloDroid app) that will allow us to have those discussions.

On the topic of SSL and SAST, here is another example of where we need SAST rules for SSL: How to create '100% SSL websites' Correctly

Ivan Ristic in his Breaking SSL presentation



 Mentions 10 SSL-related mistakes that he has seen on the interweb (from small to large/popular sites)

 

 

 




And after showing the audience why just about everybody struggles to do SSL right, he concludes:


Well the reason why a lot of sites out there don't get it right is it because (as the 10 mistakes show) it is NOT a relatively small effort 

See, the reason why there aren't SAST rules to check for these 10 'mistakes' is because they are hard to detect in a consistent and scalable way (btw https://www.ssllabs.com/ is a big part of the solution, but we need SAST rules that can consume its data and integrate it with the SDL and CI environments)

When I see companies that are trying to start an 'secure coding' effort, I usually like to recommend "Why don't you do a '100% SSL Transformation' project? Where you will try to make your website XYZ to run 100% in HTTPS". That is a nice self-contained project which will force the multiple teams (DevOps, QA, devs, managers) to work together in a focused goal. This will create the relationships and connections required to tackle the harder problem of injecting secure coding practices into the SDL. See Etsy's post on Scaling User Security for some real-world challenges of moving into an '100% SSL world'.

Finally remember that SSL is one of those development activities that is done purely for security purposes. It doesn't add any 'direct value' to the application's business function, and in fact, its implementation/deployment might have nasty side effects on the application's performance and availability (which is FAR more important to most businesses, than the fuzzy threat of one of their users being 'compromised while accessing the site over an insecure network' )