This Week In Security: Cisco, Mitel, And AI False Flags

April 26, 2024 by Jonathan Bennett 3 Comments

There’s a trend recently, of big-name security appliances getting used in state-sponsored attacks. It looks like Cisco is the latest victim, based on a report by their own Talos Intelligence.

This particular attack has a couple of components, and abuses a couple of vulnerabilities, though the odd thing about this one is that the initial access is still unknown. The first part of the infection is Line Dancer, a memory-only element that disables the system log, leaks the system config, captures packets and more. A couple of the more devious steps are taken, like replacing the crash dump process with a reboot, to keep the in-memory malware secret. And finally, the resident installs a backdoor in the VPN service.

There is a second element, Line Runner, that uses a vulnerability to arbitrary code from disk on startup, and then installs itself onto the device. That one is a long term command and control element, and seems to only get installed on targeted devices. The Talos blog makes a rather vague mention of a 32-byte token that gets pattern-matched, to determine an extra infection step. It may be that Line Runner only gets permanently installed on certain units, or some other particularly fun action is taken.

Fixes for the vulnerabilities that allowed for persistence are available, but again, the initial vector is still unknown. There’s a vulnerability that just got fixed, that could have been such a vulnerability. CVE-2024-20295 allows an authenticated user with read-only privileges perform a command injection as root. Proof of Concept code is out in the wild for this one, but so far there’s no evidence it was used in any attacks, including the one above. Continue reading “This Week In Security: Cisco, Mitel, And AI False Flags” →

This Week In Security: Browser Exploits, Play Protect, And Turn ON Your Firewall!

October 20, 2023 by Jonathan Bennett 5 Comments

Google Chrome has done a lot of work on JavaScript performance, pushing the V8 engine to more and more impressive feats. Recently, that optimization has one more piece, the Maglev compiler, which sits between Sparkplug and TurboFan, as a mid-tier optimization step. With a Just In Time (JIT) system, the time saving of code optimization steps has to be carefully weighed against the time costs, and Maglev is another tool in that endless hunt for speed. And with anything this complicated, there’s the occasional flaw found in the system. And of course, because we’re talking about it here, it’s a security vulnerability that results in Remote Code Execution (RCE).

The trick is to use Maglev’s optimization against it. Set up a pair of classes, such that B extends A. Calling new B() results in an attempt to use the constructor from A. Which works, because the compiler checks to make sure that the constructors match before doing so. There’s another way to call a constructor in JS, something like Reflect.construct(B, [], Array);. This calls the B constructor, but indicates that the constructor should return an Array object. You may notice, there’s no array in the A class below. Tricking the compiler into using the parent class constructor in this fashion results in the array being uninitialized, and whatever happens to be in memory will set the length of the array. Continue reading “This Week In Security: Browser Exploits, Play Protect, And Turn ON Your Firewall!” →

A modchip described in the article - a small PCB with an epoxy blob on it, soldered to the Cisco switch PCB using four thin wires

Counterfeit Cisco Hardware Bypasses Security Checks With Modchips

February 1, 2023 by Arya Voronova 32 Comments

Some pictures recently surfaced on social media, showing a small PCB tapped into four points on Cisco-branded boards. What is this about? A NSA backdoor so data can be exfiltrated to some third party? Well, that’s theoretically possible, but it’s actually used for bypassing hardware authenticity checks in Cisco hardware being cloned — a sizable industry. Of course, “can’t believe it’s not Cisco” hardware is only valuable insofar that it’s able to run the Cisco software, and that’s where the bodge boards play a major role.

A 2020 report by F-Secure details an investigation, comparing three switches marked as Cisco 2960X – one known genuine and two known counterfeits. The counterfeits had the aforementioned implants either soldered to the bottom of the PCB or added to the board as a separate component, and the paper goes into why they’re important for successful counterfeiting.

Apparently, these chips emulate or bypass an I2C EEPROM containing part of the code executed during the boot sequence, and Cisco depends on this EEPROM’s contents for authenticity verification. Cisco software reads the EEPROM twice — once for verification, and once again for actually running it. The microcontroller included on the mod board can return a genuine binary with a valid signature on the first read, and a binary with hardware checks patched out for subsequent reads.

The paper will tell you about way more than this — it’s thorough yet captivating. As you’d expect, it devotes quite a bit of time to comparing genuine and counterfeit boards, showing that the cloning process is pretty to-the-T, save for some part substitutions. For instance, check out the PDF page 12 to see how via locations are exactly copied between PCBs in a bizarre way, or the Cisco file format and authenticity check analysis closer to the end of the report. All in all, the 38 pages of the document make for a fun foray into what makes Cisco authentication mechanisms tick, and what helps clone hardware makers bypass them.

