[Rowan Patterson] informed us about a recent ticket he opened over at the Raspberry Pi Documentation GitHub repository. He asked about the the lack of updates to the Raspberry Pi 4’s USB-C power schematics for this board. You may recall that the USB-C power issue was covered by us back in July of 2019, yet the current official Raspberry Pi 4 schematics still show the flawed implementation, with the shorted CC pins, nearly two years later.
[Alasdair Allan], responsible for the Raspberry Pi documentation, mentioned that they’re in the process of moving their documentation from Markdown to AsciiDoc, and said that they wouldn’t have time for new changes until that was done. But then [James Hughes], Principal Software Engineer at Raspberry Pi, mentioned that the schematics may not be updated even after this change due to a of lack of manpower.
As [James] emphasized, their hardware will probably never be open, due to NDAs signed with Broadcom. The compromise solution has always been to publish limited peripheral schematics. Yet now even those limited schematics may not keep up with board revisions.
An easy fix for the Raspberry Pi 4’s schematics would be for someone in the community to reverse-engineer the exact changes made to the Raspberry Pi 4 board layout and mark these up in a revised schematic. This should be little more than the addition of a second 5.1 kΩ resistor, so that CC1 and CC2 each are connected to ground via their own resistor, instead of being shorted together.
Still, you might wish that Raspberry Pi would update the schematics for you, especially since they have updated versions internally. But the NDAs force them to duplicate their efforts, and at least right now that means that their public schematics do not reflect the reality of their hardware.
For the first time since its inception, the Korea Communications Commission this week revoked the regulatory approvals of 1,696 telecommunications devices from 378 companies, both foreign and domestic. Those companies must recall unsold inventory from the shelves, and prove conformity of existing products already sold. In addition, the companies may not submit new applications for these items for one year. It’s not clear what would happen to already-sold equipment if the manufacturer is unable to prove conformity as requested — perhaps a recall? Caught up in this are CCTV products, networking equipment, Bluetooth speakers, and drones from companies like Huawei, DJI, and even Samsung.
The heart of the issue are what’s known as Mutual Recognition Agreements (MRAs) between countries to officially recognize of each other’s certification testing laboratories (or Conformity Assessment Bodies, CAB, in the lingo of the industry). Currently ten countries (USA, Canada, Mexico, UK, Israel, Japan, Korea, Singapore, Vietnam, and Australia), the 27 member states of the EU, Taiwan and Hong Kong all have MRAs with each other. Based on these MRAs, a Korean manufacturer could have a product tested by a laboratory in Israel, for example, and all would be kosher with the KCC.
At the center of attention is the Bay Area Compliance Laboratories (BACL), established in 1996 and headquartered in Sunnyvale, California. BACL has laboratories all over the world (USA, Taiwan, Hong Kong, Vietnam, and mainland China). Except for those in mainland China, all BACL laboratories are acceptable per the MRAs. The KCC received a tip last year that some compliance test reports for some products might be defective.
A six-month investigation in cooperation with the US National Institute of Standards and Technology (NIST) resulted in the announcement this week. Korean companies, 378 of them to be exact, had submitted test reports from BACL Sunnyvale which appeared to be appropriate. But on further investigation, it was learned that the actual testing was done by BACL laboratories in mainland China and only the reports were prepared in Sunnyvale.
It’s not clear whether these companies were knowingly playing fast and loose with the rules, whether BACL was complicit, if it was just a misunderstanding of the intricacies of the regulations and MRAs, or a combination of all three. Regardless, the KCC said that intent doesn’t matter according the their rules. It also has not been suggested that the products themselves are problematic, nor has anyone suggested that BACL’s Chinese laboratories performed slipshod work — rather, the KCC says it has no choice but to proceed with the revocation based on the applicable laws.
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”→
Finding broken test gear and fixing it up to work again is a time-honored tradition among hackers. If you’re lucky, that eBay buy will end up being DOA because of a popped fuse or a few bad capacitors, and a little work with snips and a soldering iron will earn you a nice piece of test gear and bragging rights to boot.
Some repairs, though, are in a class by themselves, like this memory module transplant for a digital scopemeter. The story began some time ago when [FeedbackLoop] picked up a small lot of broken Fluke 199C scopemeters from eBay. They were listed as “parts only”, which is never a good sign, and indeed the meters were in various states of disassembly and incompleteness.
The subject of the video below was missing several important bits, like a battery and a power connector, but most critically, its memory module. Luckily, the other meter had a good module, making reverse engineering possible. That effort started with liberating the two RAM chips and two flash chips, all of which were in BGA packages, from the PCB. From there each chip went into a memory programmer to read its image, which was then written to new chips. The chip-free board was duplicated — a non-trivial task for a six-layer PCB — and new ones ordered. After soldering on the programmed chips and a few passives, the module was plugged in, making the meter as good as new.
There is no question that poaching has become an existential threat to the five species of rhinoceros alive today. Even the wildlife reserves where most rhinos live struggle to provide protection from the wanton and cruel poaching of the world’s last remaining rhinos.
Poachers are generally looking to sell the horns which consist of pure keratin, the same material that makes up our fingernails and hair. Rhino horns have seen a big rise in demand the past decades, with a black market in Vietnam representing the biggest buyers, primarily for use in fever and other medicines, as well as for processing into carved trinkets. This has contributed to a further rhino population collapse. Statistics from 2017 show about 18,000 white rhinos and fewer than 5,500 black rhinos remaining. Recently, the northern white rhino population in Africa went effectively extinct with the death of the last known male individual.
Clearly, if we wish to prevent extinction, we need to deal with poaching. The latest suggestion here is part of the Rhisotope project. This would make rhino horns radioactive, but how exactly would doing so prevent poaching? Let’s take a look.
It’s a way to Man-In-the-Middle an HTTPS connection, without actually needing to break the encryption. There are two primary observations at the core of the attack. First, multiple subdomains will often share the same TLS certificate. Secondly, TLS is regularly used to protect more than just HTTPS. So what happens if an HTTPS request is redirected to an SFTP server run by the same company? The TLS handshake will complete successfully, but the data returned by the server is not at all what the browser expected.
The specific details are a little light on this one, but the authors identified three broad categories of attack. The first is an upload attack, where the attacker has privileges to upload files to an FTPS server. From what I can tell, an attacker initiates an FTP upload over SSL, using the control port, and then redirects the victim’s connection to the data port on that server. The entirety of the HTML request is then saved, decrypted, on the FTPS server. This request could contain session cookies and other secrets.
The second identified attack is the opposite, the attacker uploads a malicious file, initiates a download, and then redirects a browser’s request to the FTPS data port. The malicious file is grabbed and the browser may interpret it as code to be run. The third is a reflection technique. This one’s a bit different. Essentially the attacker sends a request for DoBadThings();, and then connects the victim browser to the data port. The response is sent, Cannot find file: DoBadThings();and the browser might just execute the script fragment. This isn’t one of those attacks that are going to be applicable to just every server, but in just the right setup, it could lead to problems.
VMWare Flaw Exploited
There is a serious VMWare flaw under active exploit right now. It’s apparently in the VMware vCenter control program, and exploiting it is as simple as six curl commands. The flaw is pre-authentication and only requires access to HTTPS port 443. At least one researcher has already seen his VMware honeypot attacked and observed the web-shell the attacker installed. This one looks like a big deal, so make sure you’re up-to-date if you run VMware.
That Time the FBI Ran a Darknet
AN0M was a popular encrypted communication tool for the underworld, really a network consisting of locked down mobile devices with a specialized app running on them. The reality was a bit different, though, the tool was actually being run as Operation Ironside, a join operation by the FBI and the Australian Federal Police (AFP). The story is a weird one, and really raises some legal and ethical questions, so buckle up.
First off, things got started back in 2018 when Phantom Secure CEO Vincent Ramos was prosecuted for RICO charges, related to his company’s work on secure phones. They specialized in taking Blackberry phones, yanking out all the IO hardware, like camera, microphone, and even GPS chips, and then installing encrypted communication apps. In short, very similar to AN0M. Phantom Secure was walking a very thin line between being a legitimate provider of secure hardware, and actively supporting criminal enterprise. When Ramos told an undercover FBI agent that his phones were specifically for drug smuggling, it became obvious that he had strayed far onto the wrong side of the law. He and many in the company were charged for related crimes.
One employee already had drug charges on his record, and agreed to cooperate with the FBI in exchange for avoiding further charges. That developer had already been developing his own device, which he called AN0M. The deal he cut with the feds was to turn over his work for immunity. A scheme was hatched, apparently over beers between agents, to complete the development of AN0M and distribute the devices, but to include a complete back door for law enforcement. This is actually very similar to what was done with Crypto AG, under Project Rubicon.
The turned developer distributed the devices to his contacts, and law enforcement agencies around the world got involved, quietly helping to make them popular. The devices served their purpose of providing messaging to all recipients. It just wasn’t known at the time that law enforcement agents were BCC’d on every message. It’s not clear what triggered the raids and announcements, but this was definitely a coordinated action.
There is a lingering question, however. Namely, do law enforcement really have the legal authority to develop and distribute a malicious device and application? Did a warrant actually cover this? Can it? There is sure to be much consternation over such questions in the months to come. Just imagine that WhatsApp is eventually revealed to be an app secretly developed by the Chinese government, then how would you feel about it?
Ransomware and Bitcoin Seizure
And in another major victory for the FBI, The majority of the funds paid by the Colonial pipeline have been recovered. It’s not entirely known how the recovery happened, but you can read the FBI Affidavit that describes the path the Bitcoins took. There’s a strange little statment at the end of that document. “The private key for the Subject Address is in the possession of the FBI in the Northern District of California.” One has to wonder a couple of things. First, how was the FBI able to track those bitcoins? And second, just how did they happen to end up in a wallet that they knew the key for? Could The AN0M story be related?
The private key for the Subject Address is in the possession of the FBI in the Northern District of California
Now here’s another angle to this. Colonial was given the choice, to pay in Bitcoin or Ethereum, and they chose Bitcoin, even though there was a 10% extra fee for that currency. They had their networks mostly back up, and they knew the decryptor wouldn’t be very helpful. They were working with law enforcement, and they still paid. This raises the very real possibility that the payment was made specifically to trace the Bitcoin transactions.
Next, remember how proud JBS was of their incident response? Now we find out that they did indeed pay an $11 million ransom. However, that was in cooperation with federal officials, and was not necessary to recover files. Oh, and paid in Bitcoin. Sound familiar? At this point, it’s a fair guess that the FBI or another agency helping them has an angle on tracing Bitcoin transactions. AN0M is one possibility. Another is that the FBI is running a “mixer”, essentially a Bitcoin money laundering service. (Shoutout to @MalwareJake for that idea.) Regardless, there seems to be a more serious stance taken towards ransomware as a result of the high profile hacks of the last few weeks.
Rocket.Chat Goes Boom
Running a Rocket.Chat instance? Go update it! This popular Open Source messaging platform uses a NoSQL backend for managing users. If you thought getting rid of SQL means you don’t have injection vulnerabilities, think again.
The MongoDB database backend passes requests and data in a JSON-like format. The first attack is to stuff a regex pattern into that JSON, and leak the password hash one character at a time. The second vulnerability uses the $where operator in MongoDB in a clever way. Rather than try to leak information directly, they used error messages to get information out. Put both together, and you can go from simply knowing a user’s email address to a shell on the hosting server in seconds. All in all, it’s an impressive hack, and the video demonstration of it is worth the watch:
Agent Smith Takes Over The Matrix
Include Security found an interesting bug in the Unity engine, where a malicious game object can run arbitrary code on the machine running the engine. It’s the sort of thing that game designers don’t think too much about until it’s a problem. I couldn’t help but think of VR Chat, a multiplayer experience that allows players to upload their own avatars. It’s built in Unity, and uses game objects for those avatars. I haven’t been able to confirm whether it has this vulnerability one way or another, but I’m very much reminded of Agent Smith copying himself onto all the other citizens of the matrix. If VR Chat does indeed have this problem, it would be rather trivial to build an avatar worm to do the same thing. Life imitates art.
Don’t Use a Password Manager?
And finally, one of the hallowed bits of cybersecurity wisdom gets challenged by [Tavis Ormandy] of Google project Zero fame. His take? Don’t use a password manager! Well, actually, it’s that you shouldn’t use a password manager that is a browser extension, because websites can actually interact with the hooks that make them work. There’s more to his argument, and his conclusion is simple. Use the password manager built into Google Chrome. Or Firefox, if that’s what you use. His argument is rather compelling, that many of them aren’t as secure as they claim to be.
A Baofeng radio is often one of the first purchases a new ham radio operator makes these days due to the decent features and low price tag. They are far from perfect, but with a bit of creative inspiration, it’s possible to make the quirks work in your favor. By taking advantage of a loud pop on the earphone outputs whenever the LCD backlight turns on, [WhiskeyTangoHotel] built a radio traffic counter using an ESP8266.
Whenever there is a transmission on one of the frequencies the radio is tuned to, the backlight turns on. Connecting the audio output to an oscilloscope, [WhiskeyTangoHotel] measured a 5V spike whenever this happens. Using a pair of diodes in series to drop the voltage to a safe level, the ESP8266 detects the voltage spike and updates a Google spreadsheet with the timestamp via IFTTT.
This gave [WhiskeyTangoHotel] empirical data on how much traffic passes through the local VHF repeater, but we wouldn’t blame them if the hack itself was the real motivator.
Of course, this would also be a perfect application for the RTL-SDR, which should allow you to do the above and much more, all in software. Add a bit of AI and you can even extract the call signs. The RTL-SDR is also a good tool for learning about RF modulation.
