two USBValve devices on a table, both with a USB cable plugged in. The top one with a long narrow OLED display and the bottom one with a 128x64 OLED display.

Sleuth Untrusted USB Communication With USBValve

July 16, 2023 by Abe Connelly 11 Comments

USB devices are now ubiquitous and, from an information security standpoint, this is a terrifying prospect as malicious software can potentially be injected into a system by plugging in a compromised USB stick. To help get some piece of mind, [Cesare Pizzi] created USBValve to help expose suspicious USB activity on the fly.

The idea behind USBValve is to have the onboard microcontroller advertise itself as a storage device, pretending to have a filesystem with some common files available. When an unknown USB device is first inserted into the USB port on the USBValve tool, USBValve displays usage information, via the attached OLED screen, on whether the USB device is accessing files it shouldn’t be or immediately trying to write to the filesystem, which is a clear sign of malicious behavior.

The USBValve hardware is a straight forward composition of a Raspberry Pi Pico, an tiny I2C OLED screen and an optional PCB carrier board with a 3D printed spacer. The software uses Adafruit’s Tiny USB library along with the SSD1306AsciiWire library to drive the OLED display. And it’s all open source, including the code and PCB design files.

There’s a lot of security fun to be had with USB, from DIY dirt cheap Rubber Duckies to open source hardware Rubber Duckies, to discussions on the BadUSB exploits. The simplicity of the USBValve project allows it to be low cost, easy to use and can provide concise, critical information for a variety of real world threats.

After the break, be sure to check out [Cesare Pizzi]’s talk about USBValve at the SCC Insomnihack conference which has a wealth of information on how it fares against some known malware attacks, discussions on some of its shortcomings and potential avenues for improvement.

Thanks to [watchdog] for the tip!

Continue reading “Sleuth Untrusted USB Communication With USBValve” →

Brute Forcing A Mobile’s PIN Over USB With A $3 Board

July 16, 2023 by Donald Papp 52 Comments

Mobile PINs are a lot like passwords in that there are a number of very common ones, and [Mobile Hacker] has a clever proof of concept that uses a tiny microcontroller development board to emulate a keyboard to test the 20 most common unlock PINs on an Android device.

Trying the twenty most common PINs doesn’t take long.

The project is based on research analyzing the security of 4- and 6-digit smartphone PINs which found some striking similarities between user-chosen unlock codes. While the research is a few years old, user behavior in terms of PIN choice has probably not changed much.

The hardware is not much more than a Digispark board, a small ATtiny85-based board with built-in USB connector, and an adapter. In fact, it has a lot in common with the DIY Rubber Ducky except for being focused on doing a single job.

Once connected to a mobile device, it performs a form of keystroke injection attack, automatically sending keyboard events to input the most common PINs with a delay between each attempt. Assuming the device accepts, trying all twenty codes takes about six minutes.

Disabling OTG connections for a device is one way to prevent this kind of attack, and not configuring a common PIN like ‘1111’ or ‘1234’ is even better. You can see the brute forcing in action in the video, embedded below.

Continue reading “Brute Forcing A Mobile’s PIN Over USB With A $3 Board” →

This Week In Security: Apple’s 0-day, Microsoft’s Mess, And More

July 14, 2023 by Jonathan Bennett 4 Comments

First up, Apple issued an emergency patch, then yanked, and re-issued it. The problem was a Remote Code Execution (RCE) vulnerability in WebKit — the basis of Apple’s cross-platform web browser. The downside of a shared code base,is that bugs too are write-once, exploit-anywhere. And with Apple’s walled garden insisting that every browser on iOS actually run WebKit under the hood, there’s not much relief without a patch like this one.

The vulnerability in question, CVE-2023-37450, is a bit light on further details except to say that it’s known to be exploited in the wild. The first fix also bumped the browser’s user-agent string, adding an (a) to denote the minor update. This was apparently enough to break some brittle user-agent detection code on popular websites, resulting in an unhelpful “This web browser is no longer supported” message. The second patch gets rid of the notification.

Microsoft Loses It

Microsoft has announced that on May 15th, an attack from Storm-0558 managed to breach the email accounts of roughly 25 customers. This was pulled off via “an acquired Microsoft account (MSA) consumer signing key.” The big outstanding question is how Microsoft lost control of that particular key. According to an anonymous source speaking to The Washington Post, some of the targeted accounts were government employees, including a member of cabinet. Apparently the FBI is asking Microsoft this very same question.

Speaking of Microsoft, there’s also CVE-2023-36884, a vulnerability in Microsoft Office. This one appears to be related to the handling of HTML content embedded in Office documents, and results in code execution upon opening the document. This along with another vulnerability (CVE-2023-36874) was being used by storm- another unknown threat actor, Storm-0978 in an ongoing attack.

There’s an interesting note that this vulnerability can be mitigated by an Attack Surface Reduction (ASR) rule, that blocks Office from launching child processes. This might be a worthwhile mitigation step for this and future vulnerabilities in office. Continue reading “This Week In Security: Apple’s 0-day, Microsoft’s Mess, And More” →

This Week In Security: Bogus CVEs, Bogus PoCs, And Maybe A Bogus Breach

July 7, 2023 by Jonathan Bennett 3 Comments

It appears we have something of a problem. It’s not really a new problem, and shouldn’t be too surprising, but it did pop up again this week: bogus CVEs. Starting out in the security field? What’s the best way to jump-start a career? Getting a CVE find to your name certainly can’t hurt. And as a result, you get very junior security researchers looking for and reporting novel security vulnerabilities of sometimes dubious quality. Sometimes that process looks a lot like slinging reports against the wall to see what sticks. Things brings us to an odd bug report in the OBS Studio project.

