Conference Talk London 2018 |How to attack computers at cafes

Earlier this year, I was honoured to speak at the Security B-Sides London 2018 conference on the Rookie track. I presented the research I completed for my Master’s degree in the use of Unencrypted WiFi networks by business users. They recorded all the sessions and it is now available on YouTube.

My work builds on top of known attacks and existing software. It attempts to establish whether or not it is possible to extract NetNTLM hashes from computers connected to unencrypted WiFi networks.

If you want the full presentation document click on the link: Slide Deck “How to: Actually attack computers at cafes”

If you want to test your company’s cyber security Contact us and we will help you with your cybersecurity needs.

Transcript of my presentation |How to attack computers at cafes

This transcript has been tidied up a bit from the original speech because it doesn’t read brilliantly, but the message is the same.

Who am I?

Hi Everyone, I’m Felix and I’m a pen tester. I’ve been doing this for a while now and breaking into stuff for longer.

Why this research?

Today I am here to talk to you about some work that I did for my Masters dissertation. I was told to go away, find a project and do some research. At the same time I had a client that basically refused to take my word for it. They told me that they had lots of staff that spent a lot of time in airports and hotels and used free WiFi without a VPN or other protection. Essentially they had all their traffic going across the Internet without extra protection and this worried me.

The client turned round to me when I was telling him about the problem and stopped me saying “Can you prove it? Can you show me this? Because if you can’t I’m probably not going to do anything about it.” I had a look around but I couldn’t find a tool where the output would be something the business would care about. So I started out writing one myself.

Open WiFi MitM Condition

The work I am about to show you is based on a Man-in-the-Middle (MitM) attack. As a recap for those who may or may not know it: MitM conditions are essentially where you have some attacker controlled infrastructure where the attacker can do something to the communication between legitimate users and servers.

What can you do with MitM conditions?

These include reading the communication, modifying the communication and blocking the communication.

What I set out to do

I decided I was going to make my own Wi-Fi access point and make it steal user creds by being a MitM. I was hoping to then turn round to my client and give that demonstration so they would do something about their issue. At the time, I thought it would be easy, you know, why would it be hard, it’s open WiFi right?

Turns out encryption is a thing…

It turns out encryption is a thing… Obviously I already knew this, but it can be done at lots of different places in a communication. These days there’s not that much in terms of plain text creds going around the world. It’s usually encrypted somewhere and so that proved very quickly to me that I needed to so do something a bit different.

The idea

The idea was to go from a normal transaction to a little bit more like this diagram. I already had a bit of a plan based on some other work that I’ve seen and I know is quite prevalent. Essentially the attacker does stuff down at the bottom of this diagram. The section in pink is the bit where the attacker can take action.

What I actually did

I took a WiFi Pineapple and I set up a wireless network. I thought I was pretty obvious with the name that I used – “DANGER ZONE – DO NOT USE” – so that no one would connect to it. But people did anyway. I had a 4G modem, my WiFi Pineapple, and a battery. I wanted to prove to my clients that it was portable and you could do the attack anywhere.

Developed a tool

I took someone else’s code, frankly because it was easy and it already worked, and then I added stuff to it. My development process, over quite a long time, was where I would build a bit and it would work a bit and then I would find a bug. This quickly made me want to tear my hair out. I’d regularly leave the project and come back to it later – the hallmark of a good software development lifecycle obviously…

Fundamentally the tool is a transparent HTTP proxy which is sat on top of the SMB capture stack from Responder. Importantly, the proxy injects an HTML image tag. Because I knew I couldn’t get plaintext creds I aimed at getting a NetNTLM hash instead for later cracking. I called the tool ETAC: Evil Twin Authentication Capture.

Windows auth

One of the things you can do with Windows Auth is use programs like Internet Explorer to perform authentication. I was convinced that it was really important for me to make sure that my research worked against as stock a Windows as possible. I’ve seen lots of presentations of a similar nature that require the Operating System to be tweaked and the security weakened. I wanted this demonstration to be as real as possible so I didn’t install anything, no Firefox or anything along those lines. The only change I made, which you will see in a bit is I added them to an Active Directory domain.

