CV

Computers are complex, so is protecting them

Computer systems are complex, and the complexity has been at the point for quite a few years now it’s impossible for any one person to understand ’everything’ about any given system. There will often be people with a good understanding the ‘building blocks’ but it’s pretty much impossible to understand all the detail of the code, libaries and platforms it depends on.

Complexity has massive implications for the security of computer systems. If no-one understands a system how can you have any surity that it’s secure? The developers of the system will have tried to design for ‘known’ security issues, and tried to assemble the ‘building blocks’ in such a way they are secure but as they aren’t full understood it’s highly likely there will be some issues. This is not just an academic claim - if we simply look at the ‘security patchs’ for major building block components like Java, .NET, Windows, Linux - all of which have regular security issues that could compromize any systems built on them. On top of the building blocks, even in a mid size dev team, you will have a mixture of skills and abilities in the team and even with ‘2 person reviews’ security bugs do get through. Add in that many systems depend on services supplied by other companies - things like SaaS, hosting, ISP’s, Certificate Authorities and DNS - any or all of which are critical for security.

Certs again

Once again a major CA (Symantec) has been ‘caught’ issuing certificates improperly. There is a great write up on Ars Technica. This is really significant as falsly issued CA certificates are one (of many) way to MITM SSL.

This underlies the extreme difficulty in securing anything in IT. There are simply too many ‘moving parts’ and people in involved in securing anything. Your computers security depends on thousands of people and companies all doing everything correctly all of the time, and simple law of averages suggests this is unlikely to ever happen!

N26

There is a really good talk about some vulnerabilities found in the N26 banking app presented at the CCC congress this year.

<amp-iframe width=“1024” height=“360” sandbox=“allow-scripts allow-popups” layout=“responsive” frameborder=“0"src=“https://media.ccc.de/v/33c3-7969-shut_up_and_take_my_money/oembed" allowfullscreen>

The talk is worth a watch but it does highlight some key points

• No Certificate Pinning was being used that made it easy for the research to MITM the app
  • that’s not to say Cert Pinning fixes all issues but doing it makes things a lot harder for attackers.
• The API’s exposed to the web were far too verbose and didn’t really care about who was calling them
  • I think (shameless plug) that Application Hardening techniques for both web and mobile are going to be needed to secure these things long term. You need to ensure the code calling your API is what you think it is. This is where products like Irdeto’s Cloakware API Protection come in.
• A lot of the exploit relied on coding/logic errors - but they were quite easy to exploit
  • API Protection techniques will mitigate when the (inevitable) mistakes in logic occur in your code and make it much harder to exploit
  • That’s not to say you shouldn’t also work on fixing the logic!
• A number of the exploits relied on the engineers assuming ID were secret that were not (the ‘mastercard ID’ in this case)
  • This kind of assumption is quite common - if you think something is secret you should not just document it, but you need to have tests scanning logs/apis looking for that data occuring to ensure it’s actually still secret.
• A good breach response helps you manage PR
  • This was a pretty bad breach for N26 - but they handled it well. In particular they engaged with the researcher constructively and they fixed the issues in a reasonable time period.
  • Many companies either ignore the issue or head straight for legal threats in these cases, this is a mistake as doing so will increase likelihood of it being publicised before you have fixed it.

I suggest watching the whole talk - it’s well presented and shows a great real world example of how MITM can ruin your day as a bank or fintech.

Kaspersky

Ouch - Kaspersky have been enabling MITM attacks on their customer base. The Register citig a Chrome bug report explains how you can use this to trick consumers in thinking a site is valid/safe when it is not.

This underlines the ease of MITM SSL/TLS - see my previous article for all the different ways this can be done!

Human Momentum

I’ve been travelling quite a bit recently for work and have been reminded (again) how ‘human factors’ can defeat any attempt to improve security.

A good example of this is chip and pin/contactless. Chip and Pin is common and popular in Europe and as a result in Europe I never ‘give’ my card to members of staff for them to process it. This reduces the risk of fraud substantially as staff cannot easily clone/copy cards when they’ve never handled them.

Man in the middle is easier than you think

I’m often heard saying it’s quite easy to MITM HTTPS (also called SSL/TLS) and decided that maybe I should list all the methods I know of (there are quite a few).

The attacker has many options to try and get in the middle between the user and web server/API

• Pure Technical Approaches
  • Zero Day Vulnerabilities in browsers
  • TLS/SSL Breaks
  • Incorrectly Issued Trusted Certificate
  • Aquire vendor issued ’trusted’ certificate
• Social Engineering Approaches
  • Convince user to install MITM certificate
  • Convince user to install software
  • Malicious Browser Extensions
• Conclusion

Pure Technical Approaches

The pure technical approaches rely on attacks that don’t require users to make any mistakes and anyone can be vulnerable.