Bonum Certa Men Certa

From Moderate Advice to FUD and Misinformation: The Case of a VPN Vulnerability (CVE-2019-14899)

Sometimes it morphes to "Linux" and a false description of what's happening

VPN fake news



Summary: What should have been a trivial bugfix in a variety of operating systems and bits of software -- both proprietary and Free software -- somehow became anti-Linux FUD, clickbait and worse

EARLIER in the week I saw a report about CVE-2019-14899. There was nothing exciting about it. I mentioned it briefly and then moved on. But the following day and especially two days later (after the announcement [1]) the press was absolutely flooding with reports, especially from insecurity companies and anti-Linux sites [2-22]. At times even deliberate lies were spread [23] (there are no attacks). See below a roughly chronological list/timeline. The initial report was calm and rational.



"The only shocking thing isn't the bug but the level of media attention it has received."When one carefully examines what's at stake, the patching status (it's not a zero-day hole), the severity and risk level etc. one begins to wonder what motivated all this attention. Much more severe issues are being discovered each week if not month.

We first mentioned this 2 or 3 days ago, without even filing it as a high-priority Daily Links pick. The only shocking thing isn't the bug but the level of media attention it has received. This is not the first time such a thing happens. When similar issues affect Windows the media just describes these as "computer issues" or "PC".

