The theft of credentials has been occurring since almost the beginning of time. But of course when the web ‘happened’ and specially when e-commerce exploded stealing passwords also went on the rise. Emptying bank accounts, ordering stuff on behalf (and expenses) of others, spying, even impersonation was and is achieved by stealing credentials.
Luckily for us identity got strength with the use of two factor authentication. Banking adopted this rapidly, since they are not just in the business of money, they are a business based on trust. And without it they are out of the game. However not all services we consume with computing devices, specially on the Web have integrated two factor authentication, nor all of them are considered critical enough for that kind of robustness.
In fact many haven’t still implemented a sane headers policy on their web servers (more of this at the very bottom). Even with the wide adoption of HTTPS during the recent year, thanks in part to entities such as Let’ s Encrypt, thieves, cybercriminals, can still steal user names and passwords. This can be done by downgrading the connection from encrypted HTTPS to the old plain text HTTP.
If you find the articles in Adminbyaccident.com useful to you, please consider making a donation.
Use this link to get $200 credit at DigitalOcean and support Adminbyaccident.com costs.
Get $100 credit for free at Vultr using this link and support Adminbyaccident.com costs.
Mind Vultr supports FreeBSD on their VPS offer.
And this is what this article is all about. I’ll demo a connection downgrade from HTTPS to HTTP, in combination to ARP spoofing (which I wrote about very recently) to intercept the communication between the victim’s device and the web server.
Disclaimer: The activity described here is just for demonstration purposes. I shall not be liable for any malicious use of the tools and processes here described. Attacking people, companies, devices, public or private technological property, without the permission of such entities, may constitute an offence punishable in your region/country, and such activities are strongly discouraged by the author.
The layout of the network is a simple home network:
Broadcast range: 192.168.1.0/24
Gateway: 192.168.1.1
Victim’s address: 192.168.1.114
Attacker’s address: 192.168.1.147
This is the ARP table on the victim’s device.
In order to perform all this operation I have used a tool called Bettercap which I installed on Kali.
The tool is fairly easy to operate and just asking for help gives us some hints about its use.
As one wishes to execute this type of action fullduplex must be enabled.
Time to set the target.
The tool is now activated.
To see if the ARP spoofing bit of the attack is working we need to visit the victim’s device and check the ARP table again.
We can compare the values for the Gateway and we can see it’s changed from 5c-dc-96-89-3e-be from the real one to the fake 08-00-27-eb-35-9f. This last value corresponds to the attacker’s MAC address.
Once this has been check there are other things to do to steal credentials.
Enabling the sniffing module will allow the attacker, not just to redirect traffic from the victim to the internet as we’ve just seen with ARP spoofing, but to sniff that traffic and check the transmitted packets. These packets carry important information, such as credentials.
If the target is actually browsing this is some of the things the tool will capture.
There is another setting to be enabled. Bettercap incorporates a series of modules called caplets, which give the tool a wider range of operation, performing specific types of attacks. In this demo the hstshijack one has been configured to operate and downgrade the connection from HTTPS to HTTP.
On the victim’s device we can visit a famous website and try to log in.
Disclaimer: The attack is performed on a local device, owned by the author, and by redirecting its connection with the gateway. In no form, objective or manner, the attack is performed against the company holding the site reflected in the below capture, their services nor their partners or third parties.
Notice at the URL bar there is no HTTPS. This is a plain text HTTP connection, so the tool is working. This said, modern browsers alert the users when typing inside the boxes that the connection is not safe. The question is how many people read those little messages and how many of them don’t understand them, but crucially how many of them will proceed anyways.
With the credentials already in place there is only one step missing. Hitting the “Sign in” button.
At the attacker’s end of things one may see, lots of output, and in between the POST method being activated and the bettercap tool capturing the user name and the credentials.
The attack has succeeded.
User name is related to the session_key in this capture: [email protected]
The password is related to the session_password: pilotes123456
The attacked has worked despite the site owner’s diligent security measures. But remember, this is not effective all the time and in fact with this configuration the victim will have to visit the specific log in page straight away, and not having visited the main one before. If so the victim would’ve been redirected to an unresolvable domain making the activity suspicious. However now think of how many people have their usual log in pages bookmarked in their favourites. And yes, the attack doesn’t work 100% of the time on all sites.
The attack has some drawbacks. The victim will notice the site isn’t resolving right at some point since the configuration has been set to redirect to a false domain (.corn here), typed very similarly to .com but using the work ‘c-o-r-n’ as a replacement for ‘c-o-m’. They look very similar and this can defeat anyone not looking for this kind of error.
Another important fact is the attacker must have access to the same network the victim is sitting in. Again, be wary of free wi-fi on public premises. This is why you give the marketing and sales people VPN connections, proxy tunneled browsing complemented by good anti-virus software. They will often be out of the office, working hard, stopping to a coffee shop nearby a client and some nefarious actor can intercept their connection and try to steal their valuable credentials.
To mitigate this problem one can implement a series of measures. Two factor authentication can be one solution but, why adding that complexity when one can just configure the web server headers directives properly?
Applying the correct policy on policies means, above all, enabling HSTS which stands for HTTP Strict Transport Security. What does it do? Well, it basically mandates the connection to happen on HTTPS only, all the time, from end to end.
How can I enable HSTS, you may ask? If you are using Apache HTTP I wrote a hardening guide on this very site but I was also allowed to write one for Digital Ocean, you can read it here. And yes, FreeBSD is UNIX, it’s not Linux, although Apache HTTP is Apache HTTP everywhere. Got it?
I mean, this is not about the web server security itself, nor for the sake of it. It’s for the visitors, the customers, call it what you will. If the site you are operating on is complex and enabling some headers and features break things Mozilla has excellent documentation on the matter.
PS: As I did during my ski instructor career, finding the issues is not enough. Giving solutions to actual problems is one key for improvement. I hope you can appreciate both.
If you find the articles in Adminbyaccident.com useful to you, please consider making a donation.
Use this link to get $200 credit at DigitalOcean and support Adminbyaccident.com costs.
Get $100 credit for free at Vultr using this link and support Adminbyaccident.com costs.
Mind Vultr supports FreeBSD on their VPS offer.