On AppSec Day…

Last week, I had the pleasure of attending OWASP AppSec day in Melbourne. This was a productive day. On the flight to Melbourne, I stumbled upon a hypothesis as to why my initial attempt at differential electromagnetic analysis of some AES traces didn’t work (I figured it was due to the non-instantaneous nature of magnetic fields), which I contradicted later through further experimentation and analysis of existing capture data – all hail the advent of cheap, portable storage.

Furthermore, I was able to refine a script for trace acquisition for Rigol scopes via Ethernet, using a modified github/pklaus/ds1054z module as the communications back-end – this is now mostly stable, and semi-consistent with other parts of the fuckshitfuck toolkit. Here it is in action against 100(!!) power traces of AES on an ATMega328p (I think we ended up missing one byte!):

There’s also some progress towards a template-based attack, though I’m not sure how realistically applicable this is, given variances such as horizontal jitter (still, based on the below, cutting out 1000 data points out of 8000 is still a solid improvement):

I must admit, there is a certain joie de vivre in this work that is, broadly speaking, absent elsewhere – compared to this, I really don’t care whose XSS is where and which crayon we need for the risk matrix.

On a somewhat more serious note, a few things were telling from this day, which are worth noting down:

The Top Ten are Dead, Long Live the Top Ten

Every single talk spoke about moving security to the left, but most of the industry is still attempting to fix the OWASP Top Ten. Realistically, the OWASP Top Ten has become the OWASP Top One or Two with the introduction of modern frameworks and sensible hosting, which voids entire categories of vulnerabilities. When’s the last time you saw someone construct a SQL query with string concatenation?

When’s the last time you saw someone (who’s day job is developer – our code is duct-tape and we know it) build a SQL query manually, as opposed to fetching data through a pre-built framework?

Yet let’s take a look at the OWASP wiki for how to protect against SQL Injection vulnerabilities:

Who realistically uses this stuff in 2018? No really, please do leave a comment if these principles are still applicable to production code where you are: I need to know.

On the other hand, where is the advice on how to prevent the logic-based bugs and debug content which are generally the easiest way into a web application? More importantly, is it even feasible to package the concept of “don’t fuck up logic” into a set of codifiable rules, which people will inevitably ask for? (My initial inclination on this is “no”).

What use is all this when people still sticky tape their passwords on their POS systems to the top of their monitors, for anyone walking past to read?

Most Dangerous Adversary 2018: Vendors

One of the speakers mentioned that the most dangerous adversary of the year was the vendor. This holds particularly true in application security, where the space is poorly defined enough that it is simple to deceive unsuspecting marks – failed comedy shows like “Next-Generation WAF” and “Self-Protecting Software” have taken root, like some kind of malignant tumor. Thinking of this contemptible filth, my mind cannot help but drift to the image of a serpent in the afternoon sun, poised to strike.

If these salespeople played EVE Online, surely they would be highsec miners.

What happened to genuinely building a good product, and simply letting the product speak for itself (and making datasheets publically available as technical reference material)? Imagine how much faster the market would mature, if we all followed the Atlassian model!

Integration and You: The Untold Story

I also was able to spend some time speaking with fellow… “appsec practitioners”. I got a sense that every product on the market had miniscule signal-to-noise ratios, and the best way to use a “code security” product was to simply drop all non-critical issues identified (i.e. switch a product on, and only require human interaction on critical issues). This matches with my experience speaking to developers, who overwhelmingly reject security review tools on the basis of false positives.

This is a tricky one: as security folks, we generally don’t “eat our own dog food”, so to speak: without running large enterprise codebases (which we don’t write) through enterprise appsec tools, we don’t know where the realistic pain points are. Getting security people to write copious amounts of enterprise code isn’t necessarily the solution either – broadly speaking, it’s not necessary.

In Conclusion

While there’s no clear fixes to a lot of the stuff, I think a lot of the above is reasonably applicable to any enterprise application security programme, particularly in the form of industry-accepted best practice as opposed to ISC^2-style standards.

See you all in BSides Delhi CTF.

About Norman

Sometimes, I write code. Occasionally, it even works.
This entry was posted in Bards, Jesting. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.