Are such chips ever used for adding backdoors and data exfiltration? There’s no evidence of that, as much as that’s not to be excluded — bypassing anti-cloning protections would make other hijinks more viable no doubt, that said, only hardware authentication bypass measures were found so far. This mechanism also breaks during software updates, and absolutely, leaves some to be desired when it comes to its stated functionality. That said, such fun insights can help us, say, enforce right-to-repair, enable hardware reuse, and thwart many predatory business practices in areas where laws fail us.

The Meraki AP PCB on a desk, case-less, with three USB-UARTs connected to its pins - one for interacting with the device, and two for monitoring both of the UART data lines.

Flashing Booby-Trapped Cisco AP With OpenWrt, The Hard Way

October 26, 2022 by Arya Voronova 48 Comments

Certain manufacturers seriously dislike open-source firmware for their devices, and this particular hack deals with quite extreme anti-hobbyist measures. The Meraki MR33, made by Cisco, is a nice access point hardware-wise, and running OpenWrt on it is wonderful – if not for the Cisco’s malicious decision to permanently brick the CPU as soon as you enter Uboot through the serial port. This AP seems to be part of a “hardware as a service” offering, and the booby-trapped Uboot was rolled out by an OTA update some time after the OpenWrt port got published.

There’s an older Uboot version available out there, but you can’t quite roll back to it and up to a certain point, there was only a JTAG downgrade path noted on the wiki – with its full description consisting of a “FIXME: describe the process” tag. Our hacker, an anonymous user from the [SagaciousSuricata] blog, decided to go a different way — lifting, dumping and modifying the onboard flash in order to downgrade the bootloader, and guides us through the entire process. There’s quite a few notable things about this hack, like use of Nix package manager to get Python 2.7 on an OS which long abandoned it, and a tip about a workable lightweight TFTP server for such work, but the flash chip part caught our eye.

The flash chip is in TSOP48 package and uses a parallel interface, and an iMX6.LL devboard was used to read, modify and flash back the image — hotswapping the chip, much like we used to do with old parallel-interface BIOS chips. We especially liked the use of FFC cables and connectors for connecting the flash chip to the devboard in a way that allows hotswapping – now that we can see it, the TSOP 0.5 mm pitch and 0.5 mm FFC hardware are a match made in heaven. This hack, of course, will fit many TSOP48-equipped devices, and it’s nice to have a toolkit for it in case you don’t have a programmer handy.

In the end, the AP got a new lease of life, now governed by its owner as opposed to Cisco’s whims. This is a handy tutorial for anyone facing a parallel-flash-equipped device where the only way appears to be the hard way, and we’re glad to see hackers getting comfortable facing such challenges, whether it’s parallel flash, JTAG or power glitching. After all, it’s great when your devices can run an OS entirely under your control – it’s historically been that you get way more features that way, but it’s also that the manufacturer can’t pull the rug from under your feet like Amazon did with its Fire TV boxes.

We thank [WifiCable] for sharing this with us!

(Ed Note: Changed instances of “OpenWRT” to “OpenWrt”.)

This Week In Security: More State-Sponsored Activity, Spring4Shell

April 1, 2022 by Jonathan Bennett 4 Comments

[Editor’s note: There is a second, fake iteration of this column out today. This is obviously the real column.]

An alert from CISA, combined with an unsealed pair of indictments, sheds some new light on how Russian hackers pursue high-value targets. The key malware here is Triton, essentially a rootkit designed for the Tricon safety systems, widely deployed at refineries and other infrastructure facilities. One of the early deployments of this was to a Saudi oil plant in 2017. This deployment seems to have been botched, as it caused malfunctions and shut the plant down for about a week.

The new information is confirmation that the same operators, out of the “Central Scientific Research Institute of Chemistry and Mechanics”, attempted to target US facilities with the same campaign. The Wired coverage initially struck me as odd, as it detailed how these Russian attackers researched US refineries, looking for the most promising targets. How exactly did US intelligence agencies know about the research habits of agents in Russia? The details of the indictment has the answer: They were researching US refineries by downloading papers from the US Department of Energy. As the IP addresses of this Russian research group is known and tracked, it was easy enough for US agencies to make the connection.

Continue reading “This Week In Security: More State-Sponsored Activity, Spring4Shell” →

