This Week In Security: VPNs, Patch Tuesday, And Plundervault

An issue in Unix virtual private networks was disclosed recently, where an attacker could potentially hijack a TCP stream, even though that stream is inside the VPN. This attack affects OpenVPN, Wireguard, and even IPSec VPNs. How was this possible? Unix systems support all manner of different network scenarios, and oftentimes a misconfiguration can lead to problems. Here, packets sent to the VPNs IP address are processed and responded to, even though they are coming in over a different interface.

The attack initially sounds implausible, as an attacker has to know the Virtual IP address of the VPN client, the remote IP address of an active TCP connection, and the sequence and ACK numbers of that connection. That’s a lot of information, but an attacker can figure it out one piece at a time, making it a plausible attack. Continue reading “This Week In Security: VPNs, Patch Tuesday, And Plundervault”

This Week In Security: The Robots Are Watching, Insecure VPNs, Graboids, And Biometric Fails

A Japanese hotel chain uses robots for nearly everything. Check in, room access, and most importantly, bedside service. What could possibly go wrong with putting embedded Android devices, complete with mics and cameras, right in every hotel room? While I could imagine bedside robots ending badly in many ways, today we’re looking at the possibility that a previous guest installed an app that can spy on the room. The kiosk mode used on these devices left much to be desired. Each bot has an NFC reader, and all it takes is an URL read by that reader to break out of the kiosk jail. From there, a user has full access to the Android system underneath, and can install whatever software they wish.

[Lance Vick] discovered this potential problem way back in July, and after 90 days of inaction has released the vulnerability. More of these hotels are being rolled out for the 2020 Olympics, and this sort of vulnerability is sure to be present in other similar kiosk devices.

VPN Compromise

In March 2018, a server in a Finnish data center was compromised through a remote management system. This was probably a Baseboard Management Controller (BMC), which is as dangerous as it is useful. Most BMCs have their own Ethernet adapter, not controlled by the host computer, and allows a remote user to access the machine just as if they had a monitor and keyboard connected to it. This particularly server was one rented by NordVPN, who was apparently not notified of the data center breach.

So what was captured from this server? Apparently the OpenVPN credentials stored on that server, as well as a valid TLS key. (Document mirror via TechCrunch) It’s been noted that this key is now expired, which does mean that it’s not being actively exploited. There were, however, about 7 months between the server break-in and the certificate expiration, during which time it could have been used for man-in-the-middle attacks.

NordVPN has confirmed the breach, and tried to downplay the potential impact. This report doesn’t seem to entirely match the leaked credentials. An attacker with this data and root access to the server would have likely been able to decrypt VPN traffic on the fly.

Graboid

Named in honor of a certain sci-fi worm, Graboid is an unusual piece of malware aimed at Docker instances. It is a true worm, in that compromised hosts are used to launch attacks against other vulnerable machines. Graboid isn’t targeting a Docker vulnerability, but simply looking for an unsecured Docker daemon exposed to the internet. The malware downloads malicious docker images, one of which is used for crypto-currency mining, while another attempts to compromise other servers.

Graboid has an unusual quirk — the quirk that earned it the name: It doesn’t constantly mine or attempt to spread, but waits over a minute between bursts of activity. This was likely an attempt to mask the presence of mining malware. It’s notable that until discovered, the malicious Docker images were hosted on the Docker Hub. Be careful what images you trust, and look for the “Docker Official Image” tag.

Iran and Misdirection

Remember a couple weeks ago, when we discussed the difficulty of attack attribution? It seems a healthy dose of such paranoia might be warranted. The American NSA and British NCSC revealed that they now suspect Russian actors compromised Iranian infrastructure and deployed malware developed by Iranian coders. The purpose of this seems to have been redirection — to compromise targets and put the blame on Iran. To date it’s not certain that this particular gambit fooled any onlookers, but this is likely not the only such effort.

Android Biometrics

New Android handsets have had a rough week. First, the Samsung Galaxy S10 had an issue with screen protectors interfering with the under-the-screen fingerprint reader. This particular problem seems to only affect fingerprints that are enrolled after a screen protector has been applied. With the protector still in place, anyone’s fingerprint is able to unlock the device. What’s happening here seems obvious. The ultrasonic fingerprint scanner isn’t able to penetrate the screen protector, so it’s recording an essentially blank fingerprint. A patch to recognize these blank prints has been rolled out to devices in Samsung’s home country of South Korea, with the rest of the world soon to follow.

