Special text characters can be weaponized by malicious attackers, allowing them to set up malicious WiFi networks with names that appear to perfectly match the Service Set Identifiers (SSIDs) of legitimate networks, but are actually different.
In a blog post published earlier this month, researchers at AirEye warned that a newly discovered technique called “SSID Stripping” would allow adversaries to fool device users into logging into an attacker-controlled network that they mistakenly believe is their own corporate office network.
The technique is essentially the wireless cousin of a so-called homograph attack, whereby malicious actors use Punycode or foreign-language characters to create URLs that convincingly appear to be genuine corporate domains, but actually lead to phishing sites if a user is tricked into clicking on a link. The difference here is that SSID Stripping results in victims joining a malicious WiFi network, through which attackers can implant malware, spy on users and/or take over devices.
Using special characters, especially “non-printable” characters, researchers at AirEye and the Technion – Israeli Institute of Technology were able to craft SSIDs – a fancy way of saying WiFi network names – that, when appearing on a device’s list of available networks, looks deceivingly normal, because the strange characters, while still present, do not visibly appear.
AirEye found the technique worked on Apple’s Macs and iPhones, Microsoft Windows-based computers, Android phones and Ubuntu Linux computers. According to AirEye, none of the affected devices’ developers has fixed the problem yet, though Apple and Microsoft said they would, while the others do not recognize the issue as a serious security problem. SC Media reached out to all four developers to confirm this account. A Microsoft spokesperson responded, saying: “A user would need to be tricked into connecting to a rogue network for this technique to be successful. We encourage customers to practice good computing habits online. For more information on how to safe over wireless connections please visit: Be safer over wireless connections (microsoft.com).”
Amichai Shulman, CTO and co-founder of AirEye, told SC Media in an interview on Wednesday that the company first began working on related research roughly six months ago, but the project got a particular boost last July after the disclosure of an iOS WiFi format-string bug involving the processing of SSID, that could result the disabling of WiFi functionality.
Shulman spoke to SC Media to address the potential consequences of the SSID Stripping threat, what course of device manufacturers might want to take to prevent malicious actors from taking advantage, and how wireless threats, in his opinion, often take a back seat to other forms of threats.
How did this research project come about?
I started this specific research into a method that would hide the true name of a network, almost six months ago. What made us push forward and give some more emphasis on this research, is the release of the Apple format string vulnerability, a couple of months ago. And it all started by in a tweet by someone who [essentially] said, “Hey, look at this nice prank. I can crash the iPhone WiFi with a strange network name.” And we realized and it was proven later that it was far more than a simple prank; it was actually a vulnerability that would make someone take [the device] over. But the question was: Why would someone even click on this strange network name? And we said there must be a way to hide the real network name from the user. And that put more emphasis on this research.
Would you agree that this is in essence another form of homograph attack, much like using Punycode to create lookalike web domains?
To a large degree, this is the same technique, [only] applied to wireless networks. Which is why I think it's important, because we know how well that technique works for [conventional] phishing and… the world of domains.
Think of all the anti-phishing solutions we have in browsers and wired networks. None of these in exist in wireless networks. You have all this [employee] training for detecting phishing either in email or when surfing the web. [But] no one does that on the wireless level. Because no one thought it applies there. Well, apparently it does.
What protections currently exist in devices to prevent them from connecting to rogue networks or access points? And explain why this technique that you've uncovered bypasses those defenses.
There are a few things that happen in wireless networks in particular. One thing that happens is, if you use exactly the same name with the same characteristics as the original network, then the devices only display a single entry and you cannot really have control of which of these entries will be chosen, when the user actually tries to connect.
Moreover, there are techniques today to detect what they call rogue access points which have the same name of an existing network, but are not registered with the control system, for example, as being part of the same network. If [attackers] try to publish the same network name, but with different characteristics such as lower security, then [many devices] wouldn't allow you to connect automatically, and in some cases, it would – at least on the initial attempt to access – give you a failure notification because it was expecting one type of security, but found a different type of security.
Another thing – if [an attacker’s rogue network] has the same exact name [as a legitimate network, but the adversary does] not know the password of the network [they’re] trying to imitate, then a [user’s] connection attempt would fail because [the device would] still remember the old password.
So this is basically why [attackers] need a name that is different than reality, but looks to the user as the same.
Another thing you would like is to make sure that you can control where your network appears in the [available WiFi networks] list, with respect to the network name that you're trying to imitate. Sometimes you'd like to be in before it, sometimes you like it to be after it. It depends on the device that you're trying to attack.
Using SSID Stripping, you can introduce characters that make the name different. It looks the same, and they also allow you to control sort order. Plus, of course, the additional issue that if you embed an actual exploit – the actual attack vector – in the SSID, like in the Apple [DoS and RCE] vulnerability [CVE-2021-30800], the user is not able to see.
What are the likely consequences of joining an impostor network that hid its true identity via SSID Stripping?
Most devices, when they go on a new wireless network, they are doing an internet connectivity test. That is when… whoever controls the network, can pop up what we call captive portals. You’ve probably seen that when you log into a hotel's network for the first time, when you log in to an airport network for the first time – you'll get this captive portal that pops up and they’ll give you some commercials, ads and ask you for consent, and whatnot.
That happens automatically. Which means that once a device is connected to an attacker-controlled network, the attacker can force a browser to open and run on that device and download malicious content through the browser. And that malicious content really depends on the type of device we're talking about. So, if it's an iPhone then you need some sort of a Safari exploit. If it's an Android, you’d probably need some sort of an HTML webkit or whatever exploit. If it’s for example a Windows machine, and you're able to force the browser to start… download content, there could be a browser exploit, a PDF exploit, an Office exploits, whatever.
And people [might think], “They will see my data, but my data is encrypted because I only use SSL. But the reality is, no. At this first point, the captive portal, you don't use SSL. You are willing to accept any content from that captive portal, and you're completely vulnerable to someone trying to take over your machine through that process. And that's the real threat when connecting to an unknown or attacker-controlled network.
I would imagine that adversaries could engage in some sort of eavesdropping or spying on a targeted company if they so choose.
If it’s an enterprise machine that was even for a split-second connected to that attacker-controlled network and then goes back to the corporate network, then you have a corporate machine infected with malware, which can then start doing lateral movement inside the organization. And because what happened, you have an attack path that does not go through any network security solution.
Now the only question that remains is: how do I get near that network that I'm targeting? And most people think ,well, I’ll find their address, and I'll just physically go there – which is not a great idea if you a Russian hacker, and you're targeting the U.S.
But then this is where the security camera across the street, comes into play. If you look at any corporation in the United States, or almost everywhere in the world, there are so many wireless devices around the corporate [office] that could be hacked remotely, because they have low security – certainly lower than the enterprise itself.
Heat vision cameras, which have remote code execution vulnerabilities published almost every month, they're very popular. They're installed everywhere. They're in building stores, in coffee shop, malls, whatever. A remote attacker could take over that heat vision camera – or it could be a home router, or whatever – and then use this device as an “antenna for hire” to be near the target.
And one of the things that we were having to demonstrate is how through public information, you get the physical address of your target network, and then look for vulnerable wireless devices in the proximity and find out whether they are vulnerable or not, find out whether they're accessible through the internet, hack them, and then use them as your wireless presence near that target network.
So then would this be the type of technique we’d most likely see in low-volume, low-frequency, highly targeted attacks?
The other way around. I talk to some of the people who are part of the nation-state threat actor community. Those people would actually go and put their device near their target – because they had a very specific target and they want 100% success.
However, if you want to be an industrialized hacker, if you want to make money, then you need volume. Think Mirai botnet. It’s a huge botnet – mostly cameras. A large proportion of them are wireless-capable. [Imagine] I own such a network. Now, I start selling pieces or raising pieces of that network to people. And I say, ‘Hey, do you want cameras in New York, because you fancy targets in New York? Do you want cameras in London? Do you want a camera that is near General Electric headquarters?”
I assume that there is a marketplace for these pieces. Usually it's not a single actor that goes and takes an operation from zero to monetization. There are layers, there is a supply chain. One part of the supply chain are those people who just created botnet, create the volume. And then people are buying that access… on the darknet… [They] don't have to start from scratch. So I think that for criminal hacking, this is going to be the method of operation.
The blog post that the device manufacturers haven’t rushed to fix the issue, and some didn’t think SSID Stripping constituted a big security issue? Why do you think that is?
I'm not surprised. I think the first instances of Punycode URL… were handled with the same approach. “What are the security implications? What could possibly go wrong?” And I think they don’t realize – and I have to say, it took me a while to realize this as well – that it really is the equivalent of [Punycode phishing] URLs. This is kind of phishing for wireless networks.
I think we as security community, do not realize yet that there's a lot of risk, about wireless, in a way that we're not used to think of... There is more to wireless security than the security protocol of your wireless network.
And I think we've seen that over the past year, we're seeing more and more severe vulnerabilities in the implementation and in sometimes the design of the wireless network communication.
What could device users and manufacturers do to protect themselves?
If you are a vigilant user and you don’t get the same user experience you're used to when connecting to a standard network, get suspicious. Try to understand why you didn't get the same user experience. Why did it not connect automatically? How many users can actually do that? I don't know.
I think that for vendors, for many of the techniques that we show, they should make the display explicit, certainly non-printable characters. I personally think that a lot of the characters… could also be either explicitly marked, or even not accepted when it comes to networks’ names.
