Security Hacks

1527 Articles

This Week In Security: Nintendo Accounts, Pernicious Android Malware, And An IOS 0-day

April 24, 2020 by 8 Comments

A rash of Nintendo account compromises has made the news over the last week. Nintendo’s official response was that they were investigating, and recommended everyone enabled two factor authentication on their accounts.

[Dan Goodin] over at Ars Technica has a canny guess: The compromised accounts were each linked to an old Nintendo Network ID (NNID). This is essentially a legacy Nintendo account — one made in the Wii U and 3DS era. Since they’re linked, access via the NNID exposes the entire account. Resetting the primary account password doesn’t change the NNID credentials, but turning on two factor authentication does seem to close the loophole. There hasn’t yet been official confirmation that NNIDs are responsible, but it seems to fit the situation. It’s an interesting problem, where a legacy account can lead to further compromise.

Just Can’t Lose You: xHelper

xHelper, an Android malware, just won’t say goodbye. xHelper looks like a cleaner application, but once installed it begins rather stubbornly installing itself via the Triada trojan. The process begins with rooting the phone, and then remounting /system as writable. Binaries are installed and startup scripts are tampered with, and then the mount command itself is compromised, preventing a user from following the same steps to remove the malware. Additionally, if the device has previously been rooted, the superuser binary is removed. This combination of techniques means that the infection will survive a factory reset. The only way to remove xHelper is to flash a clean Android image, fully wiping /system in the process. Continue reading “This Week In Security: Nintendo Accounts, Pernicious Android Malware, And An IOS 0-day” →

This Week In Security: Git, Patch Tuesday, Anti-Cheat, And Vulnerable Documentation

April 17, 2020 by 8 Comments

Git released an update on Tuesday, fixing an issue that could result in leaking credentials. The vulnerability was in how Git handles an HTTP URL containing a newline. Looking at the commits in 2.26.1, we can find an example of an attack:
url = "https://one.example.com?%0ahost=two.example.com/foo.git"

So doing a git pull against this repository will connect your git instance to an attacker’s server, but using the credentials from an arbitrary server. It seems like this could potentially be used to steal Github credentials, for instance. So go make sure you have an updated Git client.
Continue reading “This Week In Security: Git, Patch Tuesday, Anti-Cheat, And Vulnerable Documentation” →

$100k To Crack A Bitcoin Wallet

April 11, 2020 by 43 Comments

When Bitcoin peaked a few years ago, with single coins reaching around $18,000 USD, heartbreaking stories began circulating about people who had tens or hundreds of coins they mined in the early days when coins were worth just a few dollars or cents. Since then, they owners of these coins had lost the private key, or simply thrown away the drive or computer the coins were on. It’s next to impossible to recover this key in most situations, but for the right amount of money it can sometimes be done.

About 20 years ago, [Mike] was working as a cryptography expert and developed a number of interesting algorithms for breaking various forms of encryption, one of which involved .zip files with poor entropy. A Bitcoin owner stumbled across the paper that [Mike] wrote and realized that it could be a method for recovering his lost key from 2016. [Mike] said it would take a GPU farm and $100,000 USD, but when the owner paid the seemingly enormous price [Mike] was able to recover around $300,000 worth of Bitcoin.

While this might not be financially feasible for you if you have a USB stick with a single coin on it you mined as a curiosity in 2010, the cryptography that is discussed in the blog entry is the real story here. We never know where the solutions to our problems are going to come from, like a random .zip file exploitation from two decades ago, but we can be sure that in the future it will be much easier to crack these keys.

Thanks to [Darmstatium] for the tip!

This Week In Security: Zoom (Really This Time), Fingerprints, And Bloatware

April 10, 2020 by 9 Comments

You were promised Zoom news last week, but due to a late night of writing, that story was delayed to this week. So what’s the deal with Zoom? Google, SpaceX, and even the government of Taiwan and the US Senate have banned Zoom. You may remember our coverage of Zoom from nearly a year ago, when Apple forcibly removed the Zoom service from countless machines. The realities of COVID-19 have brought about an explosion of popularity for Zoom, but also a renewed critical eye on the platform’s security.