The second new handset is the Google Pixel 4, which includes a new Face Unlock feature. While many have praised the feature, there is trouble in paradise. The Pixel’s Face Unlock works even when the user is asleep or otherwise unmoving. To their credit, Apple’s Face ID also checks for user alertness, trying to avoid unlocking unless the user is intentionally doing so.

The humorous scenario is a child or spouse unlocking your phone while you’re asleep, but a more sobering possibility is your face being used against you unwillingly, or even while unconscious or dead. Based on leaks, it’s likely that there was an “eyes open” mode planned but cut before launch. Hopefully the bugs can be worked out of that feature, and it can be re-added in a future update. Until then, it’s probably best not to use Google’s Face Unlock on Pixel 4 devices.

Hack My House: Opening Raspberry Pi To The Internet, But Not The Whole World

If you’ve followed along with our series so far, you know we’ve set up a network of Raspberry Pis that PXE boot off a central server, and then used Zoneminder to run a network of IP cameras. Now that some useful services are running in our smart house, how do we access those services when away from home, and how do we keep the rest of the world from spying on our cameras?

Before we get to VPNs and port forwarding, there is a more fundamental issue: Do you trust your devices? What exactly is the firmware on those cheap cameras really doing? You could use Wireshark and a smart switch with port mirroring to audit the camera’s traffic. How much traffic would you need to inspect to feel confident the camera never sends your data off somewhere else?

Thankfully, there’s a better way. One of the major features of surveillance software like Zoneminder is that it aggregates the feeds from the cameras. This process also has the effect of proxying the video feeds: We don’t connect directly to the cameras in order to view them, we connect to the surveillance software. If you don’t completely trust those cameras, then don’t give them internet access. You can make the cameras a physically separate network, only connected to the surveillance machine, or just set their IP addresses manually, and don’t fill in the default route or DNS. Whichever way you set it up, the goal is the same: let your surveillance software talk to the cameras, but don’t let the cameras talk to the outside world.

Edit: As has been pointed out in the comments, leaving off a default route is significantly less effective than separate networks. A truly malicious peice of hardware could easily probe for the gateway.

This idea applies to more than cameras. Any device that doesn’t need internet access to function, can be isolated in this way. While this could be considered paranoia, I consider it simple good practice. Join me after the break to discuss port forwarding vs. VPNs.

Continue reading “Hack My House: Opening Raspberry Pi To The Internet, But Not The Whole World”

DUHK: Don’t Use Hard-Coded Keys

The title reads like the name of a lecture in cryptography 101 or the first rule of Crypto Club. ‘DUHK‘ is in fact neither of those but the name of a recently disclosed vulnerability in a pseudorandom number generating algorithm (PNRG) that was until recently part of the federal standard X9.31.

Random numbers are essential to viable cryptography. They are also hard to obtain leading to solutions like using the physical properties of semiconductors or decaying matter, that are governed by quantum effects. The next best solution is to log events that are hard to predict like the timing of strokes on a keyboard. The weakest source of randomness is math, which makes sense, because one of maths most popular features is its predictability. Mathematical solutions have the one redeeming quality of being able to produce a lot of numbers that look random to a human in a short time.

PNRGs require a starting point from which they begin to produce their output. Once this seed is known the produced sequence becomes predictable.

The X9.31 PNRG is an algorithm that is used in various cryptographic algorithms and has been certified in the Federal Information Processing Standards for decades until it was dropped from the list of approved standards in 2016. The researchers behind DUHK found out that the standard allowed the seed to be stored in the source code of its implementation. The next step was to look for software that did this and they found X9.31 in an older version of FortiOS running on VPN gateways.

Should I be Worried?

Probably, maybe not. The analysis (PDF) published by the team behind DUHK notes that the vulnerability is limited to legacy implementations and doesn’t allow to takeover the device running them, only to eavesdrop on ‘secure’ connections. The scope of this is much more limited than exploits like remote code execution via bluetooth. It is on the other hand providing a strong case for handling standards and technical certifications with extreme scrutiny. The teams conduct also gives insight into the best practises for white-hat hacking which are frequently discussed around here. And they have a great theme song.

Untether From Your Location With A VPN

By now, most of us know the perks of using a VPN: they make private one’s online activity (at least from your ISP’s point of view, probably), and they can also make it appear as if you are in a different locale than you physically are. This is especially important for trying to watch events such as the Olympics which might air different things at different times in different countries. It’s also starting to be an issue with services like Netflix which allow content in some areas but not others.