Related/contextual items from the news:



  1. VPN hijacking on Linux (and beyond) systems
    Hi all,
    
    

    I am reporting a vulnerability that exists on most Linux distros, and other *nix operating systems which allows a network adjacent attacker to determine if another user is connected to a VPN, the virtual IP address they have been assigned by the VPN server, and whether or not there is an active connection to a given website. Additionally, we are able to determine the exact seq and ack numbers by counting encrypted packets and/or examining their size. This allows us to inject data into the TCP stream and hijack connections.

    Most of the Linux distributions we tested were vulnerable, especially Linux distributions that use a version of systemd pulled after November 28th of last year which turned reverse path filtering off. However, we recently discovered that the attack also works against IPv6, so turning reverse path filtering on isn't a reasonable solution, but this was how we discovered that the attack worked on Linux.

    Adding a prerouting rule to drop packets destined for the client's virtual IP address is effective on some systems, but I have only tested this on my machines (Manjaro 5.3.12-1, Ubuntu 19.10 5.3.0-23). This rule was proposed by Jason Donenfeld, and an analagous rule on the output chain was proposed by Ruoyu "Fish" Wang of ASU. We have some concerns that inferences can still be made using slightly different methods, but this suggestion does prevent this particular attack.

    There are other potential solutions being considered by the kernel maintainers, but I can't speak to their current status. I will provide updates as I receive them.

    I have attached the original disclosure I provided to distros@vs.openwall.org and security@kernel.org below, with at least one critical correction: I orignally listed CentOS as being vulnerable to the attack, but this was incorrect, at least regarding IPv4. We didn't know the attack worked against IPv6 at the time we tested CentOS, and I haven't been able to test it yet.

    William J. Tolley Beau Kujath Jedidiah R. Crandall

    Breakpointing Bad & University of New Mexico

    *************************************************

    **General Disclosure:

    We have discovered a vulnerability in Linux, FreeBSD, OpenBSD, MacOS, iOS, and Android which allows a malicious access point, or an adjacent user, to determine if a connected user is using a VPN, make positive inferences about the websites they are visiting, and determine the correct sequence and acknowledgement numbers in use, allowing the bad actor to inject data into the TCP stream. This provides everything that is needed for an attacker to hijack active connections inside the VPN tunnel.

    This vulnerability works against OpenVPN, WireGuard, and IKEv2/IPSec, but has not been thoroughly tested against tor, but we believe it is not vulnerable since it operates in a SOCKS layer and includes authentication and encryption that happens in userspace. It should be noted, however, that the VPN technology used does not seem to matter and we are able to make all of our inferences even though the responses from the victim are encrypted, using the size of the packets and number of packets sent (in the case of challenge ACKs, for example) to determine what kind of packets are being sent through the encrypted VPN tunnel.

    We have already reported a related vulnerability to Android earlier this year related to the issue, which resulted in the assignment of CVE-2019-9461, however, the CVE strictly applies to the fact that the Android devices would respond to unsolicited packets sent to the user’s virtual IP address over the wireless interface, but this does not address the fundamental issue of the attack and did not result in a change of the reverse path settings of Android as of the most recent security update.

    This attack did not work against any Linux distribution we tested until the release of Ubuntu 19.10, and we noticed that the rp_filter settings were set to “loose” mode. We see that the default settings in sysctl.d/50-default.conf in the systemd repository were changed from “strict” to “loose” mode on November 28, 2018, so distributions using a version of systemd without modified configurations after this date are now vulnerable. Most Linux distributions we tested which use other init systems leave the value as 0, the default for the Linux kernel.

    We have described the procedure for reproducing the vulnerability with Linux and included a section illustrating the differences in architecture.

    There are 3 steps to this attack:

    1. Determining the VPN client’s virtual IP address 2. Using the virtual IP address to make inferences about active connections 3. Using the encrypted replies to unsolicited packets to determine the sequence and acknowledgment numbers of the active connection to hijack the TCP session

    There are 4 components to the reproduction:

    1. The Victim Device (connected to AP, 192.168.12.x, 10.8.0.8) 2. AP (controlled by attacker, 192.168.12.1) 3. VPN Server (not controlled by attacker, 10.8.0.1) 4. A Web Server (not controlled by the attacker, public IP in a real- world scenario)

    The victim device connects to the access point, which for most of our testing was a laptop running create_ap. The victim device then establishes a connection with their VPN provider.

    The access point can then determine the virtual IP of the victim by sending SYN-ACK packets to the victim device across the entire virtual IP space (the default for OpenVPN is 10.8.0.0/24). When a SYN-ACK is sent to the correct virtual IP on the victim device, the device responds with a RST; when the SYN-ACK is sent to the incorrect virtual IP, nothing is received by the attacker.

    To quickly demonstrate this difference, we use the nping commands on the AP device running create_ap. The source IP is the gateway of our AP, the destination IP is the virtual IP assigned to the tun interface by the VPN client, ap0 is the interface create_ap created on the attacker device, and the destination MAC is the victim’s wireless MAC address.

    For example:

    The correct address generates a RST from the victim:

    nping --tcp --flags SA --source-ip 192.168.12.1 --dest-ip 10.8.0.8 -- rate 3 -c 3 -e ap0 --dest-mac 08:00:27:9c:53:12

    The incorrect address does not elicit a response from the victim:

    nping --tcp --flags SA --source-ip 192.168.12.1 --dest-ip 10.8.0.9 -- rate 3 -c 3 -e ap0 --dest-mac 08:00:27:9c:53:12

    Similarly, to test if there is an active connection for any given website, such as 64.106.46.56, for example, we send SYN or SYN-ACKs from 64.106.46.56 on port 80 (or 443) to the virtual IP of the victim across the entire ephemeral port space of the victim. The correct four- tuple will elicit no more than 2 challenge ACKs per second from the victim, whereas the victim will respond to the incorrect four-tuple with a RST for each packet sent to it.

    To quickly test this, we suggest creating a netcat connection on the victim device, such as this:

    Netcat 64.106.46.56 80 -p 40404

    The correct four-tuple generates challenge ACKs

    nping --tcp --flags SA --source-ip 64.106.46.56 -g 80 --dest-ip 10.8.0.8 -p 40404 --rate 10 -c 10 -e ap0 --dest-mac 08:00:27:9c:53:12

    The incorrect four-tuple generates a single RST for each packet sent:

    nping --tcp --flags SA --source-ip 64.106.46.56 -g 80 --dest-ip 10.8.0.8 -p 40405 --rate 10 -c 10 -e ap0 --dest-mac 08:00:27:9c:53:12

    Finally, once the attacker determined that the user has an active TCP connection to an external server, we will attempt to infer the exact next sequence number and in-window acknowledgment number needed to inject forged packets into the connection. To find the appropriate sequence and ACK numbers, we will trigger responses from the client in the encrypted connection found in part 2. The attacker will continually spoof reset packets into the inferred connection until it sniffs challenge ACKs. The attacker can reliably determine if the packets flowing from the client to the VPN server are challenge ACKs by looking at the size and timing of the encrypted responses in relation to the attacker's spoofed packets. The victim’s device will trigger a TCP challenge ACK on each reset it receives that has an in-window sequence number for an existing connection. For example, if the client is using OpenVPN to exchange encrypted packets with the VPN server, then the client will always respond with an SSL packet of length 79 when a challenge ACK is triggered.

    The attacker must spoof resets to different blocks across the entire sequence number space until one triggers an encrypted challenge ACK. The size of the spoof block plays a significant role in how long the sequence inference takes, but should be conservative as to not skip over the receive window of the client. In practice, when the attacker thinks it sniffs an encrypted challenge-ACK, it can verify this is true by spoofing X packets with the same sequence number. If there were X encrypted responses with size 79 triggered, then the attacker knows for certain it is triggering challenge ACKs (at most 2 packets of size 79 per second).

    After the attacker has inferred the in-window sequence number for the client's connection, they can quickly determine the exact sequence number and in-window ACK needed to inject. First, they spoof empty push-ACKs with the in-window sequence while guessing in-window ACK numbers. Once the spoofed packets trigger another challenge-ACK, an in- window ACK number is found. Finally, the attacker continually spoofs empty TCP data packets with the in-window ACK and sequence numbers as it decrements the sequence number after each send. The victim will respond with another challenge ACK once the attacker spoofs the exact sequence number minus one. The attacker can now inject arbitrary payloads into the ongoing encrypted connection using the inferred ACK and next sequence number.

    This can be tested by observing the behavior from this sequence of commands, continuing with the same four-tuple:

    Using the four-tuple from the previous steps, we send RSTs in the sequence number range in blocks of 50,000 until we trigger a challenge ACK.

    nping --tcp --flags R --source-ip 64.106.46.56 -g 80 --dest-ip 10.8.0.8 -p 40404 --rate 10 -c 10 -e ap0 --dest-mac 08:00:27:9c:53:12 --seq [SEQ RANGE]

    If the packet lands in-window, the victim will respond with at most 2 challenge ACKs per second. These packets are still encrypted and originate from the virtual interface, unlike with Android, but we can still determine the contents of these packets by their size. The encrypted challenge ACK packets are larger than the encrypted RST packets. You can run tcpdump on the victim machine to accelerate the testing of his process by viewing the actual sequence and acknowledgement numbers.

    After we have found an in-window sequence number, we locate an in- window acknowledgement by spoofing empty PSH-ACKs with the in-window sequence number and guessing the acknowledgement number by dividing the acknowledgement number space into eight blocks. In most instances, seven of these blocks will trigger challenge ACKs, but one of them will not, which allows us to quickly determine which block falls within the acknowledgement window. We are interested in the block that does not respond with a challenge ACK. This behavior can be observed by using an in-window sequence number and an acknowledgement number in the block containing the correct acknowledgement number.

    nping --tcp --flags PA --source-ip 64.106.46.56 -g 80 --dest-ip 10.8.0.8 -p 40404 --rate 10 -c 10 -e ap0 --dest-mac 08:00:27:9c:53:12 -seq 12345678 --ack [ACK RANGE]

    Finally, using the in-window sequence and acknowledgement numbers, we spoof empty PSH-ACKs using the same in-windows acknowledgement number and decrementing the sequence number until we trigger another challenge ACK. This sequence number is one fewer than the next expected sequence number. We can then arbitrarily inject data into the active TCP connection.

    Continuing with our toy example:

    nping --tcp --flags PA --source-ip 64.106.46.56 -g 80 --dest-ip 10.8.0.8 -p 40404 --rate 10 -c 10 -e ap0 --dest-mac 08:00:27:9c:53:12 -seq [EXACT] --ack [IN-WINDOW] --data-string “hello,world.”

    **Operating Systems Affected:

    Here is a list of the operating systems we have tested which are vulnerable to this attack:

    Ubuntu 19.10 (systemd) Fedora (systemd) Debian 10.2 (systemd) Arch 2019.05 (systemd) Manjaro 18.1.1 (systemd)

    Devuan (sysV init) MX Linux 19 (Mepis+antiX) Void Linux (runit)

    Slackware 14.2 (rc.d) Deepin (rc.d) FreeBSD (rc.d) OpenBSD (rc.d)

    This list isn’t exhaustive, and we are continuing to test other distributions, but made usere to cover a variety of init systems to show this is not limited to systemd.

    **Operating System Variations:

    The behavior is slightly different on other operating systems. Here is a summary of the differences:

    Android: In the first phase of the attack, Android responds with unencrypted RSTs to unsolicited SYN-ACKs for the correct port and ICMP packets for the incorrect one. For the second phase, it will respond with RSTs on the correct four-tuple.

    MacOS/iOS: The first phase of the attack does not work as described here, but you can use an open port on the Apple machine to determine the virtual IP address. We use port 5223, which is used for iCloud, iMessage, FaceTime, Game Center, Photo Stream, and push notifications etc.

    We know the phone will communicate with one of the push notification servers on port 5223, and have observed that on MacOS, the port used on the victim device is not the same as the port used to connect to the VPN server, but is very close (in our testing it has always been within 10).

    nping --tcp --flags SA --source-ip 17.57.144.[84-87] -g 5223 --dest-ip 10.8.0.8 -p [X] --rate 3 -c 3 -e ap0 --dest-mac 08:00:27:9c:53:12

    For iOS devices, it does not follow this convention for choosing the client’s source port, but always choose a port between ~48000-50000 (our testing on iOS 13.1 was between 48162-49555).

    FreeBSD: The first two phases work essentially the same as Linux, however, for the last phase, the ACK number is not needed at all, so that piece of phase three can be skipped.

    OpenBSD: OpenBSD responds to spoofed SYN packets to the correct virtual IP with unencrypted RST packets, and the incorrect virtual IP elicits unencrypted NTP packets or nothing at all for the first part of the attack. For the second part, the responses are encrypted, but we can still determine which packets are challenge ACKs from the packet size, as with Linux. Connections can be reset by sending a RST with the correct sequence number.

    **Possible Mitigations:

    1. Turning reverse path filtering on

    Potential problem: Asynchronous routing not reliable on mobile devices, etc. Also, it isn’t clear that this is actually a solution since it appears to work in other OSes with different networking stacks. Also, even with reverse path filtering on strict mode, the first two parts of the attack can be completed, allowing the AP to make inferences about active connections, and we believe it may be possible to carry out the entire attack, but haven’t accomplished this yet.

    2. Bogon filtering

    Potential problem: Local network addresses used for vpns and local networks, and some nations, including Iran, use the reserved private IP space as part of the public space.

    3. Encrypted packet size and timing

    Since the size and number of packets allows the attacker to bypass the encryption provided by the VPN service, perhaps some sort of padding could be added to the encrypted packets to make them the same size. Also, since the challenge ACK per process limit allows us to determine if the encrypted packets are challenge ACKs, allowing the host to respond with equivalent-sized packets after exhausting this limit could prevent the attacker from making this inference.

    We have prepared a paper for publication concerning this vulnerability and the related implications, but intend to keep it embargoed until we have found a satisfactory workaround. Then we will report the vulnerability to oss-security@lists.openwall.com. We are also reporting this vulnerability to the other services affected, which also includes: Systemd, Google, Apple, OpenVPN, and WireGuard, in addition to distros@vs.openwall.org for the operating systems affected.

    Thanks,

    William J. Tolley Beau Kujath Jedidiah R. Crandall

    Breakpointing Bad & University of New Mexico
  2. New Vulnerability Lets Attackers Hijack VPN Connections on Most UNIX Systems

    Affecting most GNU/Linux distributions, as well as FreeBSD, OpenBSD, Android, iOS and macOS systems, the new security vulnerability could allow a local attacker to determine if another user is connected to a VPN (Virtual Private Network) server and whether or not there's an active connection to a certain website.

    The vulnerability (CVE-2019-14899) is exploitable with adjacent network access, which requires the attacker to have access to either the broadcast or collision domain of the vulnerable operating system, and lets attackers to hijack connections by injecting data into the TCP (Transmission Control Protocol) stream.

    The vulnerability has been reported to work against various popular VPN solutions, including OpenVPN, IKEv2/IPSec, as well as WireGuard, and it doesn't matter which VPN technology is being used, thus allowing attacker to determine the type of packets being sent through the encrypted VPN tunnel.

  3. Tricky VPN-busting bug lurks in iOS, Android, Linux distros, macOS, FreeBSD, OpenBSD, say university eggheads

    A bug in the way Unix-flavored systems handle TCP connections could put VPN users at risk of having their encrypted traffic hijacked, it is claimed.

    The University of New Mexico team of William Tolley, Beau Kujath, and Jedidiah Crandall this week said they've discovered CVE-2019-14899, a security weakness they report to be present in "most" Linux distros, along with Android, iOS, macOS, FreeBSD, and OpenBSD. The upshot is, if exploited, encrypted VPN traffic can be potentially hijacked and disrupted by miscreants on the network.

    To pull off the attack, the US-based posse says, a hacker would need to be "network adjacent" to their target, or control an access point on the victim's local network. Once the victim connected to their VPN, the spy would be able to, for one thing, tamper with the TCP stream to do things like inject packets into the stream.

  4. New Linux Vulnerability Lets Attackers Hijack VPN Connections

    Security researchers found a new vulnerability allowing potential attackers to hijack VPN connections on affected *NIX devices and inject arbitrary data payloads into IPv4 and IPv6 TCP streams. They disclosed the security flaw tracked as CVE-2019-14899 to distros and the Linux kernel security team, as well as to others impacted such as Systemd, Google, Apple, OpenVPN, and WireGuard. The vulnerability is known to impact most Linux distributions and Unix-like operating systems including FreeBSD, OpenBSD, macOS, iOS, and Android. A currently incomplete list of vulnerable operating systems and the init systems they came with is available below, with more to be added once they are tested and found to be affected: Ubuntu 19.10 (systemd), Fedora (systemd), Debian 10.2 (systemd), Arch 2019.05 (systemd), Manjaro 18.1.1 (systemd), Devuan (sysV init), MX Linux 19 (Mepis+antiX), Void Linux (runit), Slackware 14.2 (rc.d), Deepin (rc.d), FreeBSD (rc.d), and OpenBSD (rc.d).

  5. New Linux Vulnerability Lets Attackers Hijack VPN Connections

    Security researchers found a new vulnerability allowing potential attackers to hijack VPN connections on affected *NIX devices and inject arbitrary data payloads into IPv4 and IPv6 TCP streams.

    They disclosed the security flaw tracked as CVE-2019-14899 to distros and the Linux kernel security team, as well as to others impacted such as Systemd, Google, Apple, OpenVPN, and WireGuard.

  6. New vulnerability lets attackers sniff or hijack VPN connections

    The vulnerability -- tracked as CVE-2019-14899 -- resides in the networking stacks of multiple Unix-based operating systems, and more specifically, in how the operating systems reply to unexpected network packet probes.

  7. Hackers Can Hijack VPN Connections Using A New Linux Vulnerability

    Researchers have found a vulnerability on most Linux distros and *NIX devices which allow hackers to hijack the VPN connections and inject malicious data into the TCP stream.

    The security researchers found the vulnerability in most Linux distributions and operating systems such as Linux, FreeBSD, OpenBSD, macOS, iOS, and Android.

  8. Linux security flaw could let VPN connections be hacked

    The Breakpointing Bad cybersecurity research team from the University of New Mexico discovered and reported on a security flaw which could allow malicious actors to hack Virtual Private Network (VPN) connections.

    William J. Tolley, Beau Kujath, and Jedidiah R. Crandall said the flaw impacts Linux, Android, macOS and other Unix-based operating systems and could allow attackers to sniff, hijack and tamper with VPN-tunnelled connections. The vulnerability was named CVE-2019-14899, with the researchers claiming it takes advantage of how operating systems handle unexpected network probes.

  9. Linux Flaw Allows VPN Hijacking

    A number of Linux distributions, including Ubuntu, Fedora, and Debian, contain a newly discovered vulnerability that an attacker could use to determine whether an individual is using a VPN and then potentially hijack that encrypted connection.

    A research team from the University of New Mexico discovered the vulnerability and developed an attack to exploit it. The attack has some specific requirements and relies on some analysis of the traffic going to and from the target device running the VPN client. The attack is confirmed to work against WireGuard and OpenVPN, but the researchers said that the VPN a victim is using doesn’t really matter. The main prerequisite for the attack to work is for the attacker to be able to send unsolicited packets to the victim’s VPN client.

  10. New Linux vulnerability lets attackers to hijack VPN connections

    Three researchers from the University of New Mexico and Breakpointing Bad have identified vulnerability in the way Unix and Linux-based operating systems like the macOS handle the TCIP connections. Researchers believe that vulnerability can specifically affect VPN users by hijacking encrypted traffic.

  11. New Linux Bug Lets Attackers Hijack Encrypted VPN Connections

    A team of cybersecurity researchers has disclosed a new severe vulnerability affecting most Linux and Unix-like operating systems, including FreeBSD, OpenBSD, macOS, iOS, and Android, that could allow remote 'network adjacent attackers' to spy on and tamper with encrypted VPN connections.
    The vulnerability, tracked as CVE-2019-14899, resides in the networking stack of various operating systems and can be exploited against both IPv4 and IPv6 TCP streams.
    Since the vulnerability does not rely on the VPN technology used, the attack works against widely implemented virtual private network protocols like OpenVPN, WireGuard, IKEv2/IPSec, and more, the researchers confirmed.
    This vulnerability can be exploited by a network attacker — controlling an access point or connected to the victim's network — just by sending unsolicited network packets to a targeted device and observing replies, even if they are encrypted.

  12. VPN Bug Affects “Most” Linux Distros

    A team of security researchers from the University of New Mexico has disclosed a new vulnerability that could allow attackers to probe devices and determine various details about the VPN (Virtual Private Network) connection status of a user.

    The security vulnerability (CVE-2019-14899) appears to affect most GNU/Linux distributions, besides FreeBSD, OpenBSD, Android, iOS and macOS systems. William J. Tolley, one of the security researchers, explained in a post that the vulnerability could let attackers to determine if another user is connected to a VPN, the virtual IP address they have been assigned by the VPN server, and also sniff out whether or not there is an active connection to a given website.

  13. OpenBSD devs patch authentication bypass bug

    One of the internet’s most popular free operating systems allowed attackers to bypass its authentication controls, effectively leaving the keys in the back door, according to an advisory released this week. The developers of the OpenBSD system have already patched the vulnerability.

    OpenBSD allowed people access to its smtpd, ldapd, and radiusd programs – which send mail, allow access to user directories, and allow remote access to the computer system. All an attacker needed to do was enter a specific word prefixed by a hyphen as a username.

    Qualys Research Labs found four bugs in BSD Authentication, which is the code that OpenBSD uses to authenticate users. Three of them were local privilege escalation bugs, while the other, CVE-2019-19521, bypassed the authentication system altogether. According to its security advisory, BSD Authentication supports four authentication styles: password, a one-time password mechanism called S/Key, and Yubico’s YubiKey hardware token.



  14. New Linux vulnerability puts VPN connections at risk of hijacking

    Furthermore, the research team also identified the SEQ and ACK numbers from inspecting the encrypted packet size and number and managed to inject data into the TCP steam, which led to the hijacking of the connection. This means VPN technology was ineffective in preventing the attack since even encrypted packets could be assessed.

    After testing on Manjaro 18.1.1, CentOS, and Ubuntu 19, researchers discovered that the exploit was applicable to both IPv4 and IPv6. Other systems that are vulnerable to exploitation include Void Linux, Debian 10.2, Slackware 14.2, Arch 2019.5, MX Linux 19, Deepin, Fedora, Devuan, FreeBSD, and OpenBSD. They will be testing the effectiveness of the exploit against Tor as well.

  15. Attackers using Linux Vulnerability to Hijack VPN Connections
  16. Linux VPN connections can be hacked

    Insecurity experts at Breakpointing Bad have found aa new vulnerability allowing potential attackers to hijack VPN connections on affected *NIX devices and inject arbitrary data payloads into IPv4 and IPv6 TCP streams.

    The security flaw tracked as CVE-2019-14899 to distros and the Linux kernel security team, as well as to others impacted such as Systemd, Google, Apple, OpenVPN, and WireGuard. The vulnerability is known to impact most Linux distributions and Unix-like operating systems including FreeBSD, OpenBSD, macOS, iOS, and Android.

    A currently incomplete list of vulnerable operating systems and the init systems they came with is available below, with more to be added once they are tested and found to be affected: Ubuntu 19.10 (systemd), Fedora (systemd), Debian 10.2 (systemd), Arch 2019.05 (systemd), Manjaro 18.1.1 (systemd), Devuan (sysV init), MX Linux 19 (Mepis+antiX), Void Linux (runit), Slackware 14.2 (rc.d), Deepin (rc.d), FreeBSD (rc.d), and OpenBSD (rc.d).

  17. VPN connections could be hacked due to Linux security flaw

    A new vulnerability that could allow potential attackers to hijack VPN connections on affected NIX devices and inject arbitrary data payloads into IPv4 and Ipv6 TCP streams has been discovered by security researchers.

    The researchers disclosed the security flaw they detected, tracked as CVE-2019-14899, to Linux distro makers, the Linux kernel security team and to others that are impacted including systemd, Google, Apple, OpenVPN and WireGuard.

  18. Unix-like Systems Vulnerable to VPN Inferring and Hijacking Attacks

    Three researchers from Breakpointing Bad and the University of New Mexico have discovered a vulnerability that exists in Linux and Unix-like operating systems like Android and macOS. Given the tracking code “CVE-2019-14899”, the flaw resides in the routing table code and the TCP code that is present in these systems. The vulnerability allows an attacker to perform traffic analysis via clever use of encrypted DNS queries in conjunction with error messages, leading to the sniffing of open TCP connection information. The attack was discovered quite a while back, but the researchers disclosed it publicly now, and after they allowed the vendors some time to plug the holes.

  19. Researchers say VPN bug affects Linux, Unix systems
  20. Linux Bug Opens Most VPNs to Hijacking

    In a coffee-shop scenario, attackers can hijack “secure” VPN sessions of those working remotely, injecting data into their TCP streams.

    A vulnerability in most Linux distros has been uncovered that allows a network-adjacent attacker to hijack VPN connections and inject rogue data into the secure tunnels that victims are using to communicate with remote servers.

    According to researchers at University of New Mexico and Breakpointing Bad, the bug (CVE-2019-14899), “allows…an attacker to determine if…a user is connected to a VPN, the virtual IP address they have been assigned by the VPN server, and whether or not there is an active connection to a given website.”

  21. New vulnerability lets attackers sniff or hijack VPN connections


  22. Researchers find a new Linux vulnerability that allows attackers to sniff or hijack VPN connections

    On Wednesday, security researchers from the University of New Mexico disclosed a vulnerability impacting most Linux distributions and Unix-like operating systems including FreeBSD, OpenBSD, macOS, iOS, and Android. This Linux vulnerability can be exploited by an attacker to determine if a user is connected to a VPN and to hijack VPN connections.

    The researchers shared that this security flaw tracked as CVE-2019-14899, “allows a network adjacent attacker to determine if another user is connected to a VPN, the virtual IP address they have been assigned by the VPN server, and whether or not there is an active connection to a given website.” Additionally, attackers can determine the exact sequence and acknowledgment numbers by counting encrypted packets or by examining their size. With this information in hand, they can inject arbitrary data payloads into IPv4 and IPv6 TCP streams.



  23. Hackers Exploit New Linux Vulnerability To Hijack VPN Connections

    The attack has been reported to work against several popular VPN solutions, including OpenVPN, IKEv2/IPSec, and WireGuard.

    However, the researchers are still testing their viability against Tor, as it works in a SOCKS layer and implements authentication and encryption that takes place in userspace.

    “It should be noted, however, that the VPN technology used does not seem to matter and we are able to make all of our inferences even though the responses from the victim are encrypted, using the size of the packets and number of packets sent (in the case of challenge ACKs, for example) to determine what kind of packets are being sent through the encrypted VPN tunnel,” clarifies the research team.



