Last year I got interested in the security field. Partially, because of accidentally falling into it, but also all the news around botnets, ransomware, and breaches just would not leave my awareness bubble.
Coincidentally, thanks to awesome organisers, this year Kyiv got its very own OWASP chapter! So far they’ve had three meetups. Unfortunately, I missed the first one but attended the second, and they were kind enough to allow me to give a talk at the third.
This post contains some highlights and notes on the talks I attended from the last, Winter 2017 meetup. Any mistakes below most certainly are my own and not the speakers.
Note that while presentations were not in English, most slides are.
Don’t Waste Time on Learning Cryptography: Better Use It Properly, Anastasiia Vixentael
In her talk, Anastasiia argues that using cryptography for the basic case of data encryption and decryption is needlessly complicated. There are usual suspects involved: cyphers, modes, hashes, key lengths, IVs. Then, add to those all the required infrastructure for secrets management, backups, etc. It’s just too many choices with lots of hidden traps. Using a nice visual metaphor from the talk, it all builds into a “Wall of Insanity.”
Proposed solution: boring crypto. As I understood it, this is an idea of a library with usable by regular developer interface, while most of the complex decisions made by the knowledgeable author in the form of reasonable defaults. Plug’n’Play comes to crypto! Examples include BoringSSL, noise, libsodium, themis and keyczar.
Another interesting point from the talk: you should prefer a higher level of abstraction when choosing how to implement cryptography in your project. Prefer crypto-systems (e.g. WhisperSystems’ signal protocol, ZeroKit, TLS) to crypto-libraries, and boxed solutions (Vault, Acra) to crypto-systems.
I was slightly confused during the part about HSMs, TPM and software cryptography. It seemed disconnected from the general story before and after it.
Overall, it’s an excellent introduction, with a few links and things to google when embarking on enhancing project’s security by adding crypto.
Links: video, slides.
SAMM: Understanding Agile in Security, Pavel Radchuk
This was a nice and short talk on the strategy and complementing tools for bringing security to the agile development called OWASP SAMM. The problem it solves is the same as in the previous talk (and always?) — developers have lots of other tasks, no time for security.
With SAMM there’s no need to go all-in, it follows native for Agile’s iterative approach:
- perform an assessment — what do we have now?
- define goals — what do we want to do better?
- think of the ways to come a bit closer to your goals
- do a small step towards improvement
- go to 1
So far as intro goes, it all sounded very reasonable and, importantly, doable.
Would love to hear more about real life experience implementing SAMM, e.g. what went not so good, reasons choose something else, tools you wish existed, trade-off decisions, etc. Does anyone want to do a follow-up? 🙂
Links: video, slides.
Security Economics, Vlad Styran
I don’t know how recent this is, but security people seem to have a general interest in the economics. It makes sense, of course, since both fields also study the people motivations, but economists worked on that relatively longer, and so have more to share. This talk was loosely(?) based on the recent “Cyber Security Economics” course.
- Only making more money is an incentive for vendors, not building secure things; on the other hand, consumers are motivated to spend less. In this setup both vendors and consumers would like to ignore “invisible features” like security and “promise” to add them at some point later
- All risks are on security consumers because there’s always a way to blame them: wrong configuration, “human error,” etc.
- Security results are tricky to measure since “losses that didn’t happen” just aren’t there
- Compliance is security, but it protects from different actors, namely government and industry regulators, than firewalls or IDSes
There was a bit that confused me: first, we imagined rational actors to build our models, studied them, and then we discover that people are (surprise!) not rational. So, shouldn’t the models be updated? How wrong are insights drawn from those models?
Links: video, slides.
Modern SSL Pinning, Dima Kovalenko
This was an especially fun talk on the SSL/TLS pinning techniques as Dima presented it from the perspective of the security researcher or attacker. I’d keep reminding myself that occasional “Everything got worse” for a defence side means diametrically opposite: “Everything got better!”
A brief history of the cat-and-mouse game of app developers and people reversing their APIs (examples for iOS, but it’s similar with Android):
- at first, switch from HTTP to HTTPS was meant to prevent MITM attacks
- it’s trivial to circumvent by adding your cert to the system’s cert storage
- probably annoyed by all the bots, developers added certificate pinning to make it harder to reverse their API and started bundling, or just downloading on the first start their certs, so that modifying global system storage became useless
- SSLKillSwitch appears that hooks into the system’s SSL stack, basically replacing function
verifyCert()with something that always returns
- developers now began using custom SSL implementations (mostly just OpenSSL), so that SSLKillSwitch no longer works with a lot of popular apps, but still works with ones that have less engineering power behind them
- with rooted device it’s still just a matter of time, and enough motivation to find the function to hook into, again making the SSL check always succeed
Things are “easier” on the Android since it’s more open, i.e. it’s harder for developers to secure.
When asked what he thinks about the idea of boring crypto, Dima said that it sounds great for reversers because it means one will be able to use the same method working with more than one app, similarly to how it was at the time of SSLKillSwitch.
Links: video, slides.
I also gave a talk, but it will be in a separate post. Stay tuned! 😉
It was an excellent meetup, and I’m looking forward going again. Huge thanks to OWASP for sponsoring, chapter leaders for starting and continuing work on this whole thing, and speakers for sharing your knowledge and experience!
By the way, they’ve just announced the next meetup on March 3rd and you should submit a CFP! Registration will open a bit later, on the 1st of February. You should follow OWASP Kyiv twitter for future announcements.