Cisco Router Repair Revives Piece Of Internet History

September 13, 2021 by Tom Nardi 27 Comments

It would be fair to say that the Internet as we know it runs on Cisco hardware. While you might never see the devices first-hand, there’s an excellent chance that every web-bound packet leaving your computer or smartphone will spend at least a few milliseconds of its life traveling through hardware built by the San Jose, California based company. But of course, even a telecommunications giant like Cisco had to start somewhere.

Cisco’s first commercial router, the Advanced Gateway Server (AGS), was released in 1986 and helped put the company (and the Internet) on the path towards unfathomable success. [Andreas Semmelmann] had wanted to add one of these microwave-sized machines to his collection for some time, so when an AGS+ popped up in the local classifieds he didn’t hesitate to make the hour drive to go pick it up. But like many pieces of vintage computing equipment, it needed a little help getting back on its feet.

What 4 MB of flash looked like in the late 1980s.

Since he had to take the router apart anyway to diagnose what ailed it, [Andreas] decided to take photographs along the way and document this piece of Internet history. He walks the reader through the massive processor, Ethernet, and serial cards that are housed in the unit’s rack-like enclosure. We appreciate him taking the scenic route, as it gives us a great look inside what would have been state-of-the-art telecommunications gear when this version of the AGS hit the market in 1989.

The walk-through is full of interesting details that make us appreciate just how far things have come in the last 32 years. Imagine yanking the EPROMs out of the board and firing up the UV eraser each time you needed to update your router’s firmware. Or needing a special adapter to convert the AUI-15 connectors on the back panel to the now ubiquitous RJ45 jack.

After this stroll down memory lane, [Andreas] gets to the actual repair work. It likely won’t surprise the regular Hackaday reader to find that the power supply wasn’t operating to spec, and that some aged capacitors and a shorted rectifier diode needed to be replaced to put it back on an even keel. But even with the PSU repaired, the router failed to start. The console output indicated the software was crashing, but hardware diagnostics showed no obvious faults.

Replacing these failed PSU components was just the beginning.

With some part swapping, firmware flashing, and even a bit of assistance from Cisco luminary [Phillip Remaker], the issue was eventually identified as a faulty environmental monitoring (ENVM) card installed in the AGS+. As luck would have it the ENVM capability isn’t required to boot the router, so [Andreas] was able to just disconnect the card and continue on with his exploration of the hardware that helped build the Internet as we know it.

Considering its age, this piece of 1980s Cisco gear ended up being in relatively good shape. But that’s not always the case. Over the years we’ve found ourselves in awe of the incredible amount of time, effort, and skill, it takes to restore some of these classic machines. We have great respect for the dedicated individuals who are willing to take on the challenge of keeping these pieces of history up and running for future generations to marvel at.

[Thanks to Bob for the tip.]

This Week In Security: Pwn2own, Zoom Zero Day, Clubhouse Data, And An FBI Hacking Spree

April 16, 2021 by Jonathan Bennett 11 Comments

Our first story this week comes courtesy of the Pwn2own contest. For anyone not familiar with it, this event is held twice a year, and features live demonstrations of exploits against up-to-date software. The one exception to this is when a researcher does a coordinated release with the vendor, and the update containing the fix drops just before the event. This time, the event was held virtually, and the attempts are all available on Youtube. There were 23 attacks attempted, and only two were outright failures. There were 5 partial successes and 16 full successes.

One of the interesting demonstrations was a zero-click RCE against Zoom. This was a trio of vulnerabilities chained into a single attack. The only caveat is that the attack must come from an accepted contact. Pwn2Own gives each exploit attempt twenty minutes total, and up to three attempts, each of which can last up to five minutes. Most complex exploits have an element of randomness, and exploits known to work sometimes don’t work every time. The Zoom demonstration didn’t work the first time, and the demonstration team took enough time to reset, they only had enough time for one more try.

BleedingTooth

We first covered BleedingTooth almost exactly six months ago. The details were sparse then, but enough time has gone by to get the full report. BleedingTooth is actually a trio of vulnerabilities, discovered by [Andy Nguyen]. The first is BadVibes, CVE-2020-24490. It’s a lack of a length check in the handling of incoming Bluetooth advertisement packets. This leads to a buffer overflow. The catch here is that the vulnerability is only possible over Bluetooth 5. Continue reading “This Week In Security: Pwn2own, Zoom Zero Day, Clubhouse Data, And An FBI Hacking Spree” →