“Zoombombing”, joining a Zoom meeting uninvited, made national headlines as a result of a few high profile incidents. The US DOJ even released a statement about it. Those incidents seem to have been a result of Zoom default settings: no meeting passwords, no “waiting room”, and meeting IDs that persist indefinitely. A troll could simply search google for Zoom links, and try connecting to them until finding an active meeting. Ars ran a great article on how to avoid getting zoombombed (thanks to Sheldon for pointing this out last week).

There is another wrinkle to the Zoom story. Zoom is technically an American company, but its Chinese roots put it in a precarious situation. Recently it’s been reported that encryption keying is routed through infrastructure in China, even though the calling parties are elsewhere. In some cases, call data itself goes through Chinese infrastructure, though that was labeled as a temporary bug. Zoom was also advertising its meetings as having end-to-end encryption. That claim was investigated, and discovered to be false. All meetings get decrypted at Zoom servers, and could theoretically be viewed by Zoom staff. Continue reading “This Week In Security: Zoom (Really This Time), Fingerprints, And Bloatware” →

Decentralized Privacy-Preserving Proximity Tracing

April 9, 2020 by 6 Comments

As we continue through the pandemic, whether we are on lockdown or still at work, there is a chance for all of us that we could still pick up the virus from a stray contact. Mapping these infections and tracing those in proximity to patients can present a major problem to infection control authorities, and there have been a variety of proposals for smartphone apps designed to track users’ contacts via the Bluetooth identities their phones encounter. This is a particular concern to privacy advocates, because there is a chance that some governments could use this as an excuse to bring in intrusive personal surveillance by this means. A group of academics from institutions across Europe have come together with a proposal for a decentralised proximity tracing system that allows identification of infection risk without compromising the privacy of those using it.

Where a privacy-intrusive system might use a back-end database tracking all users and recording their locations and interactions, this one uses anonymised tokens stored at the local level rather than at the central server. When a user is infected this is entered at app level rather than at server level, and the centralised part of the system merely distributes the anonymised tokens to the clients. The computation of whether contact has been made with an infected person is thus made on the client, meaning that the operator has no opportunity to collect surveillance data. After the pandemic has passed the system will evaporate as people stop using it, rather than remaining in place harvesting details from installed apps. They are certainly not the first academics to wrestle with this thorny issue, but they seem to have ventured further into the mechanics of it all.

As with all new systems, it’s probably good to subject it to significant scrutiny before deploying it live. Have a read. What do you think?

We are all watching our authorities as they race to respond to the pandemic in an effective manner, and we hope that should they opt for an app that it does an effective job and they resist the temptation to make it too intrusive. Our best course of action meanwhile as the general public is to fully observe all advised public health measures such as self-isolation or the wearing of appropriate personal protective equipment.

This Week In Security: OpenWrt, ZOOM, And Systemd

April 3, 2020 by 21 Comments

OpenWrt announced a problem in opkg, their super-lightweight package manager. OpenWrt’s target hardware, routers, make for an interesting security challenge. A Linux install that fits in just 4 MB of flash memory is a minor miracle in itself, and many compromises had to be made. In this case, we’re interested in the lack of SSL: a 4 MB install just can’t include SSL support. As a result, the package manager can’t rely on HTTPS for secure downloads. Instead, opkg first downloads a pair of files: A list of packages, which contains a SHA256 of each package, and then a second file containing an Ed25519 signature. When an individual package is installed, the SHA256 hash of the downloaded package can be compared with the hash provided in the list of packages.


It’s a valid approach, but there was a bug, discovered by [Guido Vranken], in how opkg reads the hash values from the package list. The leading space triggers some questionable pointer arithmetic, and as a result, opkg believes the SHA256 hash is simply blank. Rather than fail the install, the hash verification is simply skipped. The result? Opkg is vulnerable to a rather simple man in the middle attack.