While VPNs can help solve this problem, it can be tedious to set them up for specific purposes like this if you have to do it often. Luckily, [clashtherage] has created a router with a Raspberry Pi that takes care of all of the complicated VPN routing automatically. In much the same way that another RPi router we’ve seen eliminates ads from all of your internet traffic, this one takes all of your traffic and sends it to a locale of your choosing. (In theory one could use both at the same time.)

Obviously this creates issues for Netflix as a company, and indeed a number of services (like craigslist, for example) are starting to block access to their sites if they detect that a VPN is being used. Of course, this only leads to an arms race of VPNs being blocked, and them finding ways around the obstacles, and on and on. If only IPv6 was finally implemented, we might have a solution for all of these issues.

A Red Teamer’s Guide To Pivoting

What is hacking and what is network engineering? We’re not sure where exactly to draw the lines, but [Artem]’s writeup of pivoting is distinctly written from the (paid) hacker’s perspective.

Once you’re inside a network, the question is what to do next. “Pivoting” is how you get from where you are currently to where you want to be, or even just find out what’s available. And that means using all of the networking tricks available. These aren’t just useful for breaking into other people’s networks, though. We’ve used half of these tools at one time or another just running things at home. The other half? Getting to know them would make a rainy-day project.

Is there anything that ssh and socat can’t do? Maybe not, but there are other tools (3proxy and Rpivot) that will let you do it easier. You know how clients behind a NAT firewall can reach out, but can’t be reached from outside? ssh -D will forward a port to the inside of the network. Need to get data out? There’s the old standby iodine to route arbitrary data over DNS queries, but [Artem] says dnscat2 works without root permissions. (And this code does the same on an ESP8266.)

Once you’ve set up proxies inside, the tremendously useful proxychains will let you tunnel whatever you’d like across them. Python’s pty shell makes things easier to use, and tsh will get you a small shell on the inside, complete with file-transfer capabilities.

Again, this writeup is geared toward the pen-testing professional, but you might find any one of these tools useful in your own home network. We used to stream MP3s from home to work with some (ab)use of netcat and ssh. We keep our home IoT devices inside our own network, and launching reverse-proxies lets us check up on things from far away without permanently leaving the doors open. One hacker’s encrypted tunnel is another man’s VPN. Once you know the tools, you’ll find plenty of uses for them. What’s your favorite?

Thanks [nootrope] for the indirect tip!

How The NSA Can Read Your Emails

Since [Snowden]’s release of thousands of classified documents in 2013, one question has tugged at the minds of security researchers: how, exactly, did the NSA apparently intercept VPN traffic, and decrypt SSH and HTTP, allowing the NSA to read millions of personal, private emails from persons around the globe? Every guess is invariably speculation, but a paper presented at the ACM Conference on Computer and Communications Security might shed some light on how the NSA appears to have broken some of the most widespread encryption used on the Internet (PDF).

The relevant encryption discussed in the paper is Diffie–Hellman key exchange (D-H), the encryption used for HTTPS, SSH, and VPN. D-H relies on a shared very large prime number. By performing many, many computations, an attacker could pre-compute a ‘crack’ on an individual prime number, then apply a relatively small computation to decrypt any individual message that uses that prime number. If all applications used a different prime number, this wouldn’t be a problem. This is the difference between cryptography theory and practice; 92% of the top 1 Million Alexa HTTPS domains use the same two prime numbers for D-H. An attacker could pre-compute a crack on those two prime numbers and consequently be able to read nearly all Internet traffic through those servers.

This sort of attack was discussed last spring by the usual security researchers, and in that time the researchers behind the paper have been hard at work. The earlier discussion focused on 512-bit D-H primes and the LogJam exploit. Since then, the researchers have focused on the possibility of cracking longer 768- and 1024-bit D-H primes. They conclude that someone with the resources of cracking a single 1024-bit prime would allow an attacker to decrypt 66% of IPsec VPNs and 26% of SSH servers.

There is a bright side to this revelation: the ability to pre-compute the ‘crack’ on these longer primes is a capability that can only be attained by nation states as it’s on a scale that has been compared to cracking Enigma during WWII. The hardware alone to accomplish this would cost millions of dollars, and although this computation could be done faster with dedicated ASICs or other specialized hardware, this too would require an enormous outlay of cash. The downside to this observation is, of course, the capability to decrypt the most prevalent encryption protocols may be in the hands of our governments. This includes the NSA, China, and anyone else with hundreds of millions of dollars to throw at a black project.