Computers are complex, so is protecting them

Sat, Jan 28, 2017
tech #security #complex #attack-trees #defense-in-depth

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.

With this level of complexity, it becomes impossible to prevent all vulnerabilities. This is becomming a larger & larger problem in the real world. We do hear about famous hacks like Yahoo, Talk Talk, Best Buy etc - but mostly they were unlucky. We know from the security patch lists every system up and running (for example) on 1st Jan 2016 had vulnerabilities due to issues in some of the underlying infrastructure components.

There is hope however - although every system was vulnerable, not every system was exploitable. This is a key distinction to make. For example leaving my front door unlocked makes me vulnerable to someone walking into my house and stealing things, however this is not exploitable if I’m at home paying attention. The term for this is defense in depth - where you have multiple, overlapping security procedures. Defense in depth allows for one or more components to fail and still have a chance of stopping the attacker.

If we take an example of credit card theft on the web and how you secure it. A defense in depth metholdogy would suggest you try and

  • Protect the connection to the web browser
  • Protect the code running on the web browser
  • Protect the code running on the server
  • Protect the web server/API
  • Train developers in secure coding practices
  • Implement strong admin controls & audit logging
  • Analyse the transaction pattern for signs of fraud
  • Analyse the client profile for signs of fraud

All of these on their own is not enough to stop an attack - however combined there is a good chance one (or more) of them will delay/impede an attacker. This can often be enough to stop theft if those alerts are (manually or automatically) monitored.

The challenge with needing to deploy a defense in depth is decide which defense to deploy. The list above in the credit card example is far from exhaustive and it’s hard to choose what to pick. This is where modelling an Attack Tree comes in - with an Attack tree you simply write the goal (steal money) and then list all the ways to do it, and all the ways to stop it as a tree applying scores at each node. Bruce Schneier wrote a great article explaining it back in 1999. This is a very practical methodology to use to explain what protection to use.

Computer systems are extremly complex, and the only way to protect them is with a layered defense, consisting of multiple, overlapping solutions to try and prevent attacks. The best way to decide what you need is an Attack Tree, rigourous attack tree modelling gives you a good way to decide which attacks are feasible if a single security defense fails, and which are well protected by multiple layers of defense. Unfortunately very few systems today are modelled with attack trees to consider the threat level and instead many people rely on ‘tick box’ security which is dangerous as is does not address all the threats, or assess the risk of someone making a mistake (and you can guarentee people sometimes make mistakes).

Certs again

Sat, Jan 21, 2017
tech #ssl #crypto #security

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

Wed, Jan 4, 2017
tech #mitm #fintech

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

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

Wed, Jan 4, 2017
tech #security #mitm #crypto

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

Mon, Nov 28, 2016
tech #security #payments

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.

However contrasting this with the USA - in the USA even when they have chip and pin machines it still seems common for the shop staff to take the card and ‘swipe’ it first. This seems in 95% of cases to result in you signing for the transaction. If you think why shops are not using the chip and pin slots - I guess it’s human nature. People are used to the old method and there has been no incentive to force change. A good write up of the issues is at http://qz.com/717876/the-chip-card-transition-in-the-us-has-been-a-disaster/

What’s even more worrying is how shops in the USA are handling contactless. Shop staff have taken my card and tapped it on the pad. This is a logical extension of the current behaviour but is rife with fraud possiblities. I have no way to verify the amount and the staff could be wandering off to clone it.

This just shows dealing with the human factors is essential. People will accept less security for convience (until it goes horribly wrong)!

Man in the middle is easier than you think

Fri, Nov 18, 2016
tech #security #mitm #crypto

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

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

Zero Day Vulnerabilities in browsers

Your web browser is pretty secure, but it’s not perfect there is a continous stream of exploits, known as Zero Day vulnerability being found in browsers. They are called Zero day as the hackers find them before the vendor and the vendor has 0 days to fix them. Take for example the annual pwn2own competition where every year for the last few years security researchers have managed to break all of the major browsers. The browser vendors have definitely made their browsers more secure - but each year they get hacked, fix the hacks but more hacks are found.