Windows auth – the dot rule

So to clarify, I am trying to get Internet Explorer to authenticate against something. In the default configuration the security settings restrict this automatic login to the Intranet zone. If the machine thinks it is in an Intranet it will do what I need it to. The Intranet is defined by the settings in Internet Explorer. By default this means anything you explicitly list as part of the Intranet, any sites that don’t go through a configured proxy server, and those that are accessed via a UNC path. This last one is better understood as “the dot rule” and means that you can’t do it against IP addresses of Fully Qualified Domain Names (FQDNs). This is because both IPs and FQDNs have dots in them. All this meant the attack needed a DNS server.

The final attack flow

The diagram is what my attack flow ended up looking like:

• The victim joins the evil twin wireless network and asks for a DHCP lease
• The DHCP lease is supplied by the attackers DHCP server
• Then an HTTP request goes through the evil web proxy
• The web proxy downgrades the request as much as possible to enable easy injection on the response. This includes removing or altering HTTP headers and so on but not things like SSL stripping.
• The HTTP response then gets an image tag injected into it
• Which then creates a DNS resolution request
• And then the SMB stack from responder kicks in and helpfully provides authentication capabilities

The challenges / HTTP is a pain

That all sounds like it should be amazing and work nicely and it kinda works… I had lots of problems:

• First of all HTTP is a pain, there are a lot of variants in it.
• The WiFi Pineapple doesn’t have a lot of power so I couldn’t just use other peoples libraries. This meant that I had to write a lot of this myself.
• I found that there were status codes coming up with problems that I had no idea about and not seen before like an HTTP 416 error. This is “Range not satisfiable” – what on Earth does that mean?
• Lots of HTTP headers were causing me problems.
• Normal error handling was also tricky because sometimes connections and just not completed properly.
• I discovered that there are behavioural differences between the use of transparent proxies and declared proxies. One of the things that is different is that transparent proxies don’t get explicitly told what port to actually go and make the request on. This is because its part of the original TCP connection. If you are doing iptables manipulations you lose some of that information. It’s often easy to guess but that isn’t great and it still needs coding up.

Transaction size and chunking

My favourite challenge was HTTP chunking and the differences between HTTP 1.0 and 1.1. Although they are a bit interchangable one of the biggest headaches I had was dealing with Chunked Transfer Encoding (CTE). In CTE you get a chunk of information and then the next chunk and so on. This is fine but there seems to be two different types of CTE: marked and unmarked.

When you think about it, I am trying to inject an HTML tag so I had to be quite careful with where that tag goes. Otherwise you end up with half of the injected tag in one chunk and half in the next chunk. Alternatively, you can save the whole response in the transparent proxy, manipulate it and the spit it out at the end. But this introduces delays which might make users suspicious of the gateway.

Successes and failures

The success I had was the fact that a standalone Windows 7 machine gave me NetNTLM creds no problem whatsoever, every single time it was happy. Unfortunately the moment I joined the machine to an Active Directory domain, things started going a bit pear shaped. Unfortuantely, what happens is that the SMB connection starts and almost straight away the targeted machine tries to work out where it’s Kerberos KDC is. It performs DNS resolution for the FQDN of the Active Directory Domain that it knows about. When it doesn’t get a response, or a “no such name” response, it literally just sends an RST packet ending the connection to my attacking infrastructure. Game Over….

There are lots of ways I think I could develop this further. I ran out of time for my Master’s thesis so I had to submit and it was fine. I think you might well be able to develop it to impersonate the KDC. Perhaps, depending on what it is looking for to prove that it is within the correct network it might be possible to trick it and get the authentication desired.

Summary

The tool is on GitHub, I definitely could develop it further. Machines joined to a domain are not vulnerable to this attack (yet), but those that are not domain joined are vulnerable.

Thank you very much, are there any questions?