Using Ghidra To Extract A Router Configuration Encryption Key

Who doesn’t know the struggle? Buying an interesting piece of hardware for a song and a dance, and then finding that the device’s firmware and/or configuration file is locked down with various encryption or obfuscation methods. This was the experience [Ali Raheem] had when he got a TP-Link TL-MR3020 V3 for a mere 18 British Pounds, intending to use this 4G-capable router to increase internet reliability.

Naturally this can all be done when staying inside the vendor-provided marked lines, which in this case meant ignoring the encrypted configuration files. As the owner of the hardware, this was of course unacceptable and thus [Ali] got a firmware image from the TP-Link site to see what could be gleaned from it in terms of encryption keys and other hints.

After obtaining the TP-Link-provided BIN file, the application of binwalk helpfully extracted the files embedded in it, followed by John the ripper decrypting the passwords in the /etc/passwd.bak file, and ultimately finding the encrypted /etc/default_config.xml file. Searching for this filename string in the rest of the extracted files led to /lib/libcmm.so.

Dropping this shared library file into Ghidra to disassemble its code, [Ali] found a function suspiciously called decryptFile. Inside was a reference to the global key string, which when tossed into OpenSSL and after some fiddling turned out to decrypt the XML configuration file in des-ecdb mode. From this point dropping in one’s own configuration files should be no problem after encrypting them to make the firmware happy. Nice work!

RevK_NFC-Reader_v2-Photo

NFC Who’s At The Door

RevK_NFC_v1-Prototype-Photo
An early prototype that worked on the first try, except for one LED

[RevK] wanted to learn about NFC readers, and we agree that the best way to do so is to dive in and build one yourself.

There are readers available from multiple sources, but [RevK] found them either compact but with no prototyping space or plenty of prototyping space and a large footprint. High-speed UART (HSU) was selected over I2C for communication with an ESP32 as testing showed it was just as fast and more reliable over long distances at the cost of only one additional wire.

After a few versions, the resulting PN532 based NFC reader has just enough GPIO for a doorbell and tamper switch and three status LEDs, with board files and a 3D-printed case design included in the open source project on GitHub. When looking into the project, we appreciated learning about tamper switches that can include closed or open contact status when an NFC is read, most often used in the packaging of high-value and collectible products. If you have worked with this tamper feature of NFCs, let us know about it.

Thanks for the tip, [Simon]

This Week In Security: Print Nightmare Continues, Ransomware Goes Bigger, And ATM Jackpots!

For the second time, Microsoft has attempted and failed to patch the PrintNightmare vulnerability. Tracked initially as CVE-2021-1675, and the second RCE as CVE-2021-34527. We warned you about this last week, but a few more details are available now. The original reporter, [Yunhai Zhang] confirms our suspicions, stating on Twitter that “it seems that they just test with the test case in my report”.

Microsoft has now shipped an out-of-band patch to address the problem, with the caveat that it’s known not to be a perfect fix, but should eliminate the RCE element of the vulnerability. Except … if the server in question has the point and print feature installed, it’s probably still vulnerable. And to make it even more interesting, Microsoft says they have already seen this vulnerability getting exploited in the wild. Continue reading “This Week In Security: Print Nightmare Continues, Ransomware Goes Bigger, And ATM Jackpots!”

WiFiWart Linux Pentesting Device Gets First PCBs

When we last checked in on the WiFiWart, an ambitious project to scratch-build a Linux powered penetration testing drop box small enough to be disguised as a standard phone charger, it was still in the early planning phases. In fact, the whole thing was little more than an idea. But we had a hunch that [Walker] was tenacious enough see the project through to reality, and now less than two months later, we’re happy to report that not only have the first prototype PCBs been assembled, but a community of like minded individuals is being built up around this exciting open source project.

Now before you get too excited, we should probably say that the prototypes didn’t actually work. Even worse, the precious Magic Smoke was released from the board’s Allwinner A33 ARM SoC when a pin only rated for 2.75 V was inadvertently fed 3.3 V. The culprit? Somehow [Walker] says he mistakenly ordered a 3.3 V regulator even though he had the appropriate 2.5 V model down in the Bill of Materials. A bummer to be sure, but that’s what prototypes are for.