The root issue here is software is complicated. As an example Fieox has 14 million lines of code and Chrome has 14.9 million lines. At that volume no one human can understand it all and it gets incredibly hard to ensure there are no weaknesses in it. There are tools that try and solve this but none of them can catch all bugs - as it’s quite hard to define what a bug is, until you see it! There are some approaches using machine learning (also called AI) that may help - but I suspect for the foreseeable future we’ll continue to have 0 day flaws found in browsers at regular intervals.

Zero Days are very relevant for breaking HTTPS as typically once a zero day is found it will be used (often via advertising banners) to install malware on the consumers computer. The malware will do a range of things including breaking HTTPS and logging keystrokes.

TLS/SSL Breaks

TLS/SSL are the cryptographic foundation of security on the internet, however they are definitely not flawless. In the last few years we’ve seen discovered techniques to break them, exploiting flaws in both designs and implementations.

TODO ADD PICTURE HERE

Over the last few years there have been several breaches (all with odd names) on TLS/SSL including

If we extrapolate this would suggest we’re going to get a steady stream of such issues over the next few years. Once you have broken the encryption then it becomes possible to MITM the connection. It can be argued that over time TLS will get more and more secure but so far we don’t seem to have got there!

Incorrectly issued ‘trusted’ certificate

TLS/SSL relies on certificate authorities (CA) to work - those are the companies that certify that when you connect to ‘www.mybank.com’ that you are actually talking to your bank. Each web browser vendor (Microsoft, Apple, Google, Mozilla) have a list of approved certificate authorities they trust by default - and they require them to only issue certificates to legitimate companies. In theory this should mean when you see the green padlock on your browser you know who you are talking to - except this doesn’t work all the time.

The issue is in how the CA verifies the company - there have been repeated issues with legitimate certificate authorities issuing certificates in error to 3rd parties who then impersonate the site. This can happen due to weak verification processes or in some cases it looks delibrate. When this is spotted the CA gets ‘told off’ by the browser vendors but in most cases they are just made to apologise and told not to do it again.

The end result of this is hackers have managed to get certificates that let them MITM legitimate websites and use them for profit. There are a number of upcoming web standards designed to make this stronger (e.g. HSTS) but many sites are not using this yet as it’s hard to configure reliably.

Aquire vendor issued ‘trusted’ certificate

A varient on getting a CA to issue a certificate is to find the private key for a certificate that has been trusted by the user. Most users are not aware of it but many computers have extra certificates installed and trusted by their IT department or 3rd party software. For example if your organization uses Microsoft Active Directory there is a good chance someone has installed a certificate authority for that and your local intranet, another example is Dell who installed for several years such a certificate.

This matters because if that certificates private key is not protected (and unfortunately it often isn’t) and a hacker gets it they can intercept all of your HTTPS traffic.

Social Engineering Approaches

For social engineering approaches we combine technical ‘tricks’ with getting the computer user to do something that makes our lives hacking them easier. It’s surprising easy to convince people to do things that let you hack their computer.

Convince user to install MITM certificate

Many legitimate Wifi hotspots require users to install either software or a certificate to access them. This is especially common in emerging markets (and relatively rare in Europe/North America). The purpose of this is to allow the wifi hotspot owner to inspect all your secure traffic e.g. to prevent misuse. However the same certificate also allows the hotspot owner to MITM all your connections and view any data you see and potentially trigger sites to perform actions as you.

With a ‘legitimate’ Wifi hotspot this probably won’t happen. However there is a device known as a Wifi Pineapple available for $99 that can be used either a security testing tool, or more nefariously, to mimic a legitimate wifi network. The hacker simply has to set up a Wifi pineapple, via it’s easy to use GUI, and you’ll be asked to install a MITM certificate from it, they can then intercept and modify anything you see.

The user has had to do something ‘silly’ for this to happen - namely install the MITM SSL certificate (a simple double click), but it’s generally quite easy to convince people this is legitimate. Relying on consumers IT education being sufficent to not do stuff is a strategy based on ‘hope’, which I’m pretty sure is not going to work!

Convince user to install software

Asking a user to install a MITM certificate is not the only way to ‘break’ HTTPS - another way to achieve this is to ask them to install some software. Typically this software is in the form of a Trojan Horse. For example some wifi hotspots ask you to download a ‘security’ or ‘connection manager’ program. These can be harmless or could also install the tools required to intercept your HTTPS.