Recent Techrights' Posts

An "Efficient Windows 11 Experience" is Removing a Text Editor (Less than 5 Megabytes in Size) and Adding Chatbots That Require a New PC/Datacentre
Vista 11 24H2 update removes WordPad
 
A 3-Year Campaign to Coerce/Intimidate Us Into Censorship: Targeting My Wife
In my view, it is a form of overt sexism
[Chart] Chromebooks in Micronesia Grew at the Expense of Microsoft Windows
As of today...
Linus Torvalds Mocked "Cloud Native" in His Latest Talk (Arguing It's Just Hype), 'Linux' Foundation 'Research' (Marketing) Chooses Proprietary Software to Query Its Adopters
The name "Linux" is overused, abused, even grossly misused
Links 29/05/2024: More Arrests of Regime Critics and Hate Crimes
Links for the day
Brittany Day (linuxsecurity.com) Now Leverages Microsoft Chatbots to Promote Microsoft Propaganda Disguised as "Linux"
What Brittany Day does is an attack both on the Web and on Linux
[Meme] Don't Trust Users to Boot Their Own PCs?
UEFI 'secure' boot
Links 29/05/2024: Hack The Box, Why I Left Healthcare, and Chatbots as Health Risk
Links for the day
Gemini Links 29/05/2024: BESM Retro Second Edition and Itanium Day
Links for the day
Azerbaijan: Microsoft Falls From 99.5% to Almost Nothing or Less Than 20% (Windows Down Sharply, GNU/Linux Surges)
Based on statSounter
Over at Tux Machines...
GNU/Linux news for the past day
IRC Proceedings: Tuesday, May 28, 2024
IRC logs for Tuesday, May 28, 2024
The Campaign to 'End' Richard Stallman - Part I - Two Canceled Talks in a Row?
RMS has left Europe, so the concept of "delayed" talk is facetious or deeply cynical
On Desktops/Laptops in Andorra Windows Fell to Less Than Half, 20% If One Counts Mobile as Well
And this is a European country
[Meme] 3 Years Later
If you're going to start a fight, make sure you can handle it
When You Leave a Bad Employer and Move on to Better Things
Perhaps my main mistake was not resigning from my job sooner
No, Your Site Likely Does Not Need WordPress
I was one of the first users of WordPress
GNU/Linux in Cameroon: Rising Steadily While Windows Falls From 99% to Just 6%
If one also counts mobile (mostly Android)
Monkey See, Monkey Share
on deprivation of users
From 0.17% to 10% or More (GNU/Linux in Dominica)
Dominica isn't well known, but it does seem to have embraced Chromebooks in recent years
Links 28/05/2024: Tensions in East Asia, UK Mandatory National Service
Links for the day
Gemini Links 28/05/2024: NetCrawl and Living in Lagrange
Links for the day
Guardian Digital, Inc (linuxsecurity.com) Handed Over Its Web Site to Chatbots That Generate SEO Garbage
They need to be called out on it
statCounter Sees Microsoft Windows at Below 1% in American Samoa
Not even 1%!
Windows Down to 60% of Guam's Desktops/Laptops and Down to a Quarter Overall
No wonder Microsoft is panicking
Today in UEFI 'Secure' Boot Debates (the Frog is Already Boiling and Melting)
Over at LQ today
[Meme] A "Modern" Web's Message in a Bottle
So-called 'security'
Brittany Day: Still Chatbot Slinging, Producing Fake 'Articles' About "Linux"
random garbage produced (and censored) by Microsoft
Almost 4k Gemini Capsules, 5th Anniversary Only Weeks Away
The Web will continue to deteriorate
Microsoft: $1 Million a Day for Contempt of Court Orders (Justice Department)
Microsoft behaves as if it's 100% exempt from laws
Catbodia? In Cambodia, Microsoft's Windows Fell to All-Time Low of Less Than a Quarter.
Cambodia is leaving Microsoft behind
[Meme] Deadnaming
Guess who uses a name that was deprecated well over a decade ago?
[Meme] 'Secure' Boot in a Nutshell
Ask Microsoft if it is "safe" to boot Linux
New Press Report Explains Microsoft Severance and Quiet (Undisclosed) Layoffs
Some people will call this "loophole", whereas others will opine that it is outright illegal (but kept secret to circumvent scrutiny)
Global South is Android/Linux (Windows Era Has Come to an End Already)
I've decided to take a quick glance at South American trends for all operating systems
[Meme] Unified Patent Troll
Unified Patent Court remains illegal and unconstitutional
The European Patent Office is Sinking
Officials (or national delegates) at the European Patent Organisation have long been warned about this (by staff representatives from the European Patent Office), but they ignored the warnings
A 3-Year Campaign to Coerce/Intimidate Us Into Censorship: Targeting Guest Writers (Intimidation)
Some high-profile people have told me that the serial defamer is a "monster" (their word), so why would Neil Brown wish to help him?
Summer in the Air
We have a good pace going on owing to health, positivity, inertia and good software tools
GNU/Linux Activity in Belize
From an economic point of view, Microsoft needn't worry about Belize, but when it comes to preserving the Windows monopoly/monoculture Belize matters
Links 28/05/2024: Back to MP3, NVIDIA Sued by Authors
Links for the day
Gemini Links 28/05/2024: Bad Beach and TLS
Links for the day
Microsoft Windows Fell From 100% to Just 7.5% in Sierra Leone
Based on statCounter
In Benin, Microsoft's Windows Fell Below 10%, GNU/Linux Surged to 6% or Higher on Desktops/Laptops
That's nearly 7% - a lot higher than the average in Africa
Over at Tux Machines...
GNU/Linux news for the past day
IRC Proceedings: Monday, May 27, 2024
IRC logs for Monday, May 27, 2024
Delayed Series About Dr. Richard Stallman
A lot of the attacks on him boil down to petty things
[Meme] Elephant in the Asian Room
With ChromeOS included GNU/Linux is at 6% across Asia
GNU/Linux in Bangladesh Up From 0.5% to Over 4% (Windows Slid From 95% to 18%)
Bangladesh is one of the world's most densely-populated countries
A 3-Year Campaign to Coerce/Intimidate Us Into Censorship: Targeting Several Webhosts (in Collaboration and Conjunction With Mentally-Ill Flunkies)
Every attempt to nuke the current hosting failed, but it's still worth noting
Links 27/05/2024: One Month Left for ICQ, More Openwashing Highlighted
Links for the day
Gemini Links 27/05/2024: Back to GNU/Linux, Librem 5 Assessed
Links for the day
StatCounter (or statCounter) Has Mostly Recovered From a Day's Downtime (Malfunction)
Some of the material we've published based on the statCounter datasets truly annoys Microsofters
Google: We Don't Have Source Diversity, But We Have Chatbot Spew in Place of Sources (and It's Not Even Accurate)
Search engines and news search never looked this bad...
[Meme] Security is Not a Failure to Boot (or Illusion of Security Due to 'Unknown' System)
Red Hat is largely responsible for this mess
What is Secure Boot?
Security means the user feels safe and secure - i.e. confident that the machine would continue to work following a reboot or a system upgrade (or kernel upgrade)
StatCounter (or statCounter) Has Been Broken for Nearly 24 Hours. Who Benefits? Microsoft.
StatCounter is broken right now and has been broken for nearly 24 hours already
Links 27/05/2024: Chatbots Generate Hateful Output, TPM Performance Scrutinised
Links for the day
David Heinemeier Hansson (DHH) Realises What He Should Have Decades Ago
seeing that DHH is moving away from Apple is kind of a big deal
Reinvigorating the Voice of GNU/Linux Users (Not Companies Whose Chiefs Don't Even Use GNU/Linux!)
Scott Ruecker has just announced his return
"Tech" in the Context of Even Bigger Issues
"Tech" (or technology) activism is important; but there's a bigger picture
A Decade of In-Depth Coverage of Corruption at the European Patent Office (EPO)
The world needs transparency and sunlight
Hopefully Not Sunset for StatCounter
We hope that StatCounter will be back soon.
Over at Tux Machines...
GNU/Linux news for the past day
IRC Proceedings: Sunday, May 26, 2024
IRC logs for Sunday, May 26, 2024
Links 27/05/2024: Self-Publishing, Patent Monopolies, and Armed Conflicts
Links for the day
Gemini Links 27/05/2024: Tethering Connection and PFAs
Links for the day
Imagine Canada Enabling Rapists to Harass Their (Rape) Victims
This analogy is applicable because abusers are empowered against the abused