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

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

[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

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

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”

This Week In Security: Google Photos, Whatsapp, And Doom On Deskphones

Google Photos is handy. You take pictures and videos on your cell phone, and they automatically upload to the cloud. If you’re anything like me, however, every snap comes with a self-reminder that “the cloud” is a fancy name for someone else’s server. What could possibly go wrong? How about some of your videos randomly included in another user’s downloads?

Confirmed by Google themselves, this bug hit those using Google Takeout, the service that allows you to download all your data from a Google application, as a single archive. Google Photos archives downloaded between November 21 and November 25 may contain videos from other users, according to a notice sent to the users who downloaded said archives. It’s notable that those notices haven’t been sent to users who’s videos were exposed.
Continue reading “This Week In Security: Google Photos, Whatsapp, And Doom On Deskphones”

This Week In Security: Windows 10 Apocalypse, Paypal Problems, And Cablehaunt

Nicely timed to drop on the final day of Windows 7 support, Windows 10 received a fix to an extremely serious flaw in crypt32.dll. This flaw was reported by the good guys at the NSA. (We know it was the good guys, because they reported it rather than used it to spy on us.) It’s really bad. If you’re running Windows 10, go grab the update now. OK, you’re updated? Good, let’s talk about it now.

The flaw applies to X.509 keys that use elliptic curve cryptography. We’ve discussed ECC in the past, but let’s review. Public key encryption is based on the idea that some calculations are very easy to perform and verify, but extremely difficult to calculate the reverse operation.

The historic calculation is multiplying large primes, as it’s unreasonably difficult to factorize that result by a conventional computer. A true quantum computer with enough qubits will theoretically be able to factorize those numbers much quicker than a classical computer, so the crypto community has been searching for a replacement for years. The elliptic curve is the solution that has become the most popular. An agreed-upon curve and initial vector are all that is needed to perform the ECC calculation.

There are potential weaknesses in ECC. One such weakness is that not all curves are created equal. A well constructed curve results in good cryptography, but there are weak curves that result in breakable encryption.

With that foundation laid, the flaw itself is relatively easy to understand. An X.509 certificate can define its own curve. The Windows 10 implementation doesn’t properly check the curve that is specified. A malicious curve is specified that is similar to the expected curve — similar enough that the checks in crypt32 don’t catch it. Continue reading “This Week In Security: Windows 10 Apocalypse, Paypal Problems, And Cablehaunt”

Old Cisco WAN Card Turned FPGA Playground

Many of us think of FPGAs as some new cutting edge technology, but the fact of the matter is that they’ve been around for quite some time. They’ve just traditionally been used in hardware that’s too expensive for us lowly hackers. A case in point is the Cisco HWIC-3G-CDMA WAN card. A decade ago these would have been part of a router valued in the tens of thousands of dollars, but today they can be had for less than $10 USD on eBay. At that price, [Tom Verbeure] thought it would be worth finding out if they could be repurposed as generic FPGA experimentation devices.

So as not to keep you in suspense, the short answer is a resounding yes. In the end, all [Tom] had to do was figure out what voltages the HWIC-3G-CDMA was expecting on the edge connector, and solder a 2×5 connector onto the helpfully labeled JTAG header. Once powered up and connected to the computer, Intel’s Quartus Programmer software immediately picked up the board’s Cyclone II EP2C35F484C8 chip. The blinking LEDs seen in the video after the break serve as proof that these bargain bin gadgets are ripe for hacking.

Unfortunately, there’s a catch. After studying the rest of the components on the board, [Tom] eventually came to the conclusion that the HWIC-3G-CDMA has no means of actually storing the FPGA’s bitstream. Presumably it was provided by the router itself during startup. If you just want to keep the board tethered to your computer for experimenting, that’s not really a big deal. But if you want to use it in some kind of project, you’ll need to include a microcontroller capable of pushing the roughly 1 MB bitstream into the FPGA to kick things off.

It might not be as easy to get up and running as the 2019 Hackaday Superconference badge, but it’s certainly a lot easier to get your hands on.

Continue reading “Old Cisco WAN Card Turned FPGA Playground”