Malicious Browser Extensions

Browser extensions have a lot of power - users install them typically from externsion stores and once installed often they can see all the pages you view. This allows them to bypass the protections of HTTPS and gather all the data served on the page.

The main protection against this is the browser vendors who police the extension stores for malicious extensions. However their policing is far from perfect, some malicious extensions do sneak through and they can generally aquire data from consumers for a while before anyone notices.

A varient of this attack is to ‘buy’ an existing popular extension from it’s developer (and remember most are made as hobbies so developers will consider selling for relatively small sums) and then issue an ‘upgrade’ with the malicious code. This allows attackers to quickly distribute their code to many browsers.

Conclusion

So are we all doomed to never having secure websites?

Probably not.

Securing computers from attackers was described by John Oliver as ‘Dancing on the edge of a volcano trying desperately not to fall in’ and to some degrees this is true. Computer systems are now sufficiently complicated there will probably never be a useful and totally secure system again.

However we don’t need totally security - it doesn’t existing in the physical world and we get by just fine. What we need is a assessment of the risks, mitigations and active responses to limit the damage an attacker can do. Techniques are starting to appear to reduce these risks (e.g. shameless plug Cloaked.JS from Irdeto ) which will make it significantly less lucrative for hackers to try this. Combined with a defense in depth approach this can get us to the point where we are controlling the risks and losses to an acceptable level.

mitm key

Wed, Nov 16, 2016
tech #MITM #security

To continue my MITM attacks theme - someone has just release a nice USB key that ransacks your PC - Ars Technica has a good write up.

This kind of thing is very dangerous as it’s really easy to get people to put USB keys into computers! I’m currently writing a longer article on the (many) ways to MITM TLS to help explain how easy it is!

malware and https

Fri, Nov 11, 2016
tech #security #banks #malware

I’m often heard worrying about the state of HTTPS and the ease to get users to do things that make it basically not function - but I’ll admit evidence of real world attacks is thin on the ground. There is a systematic reason for the lack of information - if a hacker uses a Man-In-The-Middle (MITM) technique to hack HTTPS there is very little evidence left and all thart will happen is the stolen data will turn up in a list at some point in the future. It’s nearly impossible to correlete the HTTPS hack and the stolen data - as it could have been stolen in dozens of places.

I was therefore delighted to see an article on WeLiveSecurity about the retefe malware (for the record I was not deligthed about the malware existing, but about the fact people are starting to notice this kind of thing exists). What we see this malware is a systematic attempt by an organized hacking group to break into people’s bank accounts.

Some key characteristics that should alarm everyone

  • They are targeting a huge list of banks (see below)
  • They have both PC and app based attacks
  • They are defeated 2 Factor Authentication by tricking the user into entering data

We often hear, when companies get hacks, the attack was sophisticated - often it is nothing of the sort. But in this case it is - this requires organization, planning and paitence - this is not a teenager in a bedroom, but an organized group setting out to earn substantial sums over time.

The worrying thing is this could become a lot more prevelant. Web browser security is focused on solving the problem of ‘how does the consumer browser trust the server’ not ‘how does the server trust the user’. Some companies (shameless plug) like Irdeto are looking at this - but mostly it’s being ignored.

Why is is being ignored?

I’d propose the main reason this is being ignored is the difficulty measuring the attacks. If you steal credit card data (for example) via such an attack it will simply show up on a list of stolen cards. There is no was to attribute where the card came from, it could have come from the bank, any merchant who’s processed that card, shoulder surfing or a dozen other sources. In theory with enough data you may be able to correlete a cause, but banks don’t tend to share such data in a useful way so we can’t produce analysis of where things were stolen from. An indivual bank is not in a good position to do the analysis as you’d have to correlete across multiple attacks.

I’d advocate for much greater sharing of detailed (not just a press release) of attacks to allow the whole security industry to try and find the patterns and to start blocking these attacks!