OpenWrt doesn’t do any automatic installs or automatic updates, so this vulnerability will likely not be widely abused, but it could be used for a targeted attack. An attacker would need to be in a position to MitM the router’s internet connection while software was being installed. Regardless, make sure you’re running the latest OpenWrt release to mitigate this issue. Via Ars Technica.

Wireguard V1.0

With the Linux Kernel version 5.6 being finally released, Wireguard has finally been christened as a stable release. An interesting aside, Google has enabled Wireguard in their Generic Kernel Image (GKI), which may signal more official support for Wireguard VPNs in Android. I’ve also heard reports that one of the larger Android ROM development communities is looking into better system-level Wireguard support as well.

Javascript in Disguise

Javascript makes the web work — and has been a constant thorn in the side of good security. For just an example, remember Samy, the worm that took over Myspace in ’05. That cross-site scripting (XSS) attack used a series of techniques to embed Javascript code in a user’s profile. Whenever that profile page was viewed, the embedded JS code would run, and then replicate itself on the page of whoever had the misfortune of falling into the trap.

Today we have much better protections against XSS attacks, and something like that could never happen again, right? Here’s the thing, for every mitigation like Content-Security-Policy, there is a guy like [theMiddle] who’s coming up with new ways to break it. In this case, he realized that a less-than-perfect CSP could be defeated by encoding Javascript inside a .png, and decoding it to deliver the payload.

Systemd

Ah, systemd. Nothing seems to bring passionate opinions out of the woodwork like a story about it. In this case, it’s a vulnerability found by [Tavis Ormandy] from Google Project Zero. The bug is a race condition, where a cached data structure can be called after it’s already been freed. It’s interesting, because this vulnerability is accessible using DBus, and could potentially be used to get root level access. It was fixed with systemd v220.

Mac Firmware

For those of you running MacOS on Apple hardware, you might want to check your firmware version. Not because there’s a particularly nasty vulnerability in there, but because firmware updates fail silently during OS updates. What’s worse, Apple isn’t publishing release notes, or even acknowledging the most recent firmware version. A crowd-sourced list of the latest firmware versions is available, and you can try to convince your machine to try again, and hope the firmware update works this time.

Anti-Rubber-Ducky

Google recently announced a new security tool, USB Keystroke Injection Protection. I assume the nickname, UKIP, isn’t an intentional reference to British politics. Regardless, this project is intended to help protect against the infamous USB Rubber Ducky attack, by trying to differentiate a real user’s typing cadence, as opposed to a malicious device that types implausibly quickly.

While the project is interesting, there are already examples of how to defeat it that amount to simply running the scripts with slight pauses between keystrokes. Time will tell if UKIP turns into a useful mitigation tool. (Get it?)

SMBGhost

Remember SMBGhost, the new wormable SMB flaw? Well, there is already a detailed explanation and PoC. This particular PoC is a local-only privilege escalation, but a remote code execution attack is like inevitable, so go make sure you’re patched!

Peel Apart Your ISP’s Router

April 2, 2020 by 35 Comments

Whether your home Internet connection comes by ADSL, fibre, cable, or even satellite, at some point in the chain between your ISP and your computer will be a router in your home. For some of us it’s a model we’ve bought ourselves and loaded up with a custom distro, but for the majority it’s a box supplied by our ISP and subject to their settings and restrictions. [Paddlesteamer] has just such a router, a Huawei model supplied by the Turkcell ISP, and decided to do a little snooping into its setup.

In a tale of three parts, we see the device unravel, from uncovering a shell to reverse engineering its update process, to delving in its firmware and finally removing all its restrictions entirely. It’s a fascinating process in which we learn a lot, such as the way a man-in-the-middle attack is performed on the router’s connection tot he ISP, or that it contains an authorised SSH key seemingly giving Huawei a back door into it. You may never do this with your ISP’s router, but it pays to be aware of what can be put in your home by them without your realising it.

The Golden Age of router hacking may be behind us as the likes of the Raspberry Pi have replaced surplus routers as a source of cheap Linux boards, but  as this shows us there’s still a need to dive inside a router from time to time. After all, locked-down routers are hardly a new phenomenon.

Via Hacker News.