Hackers leverage flaw in Cisco switches to hit Russian, Iranian networks

The proof-of-concept exploit code for a vulnerability affecting many Cisco switches has been leveraged by vigilante hackers to mess with networks and data-centers in Russia and Iran.

Who has been hit?

According to Kaspersky Lab researchers, after exploiting the flaw the attackers are able to run code that allows them to rewrite the Cisco IOS image on the switches and change the configuration file, leaving a message that reads “Do not mess with our elections.”

“It seems that there’s a bot that is searching for vulnerable Cisco switches via the IoT search engine Shodan and exploiting the vulnerability in them (or, perhaps, it might be using Cisco’s own utility that is designed to search for vulnerable switches). Once it finds a vulnerable switch, it exploits the Smart Install Client, rewrites the config – and thus takes another segment of the Internet down,” they noted.

“That results in some data centers being unavailable, and that, in turn, results in some popular sites being down.”

The Iranian Communication and Information Technology Ministry confirmed that some 3,500 switches in the country have been affected by the attack, but also that 200,000 router switches across the world have been hit.

“Some 55,000 devices were affected in the United States and 14,000 in China, and Iran’s share of affected devices was 2 percent,” said Iran’s IT Minister Mohammad Javad Azari-Jahromi.

Who’s behing the attack?

The attackers left a contact email address in the message and Motherboard managed to get in touch with them.

Apparently, the idea was to retaliate for “attacks from government-backed hackers on the United States and other countries.”

Also, they claim to have fixed the vulnerability on exposed devices in the US and UK by running the command no vstack on the affected device, in an attempt to stave off future attacks. But a more recent Shodan search shows that the number of exposed devices has only slightly decreased.

What now?

Cisco has released security updates that fix the issue last week, but obviously many administrators did not get to implementing them before the attacks happened.

The company has also provided mitigation advice that includes running the no vstack command or, if that option isn’t available, restricting access to port 4786 via an access control list for the interface.