vpn

20 Articles

Linux Fu: VPN For Free With SSH

November 23, 2020 by 44 Comments

If you see a lot of banner ads on certain websites, you know that without a Virtual Private Network (VPN), hackers will quickly ravage your computer and burn down your house. Well, that seems to be what they imply. In reality, though, there are two main reasons you might want a VPN connection. You can pay for a service, of course, but if you have ssh access to a computer somewhere on the public Internet, you can set up your own VPN service for no additional cost.

The basic idea is that you connect to a remote computer on another network and it makes it look like all your network traffic is local to that network. The first case for this is to sidestep or enhance security. For example, you might want to print to a network printer without exposing that printer to the public Internet. While you are at the coffee shop you can VPN to your network and print just like you were a meter away from the printer at your desk. Your traffic on the shop’s WiFi will also be encrypted.

The second reason is to hide your location from snooping. For example, if you like watching the BBC videos but you live in Ecuador, you might want to VPN to a network in the UK so the videos are not blocked. If your local authorities monitor and censor your Internet, you might also want your traffic coming from somewhere else.

Continue reading “Linux Fu: VPN For Free With SSH” →

Free P2P VPN

October 18, 2020 by 34 Comments

People use a VPN — virtual private network — for a lot of reasons. However, for many people it is synonymous with hiding your network traffic, one thing that VPN can do. FreePN is a relatively new open source project that aims to build a free peer-to-peer VPN network. Like TOR, it is decentralized.

Right now, you can download for Ubuntu and Gentoo. There is a way to ask for early access for Debian, Fedora, and Arch. Windows, iOS, MacOS, and Android versions are promised for the future.

Continue reading “Free P2P VPN” →

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

December 13, 2019 by 11 Comments

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

October 25, 2019 by 10 Comments

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

November 14, 2018 by 29 Comments

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

October 25, 2017 by 31 Comments

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

October 12, 2017 by 38 Comments

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.