Author Archives: Felix

ProxyCannon-Revival – A tool for IPS evasion

Today we are releasing a tool called ProxyCannon-Revival and it is for IPS evasion. The original ProxyCannon is a tool written by Shellntel and released back in 2015. It coordinates virtual machines on cloud platforms and local routing policies so that penetration testers can simulate a real attackers ability to come from multiple IP addresses. This ability is crucial in avoiding IPS technologies and not worrying about getting caught by IP address blocking techniques.

TL;DR
The tool has been brought up to date, had new features added, and had a load of bug fixes/code clean-up. It is now in a dedicated repository here.

The catalyst to the Revival

During a penetration test some of our standard not-trying-to-be-quiet infrastructure was blocked by Fail2Ban. After a bit of investigating, we got in contact with our customer. The conversation went a bit like this:

[Us] “Tick, well-done customer, now please can you whitelist our source IP addresses.”

[Them] “Actually, we would like you to act like a real attacker, and that means you have to overcome this defensive capability.”

[Us] “Ok then, that should not be hard.”

We had a look around at what projects already exist, asked some fellow pen testers about what was around, and none of the projects found fit the requirements. There are a few that appear abandoned, such as the original ProxyCannon. Others seem massively complex, requiring Terraform and multiple layers of Proxy server. And then, there were both complex and abandoned projects such as ProxyCannon-NG. We just wanted a tool that worked with minimal effort – a classic pop-pop bang-bang affair.

We took the best fit of the projects we found and tried to get it to work, but it did not. It probably worked fine until relatively recently, as blog posts were raving about it until early 2019. As it is now 2021, we guess that the OS world has moved on and left it behind.

The update

At first, the plan was to bug-fix it and do the minimal to get it up and running again. By the time it was apparent that it would not be that easy, we were already far too emotionally invested in getting the project up and running to make the sensible decision to use a different project. Cue far too much engineering effort.

There is an issue tracker in the GitHub repo for full details, but the highlights are:

  • converted to Python 3
  • added a ton of debug output, so when it goes wrong, there is a chance of dealing with it
  • code consistency improvements and general clean-up
  • refactoring the network configurations deployed to be in line with modern OSs.

The extension – cache busting

The concept of the tool is great but works best against an IP subnet of targets rather than a single IP address. That means doing an infrastructure scan would be fine, but, a web app penetration test would end up without having randomised routes.

This routing behaviour is a result of the way current Linux OS’s do route caching. Essentially, in Equal Cost Multi Path (ECMP) routing, when the connection is made to the destination a route is calculated and stored for future use. Where you have ECMP, that route is calculated for every destination IP address so you would get random routes, but not each time you connect to the same IP address.

The ProxyCannon-Revival tool now has an optional cache busting function which can be enabled with the command line switch “-b”. This function continually changes the route weights so that, strictly speaking, it isn’t ECMP anymore. In practice it will still be pretty-much ECMP when averaged out over a period of time. The use of routes in this fashion along with a cache flush mean that the routes are used more evenly against a single IP address.

The extension – link health monitor

During testing it was plain to see that sometimes, for reasons outside the scripts control, one of the routes would be unhealthy and not function properly. This means that the user ends up with confusing timeouts or a bias towards particular routes.

There is now a network link health monitor in place that continually checks to see if the links are behaving as expected and if not, marks them as down so that the script doesn’t try to use them.

This functionality is on by default, but, can be turned off if so desired with the -m command line argument.

The extension – faster tunnel IP rotating

The process of asking AWS (the only currently supported cloud provider) for a new IP address takes approximately 2 minutes to complete. This might be sufficiently quick for some purposes but that might not be the case for other use cases, such as against application-layer IPS detection capabilities in web applications.

The tunnel host IP rotating functionality is now put into a queue with its own pool of thread workers which means that more than one host can have its IP rotated at once. This is limited to 50% of the number of tunnel hosts so that there isn’t a tragic loss of routes / source IP address entropy.