A researcher put together a script to look for possible password exposure on Github projects, and it caught a configuration value named “password” in a .ini file, being distributed in the project source. Obvious credential leak in Git source, right? Except for the little detail that it was in the “locale” folder, and the files were named ca-es.ini, ja-jp.ini, and similar. You may be in on the joke by now, but if not, those are translation strings. It wasn’t leaked credentials, it was various translations of the word “password”. This sort of thing happens quite often, and from the viewpoint of a researcher looking at results from an automated tool, it can be challenging to spend enough time with each result to fully understand the code in question. It looks like this case includes a language barrier, making it even harder to clear up the confusion.

Things took a turn for the worse when a CVE was requested. The CVE Numbering Authority (CNA) that processed the request was MITRE, which issued CVE-2023-34585. It was a completely bogus CVE, and thankfully a more complete explanation from OBS was enough to convince the researcher of his error. That, however, brings us back to CVE-2023-36262, which was published this week. It’s yet another CVE, for the same non-issue, and even pointing at the same GitHub issue where the alleged bug is debunked. There’s multiple fails here, but the biggest disappointment is MITRE, for handing out CVEs twice for the same issue. Shout-out to [Netspooky] on Twitter for spotting this one. Continue reading “This Week In Security: Bogus CVEs, Bogus PoCs, And Maybe A Bogus Breach” →

This Week In Security:Camaro Dragon, RowPress, And RepoJacking

June 30, 2023 by Jonathan Bennett 4 Comments

Malicious flash drives have come a long ways since the old days of autorun infections. It’s not an accident that Microsoft has tightened down the attack surface available of removable media. So how exactly did a malicious flash drive lead to the compromise of a European hospital? Some sophisticated firmware on the drive? A mysterious zero day? Nope, just hidden files, and an executable using the drive name and icon. Some attacker discovered that a user trying to access a flash drive, only to be presented with what looks like the same flash drive icon, will naturally try to access it again, running an .exe in the process.

That executable runs a signed Symantec binary, included on the drive, and sideloads an OCX that hijacks the process. From there, the computer is infected, as well as any other flash drives in the machine. Part of the obfuscation technique is an odd chain of executables, executed recursively for a hundred copies. Naturally once the infection has rooted itself in a given machine, it takes commands from a C&C server, and sends certain files out to its waiting overlords. Checkpoint Research has attributed this campaign to Camaro Dragon, a name straight from the 80s that refers to a Chinese actor with an emphasis on espionage. Continue reading “This Week In Security:Camaro Dragon, RowPress, And RepoJacking” →

Bluetooth Battery Monitors That Also Monitor Your Position, Without Asking

June 27, 2023 by Maya Posch 40 Comments

These days Bluetooth-based gadgets are everywhere, including for car and solar batteries. After connecting them up to the battery, you download the accompanying app on your smartphone, open it up and like magic you can keep tabs on your precious pile of chemistry that keeps things ticking along. Yet as [haxrob] discovered during an analysis, many of these devices will happily pass your location and other information along to remote servers.

The device in question is a Bluetooth 4.0 Battery Monitor that is resold under many brands, and which by itself would seem to do just what it is said to do, from monitoring a battery to running crank tests. Where things get unpleasant is with the Battery Monitor 2 (BM2) mobile app that accompanies the device. It integrates a library called AMap which is “a leading provider of digital map in China” and part of Alibaba. Although the app’s information page claims that no personal information is collected, the data intercepted with Wireshark would beg to differ.

In part 2 of this series, the BM2 app is reverse-engineered, decompiling the Java code. The personal information includes the latitude and longitude, as well as GPS, cell phone tower cell IDs and WiFi beacon data, which understandably has people rather upset. In addition to leaking your personal info, the BM2 app seems to be also good at running constantly in the background, which ironically drains your phone’s battery at an alarming rate.

Cases like these should be both a warning to not just install any app on your smartphone, as well as a wake-up call to Google and others to prevent such blatant privacy violations.

(Thanks to [Drew] for the tip)

This Week In Security: NOAuth, MiniDLNA, And Ticket To Ride

June 23, 2023 by Jonathan Bennett 4 Comments

There’s a fun logic flaw in how multiple online services handle OAuth logins, that abuses Microsoft’s Azure Active Directory service to allow account takeovers. The problem is how a site handles the “Sign In With Microsoft” option, when there’s an existing account under the same email address. This is an irritating problem for an end-user, when a site offers multiple sign-in options. Trying to remember which option was used to set up an account is a struggle, so many services automatically merge accounts.

The problem is that the Microsoft Azure authentication information includes an email address, but Microsoft hasn’t done any verification that the account in question actually controls that address. And in fact, it’s trivial for the Azure admin to change that address at whim. So if the service accepts that email address as authoritative, and auto-merges the accounts, it’s a trivial account takeover. And it’s more than just a theoretical problem, as researchers at descope were able to demonstrate the attack, and have found multiple medium and large services that were vulnerable, as well as at least two authentication providers that themselves were vulnerable to this attack.

Microsoft has pushed updates to the Azure AD service to make the issue easier to avoid, though it seems that the unverified “email” field is still being sent on authentication transactions. There is a new flag, “RemoveUnverifiedEmailClaim” that eliminates the issue, and is enabled by default for new applications. Unfortunately this means that existing vulnerable applications will continue to be vulnerable until fixed on the application side. Continue reading “This Week In Security: NOAuth, MiniDLNA, And Ticket To Ride” →