Even though [Walker] wasn’t able to fire the board up, the fact that they even got produced shows just how much progress has been made in a relatively short amount of time. A lot of thought went into how the 1 GB DDR3 RAM would get connected to the A33, which includes a brief overview of how you do automatic trace length matching in KiCad. He’s also locked in component selections, such as the RTL8188CUS WiFi module, that were still being contemplated as of our last update.

Multiple boards make better use of vertical space.

Towards the end of the post, he even discusses the ultimate layout of the board, as the one he’s currently working on is just a functional prototype and would never actually fit inside of a phone charger. It sounds like the plan is to make use of the vertical real estate within the plastic enclosure of the charger, rather than trying to cram everything into a two dimensional design.

Want to get in on the fun, or just stay updated as [Walker] embarks on this epic journey? Perhaps you’d be interested in joining the recently formed Open Source Security Hardware Discord server he’s spun up. Whether you’ve got input on the design, or just want to hang out and watch the WiFiWart get developed, we’re sure he’d be happy to have you stop by.

The first post about this project got quite a response from Hackaday readers, and for good reason. While many in the hacking and making scene only have a passing interest in the security side of things, we all love our little little Linux boards. Especially ones that are being developed in the open.

This Week In Security: Bad Signs From Microsoft, An Epyc VM Escape

Code signing is the silver bullet that will save us from malware, right? Not so much, particularly when vendors can be convinced to sign malicious code. Researchers at G DATA got a hit on a Windows kernel driver, indicating it might be malicious. That seemed strange, since the driver was properly signed by Microsoft. Upon further investigation, it became clear that this really was malware. The file was reported to Microsoft, the signature revoked, and the malware added to the Windows Defender definitions.

The official response from Microsoft is odd. They start off by assuring everyone that their driver signing process wasn’t actually compromised, like you would. The next part is weird. Talking about the people behind the malware: “The actor’s goal is to use the driver to spoof their geo-location to cheat the system and play from anywhere. The malware enables them to gain an advantage in games and possibly exploit other players by compromising their accounts through common tools like keyloggers.” This doesn’t seem to really match the observed behavior of the malware — it seemed to be decoding SSL connections and sending the data to the C&C server. We’ll update you if we hear anything more on this one.
Continue reading “This Week In Security: Bad Signs From Microsoft, An Epyc VM Escape”

This Week In Security: Schemeflood, Modern Wardialing, And More!

There’s been yet another technique discovered to fingerprint users, and this one can even work in the Tor browser. Scheme flooding works by making calls to application URLs, something like steam://browsemedia. If your machine supports the requested custom URL, a pop-up is displayed, asking permission to launch the external application. That pop-up can be detected by JavaScript in the browser. Detect enough apps, and you can build a reasonable fingerprint of the system the test is run on. Unlike some previous fingerprinting techniques, this one isn’t browser dependent — it will theoretically give the same results for any browser. This means even the Tor browser, or any browser being used over the Tor network, can give your potentially unique set of installed programs away.

Now for the good news. The Chrome devs are already working on this issue, and in fact, Chrome on my Linux desktop didn’t respond to the probes in a useful way. Feel free to check out the demo, and see if the results are accurate. And as for Tor, you really should be running that on a dedicated system or in a VM if you really need to stay anonymous. And disable JavaScript if you don’t want the Internet to run code on your computer.
Continue reading “This Week In Security: Schemeflood, Modern Wardialing, And More!”

This Week In Security: Updates, Leaks, Hacking Old Hardware, And Making New

First off, Apple has issued an update for some very old devices. Well, vintage 2013, but that’s a long time in cell-phone years. Fixed are a trio of vulnerabilities, two of which are reported to be exploited in the wild. CVE-2021-30761 and CVE-2021-30762 are both flaws in Webkit, allowing for arbitrary code execution upon visiting a malicious website.

The third bug fixed is a very interesting one, CVE-2021-30737, memory corruption in the ASN.1 decoder. ASN.1 is a serialization format, used in a bunch of different crypto and telecom protocols, like the PKCS key exchange protocols. This bug was reported by [xerub], who showed off an attack against locked iPhone immediately after boot. Need to break into an old iPhone? Looks like there’s an exploit for that now. Continue reading “This Week In Security: Updates, Leaks, Hacking Old Hardware, And Making New”