Tunnel host IP address rotation threading is enabled automatically if you run both the -b and -r command line arguments together. It is assumed if you want this level of IP address fluctuation that changing the hosts IP addresses quickly is important to you.

Adoption

You Gotta Hack That has adopted this project but welcomes the original authors and newcomers to join in with it if they wish. Hopefully, it will be useful for a while yet to come and plenty of you will be able to demonstrate that simple IPS evasion is easily achievable.

How you can perform IPS evasion with ProxyCannon-Revival

The tools is intended to be really easy to use. It is simply a case of getting an AWS account and security tokens, installing the python dependancies and executing the appropriate command. The command syntax is currently:

-id, default='ami-d05e75b8', Amazon AMI image ID
-t, default='t2.nano', Amazon AMI image type
--region, default='us-east-1', Select the region
-r, Enable Rotating AMI hosts
-b, Enable multi-path cache busting
-m, Disable link state monitor
-v, Enable verbose logging
--name, Set the name of the instance in the cluster
-i, default='detect', Interface to use, default will result in detecting the default gateway and using that
-l, Enable logging of WAN IP's traffic is routed through

num_of_instances, The number of instances you'd like to launch.

You have to tell ProxyCannon-Revival how many instances you want, but all the rest are optional. Highly recommend -l for logging external IPs and -r for rotating those IP addresses periodically.

Usual disclaimer

Please don’t use this script for nefarious purposes. Pentesters == good, law enforcement == good. Bad people == bad.

How we got our name….

Choosing the name of your child is hard. Arguably, selecting the name of your business is harder.

When I was choosing the name of the company, I knew a few things. I knew I wanted it to be cool. I knew it needed to have a kickass domain name. And I also knew that everything I thought of was already taken.

So like any other proudly geeky person, I set about programming my way through the problem. I wrote a little script that tested to see what domain names were available for every possible combination of Domain. I started with all the known TLDs (Top-Level Domains such as .com) and then the script added characters to the front. I ended up with a reasonably long list of possible domains, and I needed to narrow it down. My next step was to take the Domains I had identified and gather a screenshot of the first page of Google when searching for each of them. I was looking for inspiration. When I searched for YGHT, I spotted an article in the Urban Dictionary titled “You Gotta Hit That”. I instantly knew the name of my company and how I would brand it: “You Gotta Hack That”.

Something inexplicable happened along the way, possibly caused by my inner nerd, and I stook with the shortened version of the company name: YGHT. For several years using YGHT has been fine, but, it is more and more evident that on its own this only means things to those of us in the company.

We are now relaunching ourselves with the full version of our name, “You Gotta Hack That” but we won’t be losing our favourite short domain name…

Athom Homey Security Review | Transmits unencrypted WiFi credentials (CVE-2020-9462)


TL;DR: All Athom Homey and Athom Homey Pro devices, up to the current version (v4.2.0) transmit their initial configuration in the clear which includes your WiFi password. At the time of writing, Athom have no plans to fix this.


I will preface this with the fact that this vulnerability is not the most exciting in history, however, it is a vulnerability and the company should be doing better. The Athom Homey device is a smart-hub and can connect with other devices using a lot of different protocols.

In principle, the device is great as it means you should only have one place to orchestrate your smart home.

Despite it’s flaws, I actually really like this device.

Essentially, when setting up the device it has to connect to your WiFi network. The device has no exposed Ethernet port which is a shame, but, on the most part, this doesn’t seem to be a problem.

Athom Homey Security Vulnerability

The vulnerability only exists when going through the setup routine. The vulnerability exists because the device creates a temporary WiFi hotspot that is unencrypted which the user must connect to in order to perform the initial configuration. Crucially this means that when you configure the devices WiFi connection, you send the WiFi password in an unencrypted link to the device.

I sent Athom an email which contained the following:

The security vulnerability I wish to report to you today is the fact
that during sign up, your devices receive the WiFi security key without
being protected by any form of encryption. This means that an attacker
who is physically within range would be able to receive a copy of the
encryption key and therefore be able to gain unauthorised access to the
victim’s WiFi network. This is the same vulnerability that Amazon’s Ring
Doorbell made international news about in November 2019:

