Login
Virtual private networking (VPN) companies market their services as a way to prevent anyone from snooping on your Internet usage. But new research suggests this is a dangerous assumption when connecting to a VPN via an untrusted network, because attackers on the same network could force a target’s traffic off of the protection provided by their VPN without triggering any alerts to the user.
Image: Shutterstock.
When a device initially tries to connect to a network, it broadcasts a message to the entire local network stating that it is requesting an Internet address. Normally, the only system on the network that notices this request and replies is the router responsible for managing the network to which the user is trying to connect.
The machine on a network responsible for fielding these requests is called a Dynamic Host Configuration Protocol (DHCP) server, which will issue time-based leases for IP addresses. The DHCP server also takes care of setting a specific local address — known as an Internet gateway — that all connecting systems will use as a primary route to the Web.
VPNs work by creating a virtual network interface that serves as an encrypted tunnel for communications. But researchers at Leviathan Security say they’ve discovered it’s possible to abuse an obscure feature built into the DHCP standard so that other users on the local network are forced to connect to a rogue DHCP server.
“Our technique is to run a DHCP server on the same network as a targeted VPN user and to also set our DHCP configuration to use itself as a gateway,” Leviathan researchers Lizzie Moratti and Dani Cronce wrote. “When the traffic hits our gateway, we use traffic forwarding rules on the DHCP server to pass traffic through to a legitimate gateway while we snoop on it.”
The feature being abused here is known as DHCP option 121, and it allows a DHCP server to set a route on the VPN user’s system that is more specific than those used by most VPNs. Abusing this option, Leviathan found, effectively gives an attacker on the local network the ability to set up routing rules that have a higher priority than the routes for the virtual network interface that the target’s VPN creates.
“Pushing a route also means that the network traffic will be sent over the same interface as the DHCP server instead of the virtual network interface,” the Leviathan researchers said. “This is intended functionality that isn’t clearly stated in the RFC [standard]. Therefore, for the routes we push, it is never encrypted by the VPN’s virtual interface but instead transmitted by the network interface that is talking to the DHCP server. As an attacker, we can select which IP addresses go over the tunnel and which addresses go over the network interface talking to our DHCP server.”
Leviathan found they could force VPNs on the local network that already had a connection to arbitrarily request a new one. In this well-documented tactic, known as a DHCP starvation attack, an attacker floods the DHCP server with requests that consume all available IP addresses that can be allocated. Once the network’s legitimate DHCP server is completely tied up, the attacker can then have their rogue DHCP server respond to all pending requests.
“This technique can also be used against an already established VPN connection once the VPN user’s host needs to renew a lease from our DHCP server,” the researchers wrote. “We can artificially create that scenario by setting a short lease time in the DHCP lease, so the user updates their routing table more frequently. In addition, the VPN control channel is still intact because it already uses the physical interface for its communication. In our testing, the VPN always continued to report as connected, and the kill switch was never engaged to drop our VPN connection.”
The researchers say their methods could be used by an attacker who compromises a DHCP server or wireless access point, or by a rogue network administrator who owns the infrastructure themselves and maliciously configures it. Alternatively, an attacker could set up an “evil twin” wireless hotspot that mimics the signal broadcast by a legitimate provider.
Bill Woodcock is executive director at Packet Clearing House, a nonprofit based in San Francisco. Woodcock said Option 121 has been included in the DHCP standard since 2002, which means the attack described by Leviathan has technically been possible for the last 22 years.
“They’re realizing now that this can be used to circumvent a VPN in a way that’s really problematic, and they’re right,” Woodcock said.
Woodcock said anyone who might be a target of spear phishing attacks should be very concerned about using VPNs on an untrusted network.
“Anyone who is in a position of authority or maybe even someone who is just a high net worth individual, those are all very reasonable targets of this attack,” he said. “If I were trying to do an attack against someone at a relatively high security company and I knew where they typically get their coffee or sandwich at twice a week, this is a very effective tool in that toolbox. I’d be a little surprised if it wasn’t already being exploited in that way, because again this isn’t rocket science. It’s just thinking a little outside the box.”
Successfully executing this attack on a network likely would not allow an attacker to see all of a target’s traffic or browsing activity. That’s because for the vast majority of the websites visited by the target, the content is encrypted (the site’s address begins with https://). However, an attacker would still be able to see the metadata — such as the source and destination addresses — of any traffic flowing by.
KrebsOnSecurity shared Leviathan’s research with John Kristoff, founder of dataplane.org and a PhD candidate in computer science at the University of Illinois Chicago. Kristoff said practically all user-edge network gear, including WiFi deployments, support some form of rogue DHCP server detection and mitigation, but that it’s unclear how widely deployed those protections are in real-world environments.
“However, and I think this is a key point to emphasize, an untrusted network is an untrusted network, which is why you’re usually employing the VPN in the first place,” Kristoff said. “If [the] local network is inherently hostile and has no qualms about operating a rogue DHCP server, then this is a sneaky technique that could be used to de-cloak some traffic – and if done carefully, I’m sure a user might never notice.”
According to Leviathan, there are several ways to minimize the threat from rogue DHCP servers on an unsecured network. One is using a device powered by the Android operating system, which apparently ignores DHCP option 121.
Relying on a temporary wireless hotspot controlled by a cellular device you own also effectively blocks this attack.
“They create a password-locked LAN with automatic network address translation,” the researchers wrote of cellular hot-spots. “Because this network is completely controlled by the cellular device and requires a password, an attacker should not have local network access.”
Leviathan’s Moratti said another mitigation is to run your VPN from inside of a virtual machine (VM) — like Parallels, VMware or VirtualBox. VPNs run inside of a VM are not vulnerable to this attack, Moratti said, provided they are not run in “bridged mode,” which causes the VM to replicate another node on the network.
In addition, a technology called “deep packet inspection” can be used to deny all in- and outbound traffic from the physical interface except for the DHCP and the VPN server. However, Leviathan says this approach opens up a potential “side channel” attack that could be used to determine the destination of traffic.
“This could be theoretically done by performing traffic analysis on the volume a target user sends when the attacker’s routes are installed compared to the baseline,” they wrote. “In addition, this selective denial-of-service is unique as it could be used to censor specific resources that an attacker doesn’t want a target user to connect to even while they are using the VPN.”
Moratti said Leviathan’s research shows that many VPN providers are currently making promises to their customers that their technology can’t keep.
“VPNs weren’t designed to keep you more secure on your local network, but to keep your traffic more secure on the Internet,” Moratti said. “When you start making assurances that your product protects people from seeing your traffic, there’s an assurance or promise that can’t be met.”
A copy of Leviathan’s research, along with code intended to allow others to duplicate their findings in a lab environment, is available here.
In December 2021, Google filed a civil lawsuit against two Russian men thought to be responsible for operating Glupteba, one of the Internet’s largest and oldest botnets. The defendants, who initially pursued a strategy of counter suing Google for interfering in their sprawling cybercrime business, later brazenly offered to dismantle the botnet in exchange for payment from Google. The judge in the case was not amused, found for the plaintiff, and ordered the defendants and their U.S. attorney to pay Google’s legal fees.
A slide from a talk given in Sept. 2022 by Google researcher Luca Nagy. https://www.youtube.com/watch?v=5Gz6_I-wl0E&t=6s
Glupteba is a rootkit that steals passwords and other access credentials, disables security software, and tries to compromise other devices on the victim network — such as Internet routers and media storage servers — for use in relaying spam or other malicious traffic.
Collectively, the tens of thousands of systems infected with Glupteba on any given day feed into a number of major cybercriminal businesses: The botnet’s proprietors sell the credential data they steal, use the botnet to place disruptive ads on the infected computers, and mine cryptocurrencies. Glupteba also rents out infected systems as “proxies,” directing third-party traffic through the infected devices to disguise the origin of the traffic.
In June 2022, KrebsOnSecurity showed how the malware proxy services RSOCKS and AWMProxy were entirely dependent on the Glupteba botnet for fresh proxies, and that the founder of AWMProxy was Dmitry Starovikov — one of the Russian men named in Google’s lawsuit.
Google sued Starovikov and 15 other “John Doe” defendants, alleging violations of the Racketeer Influenced and Corrupt Organizations Act (RICO), the Computer Fraud and Abuse Act, trademark and unfair competition law, and unjust enrichment.
In June, Google and the named defendants agreed that the case would proceed as a nonjury action because Google had withdrawn its claim for damages — seeking only injunctive relief to halt the operations of the botnet.
The defendants, who worked for a Russian firm called “Valtron” that was also named in the lawsuit, told Google that they were interested in settling. The defendants said they could potentially help Google by taking the botnet offline.
Another slide from Google researcher Luca Nagy’s September 2022 talk on Glupteba.
But the court expressed frustration that the defendants were unwilling to consent to a permanent injunction, and at the same time were unable to articulate why an injunction forbidding them from engaging in unlawful activities would pose a problem.
“The Defendants insisted that they were not engaged in criminal activity, and that any alleged activity in which they were engaged was legitimate,” U.S. District Court Judge Denise Cote wrote. “Nevertheless, the Defendants resisted entry of a permanent injunction, asserting that Google’s use of the preliminary injunction had disrupted their normal business operations.”
While the defendants represented that they had the ability to dismantle the Glupteba botnet, when it came time for discovery — the stage in a lawsuit where both parties can compel the production of documents and other information pertinent to their case — the attorney for the defendants told the court his clients had been fired by Valtron in late 2021, and thus no longer had access to their work laptops or the botnet.
The lawyer for the defendants — New York-based cybercrime defense attorney Igor Litvak — told the court he first learned about his clients’ termination from Valtron on May 20, a fact Judge Cote said she found “troubling” given statements he made to the court after that date representing that his clients still had access to the botnet.
The court ultimately suspended the discovery process against Google, saying there was reason to believe the defendants sought discovery only “to learn whether they could circumvent the steps Google has taken to block the malware.”
On September 6, Litvak emailed Google that his clients were willing to discuss settlement.
“The parties held a call on September 8, at which Litvak explained that the Defendants would be willing to provide Google with the private keys for Bitcoin addresses associated with the Glupteba botnet, and that they would promise not to engage in their alleged criminal activity in the future (without any admission of wrongdoing),” the judge wrote.
“In exchange, the Defendants would receive Google’s agreement not to report them to law enforcement, and a payment of $1 million per defendant, plus $110,000 in attorney’s fees,” Judge Cote continued. “The Defendants stated that, although they do not currently have access to the private keys, Valtron would be willing to provide them with the private keys if the case were settled. The Defendants also stated that they believe these keys would help Google shut down the Glupteba botnet.”
Google rejected the defendants’ offer as extortionate, and reported it to law enforcement. Judge Cote also found Litvak was complicit in the defendants’ efforts to mislead the court, and ordered him to join his clients in paying Google’s legal fees.
“It is now clear that the Defendants appeared in this Court not to proceed in good faith to defend against Google’s claims but with the intent to abuse the court system and discovery rules to reap a profit from Google,” Judge Cote wrote.
Litvak has filed a motion to reconsider (PDF), asking the court to vacate the sanctions against him. He said his goal is to get the case back into court.
“The judge was completely wrong to issue sanctions,” Litvak said in an interview with KrebsOnSecurity. “From the beginning of the case, she acted as if she needed to protect Google from something. If the court does not decide to vacate the sanctions, we will have to go to the Second Circuit (Court of Appeals) and get justice there.”
In a statement on the court’s decision, Google said it will have significant ramifications for online crime, and that since its technical and legal attacks on the botnet last year, Google has observed a 78 percent reduction in the number of hosts infected by Glupteba.
“While Glupteba operators have resumed activity on some non-Google platforms and IoT devices, shining a legal spotlight on the group makes it less appealing for other criminal operations to work with them,” reads a blog post from Google’s General Counsel Halimah DeLaine Prado and vice president of engineering Royal Hansen. “And the steps [Google] took last year to disrupt their operations have already had significant impact.”
A report from the Polish computer emergency response team (CERT Orange Polksa) found Glupteba was the biggest malware threat in 2021.
On December 7, 2021, Google announced it was suing two Russian men allegedly responsible for operating the Glupteba botnet, a global malware menace that has infected millions of computers over the past decade. That same day, AWM Proxy — a 14-year-old anonymity service that rents hacked PCs to cybercriminals — suddenly went offline. Security experts had long seen a link between Glupteba and AWM Proxy, but new research shows AWM Proxy’s founder is one of the men being sued by Google.
AWMproxy, the storefront for renting access to infected PCs, circa 2011.
Launched in March 2008, AWM Proxy quickly became the largest service for crooks seeking to route their malicious Web traffic through compromised devices. In 2011, researchers at Kaspersky Lab showed that virtually all of the hacked systems for rent at AWM Proxy had been compromised by TDSS (a.k.a TDL-4 and Alureon), a stealthy “rootkit” that installs deep within infected PCs and loads even before the underlying Windows operating system boots up.
In March 2011, security researchers at ESET found TDSS was being used to deploy Glupteba, another rootkit that steals passwords and other access credentials, disables security software, and tries to compromise other devices on the victim’s network — such as Internet routers and media storage servers — for use in relaying spam or other malicious traffic.
A report from the Polish computer emergency response team (CERT Orange Polksa) found Glupteba was by far the biggest malware threat in 2021.
Like its predecessor TDSS, Glupteba is primarily distributed through “pay-per-install” or PPI networks, and via traffic purchased from traffic distribution systems (TDS). Pay-per-install networks try to match cybercriminals who already have access to large numbers of hacked PCs with other crooks seeking broader distribution of their malware.
In a typical PPI network, clients will submit their malware—a spambot or password-stealing Trojan, for example —to the service, which in turn charges per thousand successful installations, with the price depending on the requested geographic location of the desired victims. One of the most common ways PPI affiliates generate revenue is by secretly bundling the PPI network’s installer with pirated software titles that are widely available for download via the web or from file-sharing networks.
An example of a cracked software download site distributing Glupteba. Image: Google.com.
Over the past decade, both Glupteba and AWM Proxy have grown substantially. When KrebsOnSecurity first covered AWM Proxy in 2011, the service was selling access to roughly 24,000 infected PCs scattered across dozens of countries. Ten years later, AWM Proxy was offering 10 times that number of hacked systems on any given day, and Glupteba had grown to more than one million infected devices worldwide.
There is also ample evidence to suggest that Glupteba may have spawned Meris, a massive botnet of hacked Internet of Things (IoT) devices that surfaced in September 2021 and was responsible for some of the largest and most disruptive distributed denial-of-service (DDoS) attacks the Internet has ever seen.
But on Dec. 7, 2021, Google announced it had taken technical measures to dismantle the Glupteba botnet, and filed a civil lawsuit (PDF) against two Russian men thought to be responsible for operating the vast crime machine. AWM Proxy’s online storefront disappeared that same day.
AWM Proxy quickly alerted its customers that the service had moved to a new domain, with all customer balances, passwords and purchase histories seamlessly ported over to the new home. However, subsequent takedowns targeting AWM Proxy’s domains and other infrastructure have conspired to keep the service on the ropes and frequently switching domains ever since.
Earlier this month, the United States, Germany, the Netherlands and the U.K. dismantled the “RSOCKS” botnet, a competing proxy service that had been in operation since 2014. KrebsOnSecurity has identified the owner of RSOCKS as a 35-year-old from Omsk, Russia who runs the world’s largest forum catering to spammers.
The employees who kept things running for RSOCKS, circa 2016.
Shortly after last week’s story on the RSOCKS founder, I heard from Riley Kilmer, co-founder of Spur.us, a startup that tracks criminal proxy services. Kilmer said RSOCKS was similarly disabled after Google’s combined legal sneak attack and technical takedown targeting Glupteba.
“The RSOCKS website gave you the estimated number of proxies in each of their subscription packages, and that number went down to zero on Dec. 7,” Kilmer said. “It’s not clear if that means the services were operated by the same people, or if they were just using the same sources (i.e., PPI programs) to generate new installations of their malware.”
Kilmer said each time his company tried to determine how many systems RSOCKS had for sale, they found each Internet address being sold by RSOCKS was also present in AWM Proxy’s network. In addition, Kilmer said, the application programming interfaces (APIs) used by both services to keep track of infected systems were virtually identical, once again suggesting strong collaboration.
“One hundred percent of the IPs we got back from RSOCKS we’d already identified in AWM,” Kilmer said. “And the IP port combinations they give you when you access an individual IP were the same as from AWM.”
In 2011, KrebsOnSecurity published an investigation that identified one of the founders of AWM Proxy, but Kilmer’s revelation prompted me to take a fresh look at the origins of this sprawling cybercriminal enterprise to determine if there were additional clues showing more concrete links between RSOCKS, AWM Proxy and Glupteba.
Supporting Kilmer’s theory that AWM Proxy and RSOCKS may simply be using the same PPI networks to spread, further research shows the RSOCKS owner also had an ownership stake in AD1[.]ru, an extremely popular Russian-language pay-per-install network that has been in operation for at least a decade.
Google took aim at Glupteba in part because its owners were using the botnet to divert and steal vast sums in online advertising revenue. So it’s more than a little ironic that the critical piece of evidence linking all of these operations begins with a Google Analytics code included in the HTML code for the original AWM Proxy back in 2008 (UA-3816536).
That analytics code also was present on a handful of other sites over the years, including the now-defunct Russian domain name registrar Domenadom[.]ru, and the website web-site[.]ru, which curiously was a Russian company operating a global real estate appraisal business called American Appraisal.
Two other domains connected to that Google Analytics code — Russian plastics manufacturers techplast[.]ru and tekhplast.ru — also shared a different Google Analytics code (UA-1838317) with web-site[.]ru and with the domain “starovikov[.]ru.”
The name on the WHOIS registration records for the plastics domains is an “Alexander I. Ukraincki,” whose personal information also is included in the domains tpos[.]ru and alphadisplay[.]ru, both apparently manufacturers of point-of-sale payment terminals in Russia.
Constella Intelligence, a security firm that indexes passwords and other personal information exposed in past data breaches, revealed dozens of variations on email addresses used by Alexander I. Ukraincki over the years. Most of those email addresses start with some variation of “uai@” followed by a domain from one of the many Russian email providers (e.g., yandex.ru, mail.ru). [Full disclosure: Constella is currently an advertiser on this website].
But Constella also shows those different email addresses all relied on a handful of passwords — most commonly “2222den” and “2222DEN.” Both of those passwords have been used almost exclusively in the past decade by the person who registered more than a dozen email addresses with the username “dennstr.”
The dennstr identity leads to several variations on the same name — Denis Strelinikov, or Denis Stranatka, from Ukraine, but those clues ultimately led nowhere promising. And maybe that was the point.
Things began looking brighter after I ran a search in DomainTools for web-site[.]ru’s original WHOIS records, which shows it was assigned in 2005 to a “private person” who used the email address lycefer@gmail.com. A search in Constella on that email address says it was used to register nearly two dozen domains, including starovikov.ru and starovikov[.]com.
A cached copy of the contact page for Starovikov[.]com shows that in 2008 it displayed the personal information for a Dmitry Starovikov, who listed his Skype username as “lycefer.”
Finally, Russian incorporation documents show the company LLC Website (web-site[.]ru)was registered in 2005 to two men, one of whom was named Dmitry Sergeevich Starovikov.
Bringing this full circle, Google says Starovikov is one of the two operators of the Glupteba botnet:
The cover page for Google’s lawsuit against the alleged Glupteba botnet operators.
Mr. Starovikov did not respond to requests for comment. But attorneys for Starovikov and his co-defendant last month filed a response to Google’s complaint in the Southern District of New York, denying (PDF) their clients had any knowledge of the scheme.
Despite all of the disruption caused by Google’s legal and technical meddling, AWM is still around and nearly as healthy as ever, although the service has been branded with a new name and there are dubious claims of new owners. Advertising customer plans ranging from $50 a day to nearly $700 for “VIP access,” AWM Proxy says its malware has been running on approximately 175,000 systems worldwide over the last 24 hours, and that roughly 65,000 of these systems are currently online.
AWM Proxy, as it exists today.
Meanwhile, the administrators of RSOCKS recently alerted customers that the service and any unspent balances will soon be migrated over to a new location.
Many people seem to equate spending time, money and effort to investigate and prosecute cybercriminals with the largely failed war on drugs, meaning there is an endless supply of up-and-coming crooks who will always fill in any gaps in the workforce whenever cybercriminals face justice.
While that may be true for many low-level cyber thieves today, investigations like these show once again how small the cybercriminal underground really is. It also shows how it makes a great deal of sense to focus efforts on targeting and disrupting the relatively small number of established hackers who remain the real force multipliers of cybercrime.
FreshRSS 