List of targeted domains

  • *.facebook.com
  • *.bankaustria.at
  • *.bawag.com
  • *.bawagpsk.com
  • *.bekb.ch
  • *.bkb.ch
  • *.clientis.ch
  • *.credit-suisse.com
  • *.easybank.at
  • *.eek.ch
  • *.gmx.at
  • *.gmx.ch
  • *.gmx.com
  • *.gmx.de
  • *.gmx.net
  • *.if.com
  • *.lukb.ch
  • *.onba.ch
  • *.paypal.com
  • *.raiffeisen.at
  • *.raiffeisen.ch
  • *.static-ubs.com
  • *.ubs.com
  • *.ukb.ch
  • *.urkb.ch
  • *.zkb.ch
  • *abs.ch
  • *baloise.ch
  • *barclays.co.uk
  • *bcf.ch
  • *bcj.ch
  • *bcn.ch
  • *bcv.ch
  • *bcvs.ch
  • *blkb.ch
  • *business.hsbc.co.uk
  • *cahoot.com
  • *cash.ch
  • *cic.ch
  • *co-operativebank.co.uk
  • *glkb.ch
  • *halifax-online.co.uk
  • *halifax.co.uk
  • *juliusbaer.com
  • *lloydsbank.co.uk
  • *lloydstsb.com
  • *natwest.com
  • *nkb.ch
  • *nwolb.com
  • *oberbank.at
  • *owkb.ch
  • *postfinance.ch
  • *rbsdigital.com
  • *sainsburysbank.co.uk
  • *santander.co.uk
  • *shkb.ch
  • *smile.co.uk
  • *szkb.ch
  • *tescobank.com
  • *ulsterbankanytimebanking.co.uk
  • *valiant.ch
  • *wir.ch
  • *zuercherlandbank.ch
  • accounts.google.com
  • clientis.ch
  • cs.directnet.com
  • e-banking.gkb.ch
  • eb.akb.ch
  • ebanking.raiffeisen.ch
  • hsbc.co.uk
  • login.live.com
  • login.yahoo.com
  • mail.google.com
  • netbanking.bcge.ch
  • onlinebusiness.lloydsbank.co.uk
  • tb.raiffeisendirect.ch
  • uko.ukking.co.uk
  • urkb.ch
  • www.banking.co.at
  • www.hsbc.co.uk
  • www.oberbank-banking.at
  • wwwsec.ebanking.zugerkb.ch

Web of distrust

Wed, Nov 9, 2016

The Register are reporting a browser extension for web of trust has been caught stealing and harvesting browser history.

This underlines the risk browser plugins carry - they often can ‘see’ everything you’re browsing on the web and can send that data back to their developers. Most plugins are harmless and do what they say - but there is very little stopping ‘bad actors’ adding malicious code.

Another potential risk is a 3rd party ‘buying’ an existing plugin, imagine how many developers would happily sell their plugin for a few thousand dollars, they can then ‘update’ the plugin with malicious code and most users would never note.

The plugin stores do attempt to prevent this - but it’s going to be nearly impossible for them to stay ahead of all hackers.

Google not fixing Android Dirty Cow Yet

Tue, Nov 8, 2016

It’s become fashionable to give security defects ‘cool’ names like Heartbleed, the latest is Linux’s ‘Dirty Cow’. This is quite a major bug as it allows any user/app on a linux device to get ‘root’. Linux has now got a patch, but interestingly Google have delayed the patch for Android by a month.

It’s worth thinking a bit about what that ‘could’ mean…

  • Any android app on your phone can now do anything - all those permissions mean nothing to an app using this exploit
  • Google may be able to stop apps doing this getting through the Google App store - but they probably can’t stop them all
  • As a user there is nothing you can do to secure your phone/tablet

So all those apps you use on your phone are now vulnerable - even the best software security can only hinder an attacker with ‘root’ permissions on Android. That means if any developer, of any app on your phone, decides they want to do things like capture your online banking passwords, pretend to be in you in any app or engage in any mischief they want.

In all likelyhood most apps won’t try this - but it only takes one and all the stuff on your phone is exposed.

So what should be done, should consumers be demanding google patch quicker (probably), but we should also be demanding app vendors secure their own apps as much as possible and we should all be aware that IT security is always falible. There is no such thing as perfect security only ‘good for now’ security!