Read more about ring doorbell WiFi vulnerability

Which got the following response:

Thank you for your effort and letting us know your findings!

We are aware of the security risk involved in sending the credentials in plain text during setup of Homey.

We have made the decision back when this feature has been designed that while the process is in theory insecure, in practice it has a very low risk attack vector. In fact, there are many smart devices that use a similar way to set-up said devices.

Because the user must manually enable Wi-Fi Setup on Homey by turning it physically upside down, and another hacker must be present at the same time with equipment that’s not available to most, we have decided to focus our security efforts on more pressing matters. I am happy to say that 3rd party penetration tests have been performed on Homey and no one was able to gain access.

On a technical note, there is no secure way to set-up devices over a Wi-Fi hotspot without an out-of-band key. Homey does not have this printed in a manual, sticker etc. so we cannot simply issue an update. All other mechanisms are by definition unsafe because they rely on a shared secret, which is always crackable for any determined hacker.

We take the security and privacy of our users very seriously.

Not a bad response, though it got me to thinking…

It is true that other devices use a similar WiFi configuration routine, but, as demonstrated by Amazon’s Ring, it isn’t considered good enough on those devices either. It is also true that devices using completely different protocols, such as ZigBee, also have a similar type of key-exchange flaw. Again, it isn’t considered good enough here either.

I also don’t think it is fair to suggest that this configuration process only happens once. I’ve had this device for a while and I use it a fair bit and during that time I have ended up having to reset it and reconfigure it.

Nevermind that, but, it doesn’t take much to realise that an attacker could easily create a circumstance that would encourage the victim user to start this reconfiguration process even when it wasn’t needed.

So I sent them another email:

Thank you for your response an, but I respectfully disagree.

There are methods in a closed ecosystem to perform key exchange. For example, the software on the Homey could be instructed to use knowledge of an Athom internal Root Certificate Authority to perform Homey to Smart-phone authentication, and the user’s smart-phone could be issued with an identity that is cryptographically derived from Athom’s internal CA and as such can be trusted by the device.

This then provides encrypted comms between Homey and the Smart phone which is already a big step-up. In theory though, this could be subjected to a Man-in-the-Middle attack. For example, where another user with a legitimate certificate could trick the victim Homey and the victim smart-phone into communicating with the attacker. To prevent this circumstance it would be best to have mutual authentication, but that is very difficult to achieve with devices that have already been deployed. There is a solution though – either Diffie Hellman key exchange (DH KX) which reveals an active attacker the moment they stop intercepting communications, or a variant of DH KX called STS (Station to Station)…

Furthermore, the Homey does have the ability to perform out of band key validation – amongst other methods, it speaks! This would allow key exchange and validation to be completed in the same manner as Bluetooth key exchange is completed with a PIN number.

I’m also worried about your analysis of the risk involved – just because this only happens during setup and that there must be user interaction does not make it immune to problems. For example, it is perfectly possible for an active attacker within RF range to perform a de-authentication attack against the device until the user chooses to reset it. Granted that when calculating its CVSS, having user interaction does reduce the score, but, I would suggest the result is still relatively high at approximately 5.0, with a vector of CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. This is owing to the ability of the attacker to not only intercept the communications which reveals the WiFi network key that in turn changes the scope of the attack, but also, because there is also the possibility of an integrity issue, such that at attacker could get the Homey device to connect to a malicious WiFi network and thus be able to perform other attacks against the device.

And finally, I don’t consider your assertion that “other people do this too” an adequate defence to your own lack of security. Just because it is done elsewhere does not make it right.

Please reconsider your position. I would be delighted to be of further help.

They were gracious enough to send me another response:

I do agree with some of the points you make, however, at this time we do not have the capacity to change Homey’s behavior during Wi-Fi setup. While you are technically right, we deem the attack vector to be small enough to be acceptable.

In any future products we will consider your findings.

As of this date, no fix for this is in place which is disappointing. You can find The official CVE for this issue by clicking here:

Learn how YGHT can help you imrpove your cybersecurity