EditorsAbout the SiteComes vs. MicrosoftUsing This Web SiteSite ArchivesCredibility IndexOOXMLOpenDocumentPatentsNovellNews DigestSite NewsRSS

01.15.20

When Microsoft’s Actions Speak for Themselves (About Back Door Access)

Posted in Deception, Microsoft, Security at 2:30 am by Guest Editorial Team

Microsoft back doors

Summary: Unwittingly, people are being reminded of the ‘special relationship’ between Microsoft and the US Army (or government); The back doors or bug doors are still there, even 7 years after Edward Snowden’s NSA leaks

“Suspect…”

That’s how our reader described the article “Microsoft patches big Windows flaw discovered by NSA” (one of several of this kind published yesterday) and specifically the above portions, which were highlighted by this reader.

We’ve written a great deal about Microsoft back doors — as there are many kinds of these — and yesterday a reader showed us how a con man CEO (faking financial performance) pretends that Microsoft fights for working encryption when it fact we know for a fact Microsoft did the opposite for at least 2 decades. When Microsoft says “security” it means “national” (i.e. Pentagon-controlled) ‘security’. Windows has been very imperialistic since the antitrust trial concluded, leaving Microsoft in tact but under tighter government controls.

12.31.19

Why Large Nations Like China and Russia Will Gradually Move to GNU/Linux

Posted in GNU/Linux, Microsoft, Security, Windows at 8:25 am by Dr. Roy Schestowitz

Sunday’s news report suggests that China proceeds with its GNU/Linux migration

'Two security researchers have developed a new technique that essentially bypasses all of the memory protection safeguards in the Windows Vista operating system...'~Dennis Fisher, August 7th, 2008

Summary: Microsoft Windows is an imperialistic operating system (or bootable malware) and it is therefore imperative for nations that pursue real sovereignty to wean themselves off it altogether

IN a recent public talk of Richard Stallman he succinctly explained in very clear terms that many people are led to assume that they give instructions to computers they use. They think they’re actually the owners of these computers, whereas the topology is all ‘in reverse’; in practice, owing to the way software was coded or hard-coded, the real owner is the company behind the software and instructions are transmitted to the computers by this company instead of the user. To them, the user is just something to be exploited, ‘monetised’ (when the user is spied on there’s data to be sold, as we noted yesterday in relation to Phoronix). Windows, for example, is designed for data-mining and therefore — by its very design — it’s optimises for insecurity (remote access, harvesting) rather than security. Windows will never be secure because it’s not supposed to be. Those who think that Windows can be made secure evidently fail to grasp what Windows actually is and who it works for.

In countries that wish to control their computing — including their servers — Free software is imperative. Thankfully we’ve been seeing policies implemented by large governments in recent years that will bring rise to GNU/Linux use, even on desktops and laptops.

Michael S. Rogers
“I don’t want a back door. I want a front door.” — Director of the National Security Agency (NSA), 2015

12.30.19

Quantcast: Not a Decent Way to Treat Site Visitors, Paying Members (Subscribers) Included

Posted in Security at 11:39 am by Dr. Roy Schestowitz

Phoronix “VALUES YOUR PRIVACY” (but not upstream)

Phoronix VALUES YOUR PRIVACY

Summary: Phoronix has a privacy problem and it prevents the site from broadening its reach or increasing its appeal to geeks

TECHRIGHTS supports Phoronix and this is why it cares. It doesn’t ignore the above issue, which is longstanding. Michael Larabel explained to me that a ‘parent’ company had imposed that (more or less). So I’ve researched this a little, having seen negative comments in the forums (in response to the fund-raiser, which ends right about now). I didn’t want to ‘interfere’ with this fund-raiser, so I withheld criticism for a while.

“…I’ve researched this a little, having seen negative comments in the forums (in response to the fund-raiser, which ends right about now).”Larabel is a hard-working man. Very hard-working. I can relate to his dedication. He now also needs to support 3 people (a baby was recently born). I totally get that. But having ‘only’ like a thousand trackers in every single page (notice that the above list is alphabetical), each tracker with its own unique surveillance policy (linked to from that list), is a little too much. Pages that should take just a second or so to load can take an order or magnitude longer to fully load. Most of what’s happening isn’t visible; it happens in the background, at many server sides and also at the user’s end, owing to proprietary JavaScript code. I studied this to the extent possible. The ‘gory’ JavaScript dissection is beyond the scope of this post. There’s locational tracking as well.

“As of several weeks ago, charts stopped showing up in benchmarks/articles unless JavaScript is enabled and that makes matters worse.”Never mind the paywall; never mind the many ads that accompany each page, forums included. I can understand why some Phoronix supporters would stop blocking ads in that site. To me, personally, the spying is the main issue. It makes each page like somewhat of a ‘malware’. Bloated also, but that’s a technical matter… as bloat/clumsiness does not necessarily imply malice.

May we politely and kindly suggest that Larabel speaks to the patron about removing that malicious surveillance from all pages? Based on the forums, this is rather off-putting. Readers are generally very technical, so they know what’s going on and some publicly complain. It reduces traffic, no doubt, and keeps some people off the site. Remove the spying and traffic will increase; Tux Machines would certainly link to it a lot more. It used to be a fast, lean site. That’s just no longer the case with JavaScript enabled. As of several weeks ago, charts stopped showing up in benchmarks/articles unless JavaScript is enabled and that makes matters worse. It makes some links dreadful to click on and some pages impossible to read (without running proprietary programs).

12.07.19

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

Posted in FUD, GNU/Linux, Security at 1:16 pm by Dr. Roy Schestowitz

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.

09.15.19

‘Open Source’ You Cannot Run Without Renting or ‘Licensing’ Windows From Microsoft

Posted in Apple, Free/Libre Software, Microsoft, Security, Vista 10, Windows at 8:30 am by Dr. Roy Schestowitz

“I would love to see all open source innovation happen on top of Windows.”

Steve Ballmer, Microsoft CEO

“[Windows Vista DRM] seems a bit like breaking the legs of Olympic athletes and then rating them based on how fast they can hobble on crutches.“

Peter Gutmann

Summary: When so-called ‘open source’ programs strictly require Vista 10 (or similar) to run, how open are they really and does that not redefine the nature of Open Source while betraying everything Free/libre software stands for?

What good is “open source” that needs a back-doored, proprietary software (i.e. back doors cannot be removed) operating system with spying and DRM just to run it? We recently wrote about this kind of situation, offering examples from both Apple and Microsoft.

“And they say “soon open source” without specifying a licence or anything.”Here comes another new example from GHacks (lots of those lately; mostly from this site). “Sandboxie, a sandbox program for Microsoft’s Windows operating system, has been turned into a free application.” Freeware. And they say “soon open source” without specifying a licence or anything. Might as well turn out to be vapourware at the end…

Tabloid troll Catalin Cimpanu is already openwashing this proprietary software based on a promise from Sophos alone. Let’s rejoice “open source” that runs only on Windows. CBS and its tabloid ZDNet are once again proving to be Microsoft propaganda and this article comes from the person who constantly slanders Linux. Help Net Security said: “Sophos plans to open-source Sandboxie, a Windows utility that allows users to run apps in a sandbox. Until that happens, they’ve made the utility free.”

“When “open source” runs only on a proprietary platform with NSA back doors what is it really worth?”BetaNews — just like the above — put “open source” in the headline even though it’s only freeware. Great! And even though it’s Windows only; just like Steve Ballmer wanted…

When “open source” runs only on a proprietary platform with NSA back doors what is it really worth? Is it good for anything? Also, it’s not security; just illusion of it…

They claim that these applications improve security, but these applications only run on a platform with NSA back doors. Here’s another new example, this one of an “app” that only runs on iOS. “If you’re looking for an alternative for Google Authenticator, Microsoft Authenticator, LastPass Authenticator, or Authy, you may want to give Authenticator a chance,” it says. How does that improve security? The underlying operating system has well known back doors. The company that monopolised maintainer-ship works with the NSA and is in the PRISM spy programme. Ed Snowden’s leaks provided actual evidence and 2 years ago Wikileaks added more with Vault 7.

“Notice that all the above are security-oriented programs but not a single platform without NSA back doors is supported.”A similar example was covered 3 days ago by GHacks: “WinOTP Authenticator is an open-source alternative for WinAuth”

The “Win” means Windows; it means you lose security. You lose privacy. When “open source” runs only under proprietary software stacks with NSA back doors, such as Vista 10 (strictly in this case), a vendor can only pretend it offers security…

One of the virtues extolled by Free software proponents is superior security; well, how much do such claims hold when one must rent (license, temporarily) a bunch of dodgy binaries from NSA partners to run the said program/s? Notice that all the above are security-oriented programs but not a single platform without NSA back doors is supported.

09.09.19

Security Boulevard is a Microsoft-Connected Attack Site Created by a Free Software-Hostile Person

Posted in Free/Libre Software, FUD, Microsoft, Security at 1:04 am by Dr. Roy Schestowitz

Anti-FOSS is to be expected. It’s the business model.

Alan Shimel
This is the founder of Security Boulevard attacking Stallman simply because he occasionally speaks of Palestinians’ human rights (article bumped up by the publisher earlier this summer)

Summary: Free/Open Source software (FOSS) is being discredited using an aggregator of Microsoft-connected FUD firms, concurring with or confirming the Halloween Documents that suggested attacking FOSS by proxy

OUR daily links can be tricky to prepare because we’re reluctant to link to FUD and misinformation. So years ago we added the “Openwashing” section to it and under “Security” we often add editorial comments (corrections and clarification attempts). The FUD typically comes from the same domains. For instance, sites called “Windows” something or “Microsoft” something are likely to be Linux-hostile sources (sometimes they push Vista 10 under the guise of “Linux”, e.g. WSL).

“The FUD typically comes from the same domains. For instance, sites called “Windows” something or “Microsoft” something are likely to be Linux-hostile sources (sometimes they push Vista 10 under the guise of “Linux”, e.g. WSL).”A lot of FOSS FUD is also sourced back to ZDNet, which became an anti-FOSS propaganda machine, funded in part by Microsoft (Microsoft buys ads and bias from CBS, the parent company). Last night we saw “Lilu/Lilocked ransomware has now infected thousands of Linux servers” (this is the third such ‘report’ we see; it started with ZDNet where this got disseminated and spun as a major “Linux” issue).

Then there’s Security Boulevard, where the ‘content’ is rarely original. They mostly attack licensing and security aspects of Free software. It’s endemic. This gateway-as-a-’news’-site acts as an amplifier/loudspeaker/megaphone of anti-FOSS firms, usually Microsoft-connected ones. WhiteSource is to Microsoft the ‘new’ Black Duck and it’s a regular feature there, along with Black Duck’s parent company, Snyk, and other parasites looking to sell themselves by bashing FOSS.

Security Boulevard and WhiteSource are now working together on a “webinar” (published days ago); WhiteSource also works closely with Microsoft (co-authoring anti-FOSS papers and they are formally partners). This means that Shimel at Security Boulevard is indirectly in bed with Microsoft and is likely ‘in it’ to attack FOSS. It’s not hard to see whose voice he’s looking to facilitate. His track record was mentioned here last month and many times a decade ago when he published FOSS-hostile pieces in IDG’s “Open Source” section [1, 2, 3, 4, 5] (also see the screenshot at the top). That section of IDG (the “Open Source Subnet”) was, at least at the time, infested with people who neither understood nor liked FOSS. In fact the “Open Source Subnet” was like an extension of their “Microsoft Subnet”; only the titles varied.

As recently as days ago we saw Microsoft-connected firms (anti-FOSS FUD firms, including WhiteSource, as we noted half a decade back) again being boosted with their anti-FOSS venom by this anti-FOSS, anti-RMS, pro-Microsoft Shimel-founded Security Boulevard. It’s like its sole role is to propel these firms into Google News, ‘dressing up’ corporate lies as ‘news’.

Be careful, people; the site is pure poison which amplifies more poison. It amplifies Microsoft partners, whose principal role is delegitimising FOSS.

07.30.19

Microsoft Kills: An Introduction

Posted in Microsoft, Security, Windows at 2:42 am by Dr. Roy Schestowitz

“Our products just aren’t engineered for security.”

Brian Valentine, Microsoft executive

Microsoft gives NSA backdoor, complains about exploits

Summary: Unfit-for-use Windows, as well as other software from Microsoft, has a high mortal cost (not just monetary cost) that the media fails to properly report on

IT IS no secret that the use of Microsoft Windows causes many fatalities. In our daily links we’ve included hundreds of links to press articles about hospitals getting stung/hit by ransomware, among other modern menaces that follow a digital compromise (seizure of hospital facilities and equipment). This is killing a lot of Americans every day, but corporate media is not talking about it (not in the correct terms) and it is habitually misplacing blame. The media and NSA-like agencies, for example, couldn’t care less about the role of back doors (making systems deliberately less secure); it’s more important for them to maintain back doors on almost every computer on the planet (at the expense of people/patients who die from these back doors).

“It serves to show that these incidents aren’t even rare anymore. They’ve become a sort of new ‘norm’ — however menacing and disturbing a norm.”Sometimes the media mentions what the compromised systems were built on, but usually it’s intentionally obscured. In this series we shall explain that it’s typically Windows. We shall soon be covering Microsoft’s role in killing patients. By all means Microsoft is culpable and it isn’t just incompetent and corrupt; people actually die — sometimes in big numbers — because of these criminals who work with the state and bribe states; they put their insecure-by-design systems inside hospitals. Gates and his flunkies would of course blame the victims, notably these hospitals.

Before we commence this series, which will be based on inside sources, here are some news clippings of interest (recent news). It serves to show that these incidents aren’t even rare anymore. They’ve become a sort of new ‘norm’ — however menacing and disturbing a norm.

windows-ransomware-1

windows-ransomware-2

windows-ransomware-3

windows-ransomware-4

windows-ransomware-5

windows-ransomware-6

windows-ransomware-7

windows-ransomware-8

windows-ransomware-9

windows-ransomware-10

windows-ransomware-11

windows-ransomware-12

windows-ransomware-13

windows-ransomware-14

windows-ransomware-15

windows-ransomware-16

windows-ransomware-17

windows-ransomware-18

windows-ransomware-19

windows-ransomware-20

windows-ransomware-21

windows-ransomware-22

windows-ransomware-23

windows-ransomware-24

windows-ransomware-25

windows-ransomware-26

windows-ransomware-27

windows-ransomware-28

windows-ransomware-29

windows-ransomware-30

windows-ransomware-31

07.20.19

Slack Committed a Very Major Crime That Can Cost Many Billions If Not Trillions in Damages for Years to Come

Posted in Security at 5:32 am by Dr. Roy Schestowitz

Bankruptcy must follow, maybe arrests as well (the company’s logo gives away the company’s real worth and values)

Slack's new logo is a penis swastika

Summary: The inevitable has happened to Slack, which no longer deserves to exist as a company; moreover, the people who ran the company must be held criminally accountable

TO say that Slack got merely “compromised” would be the understatement of the decade. Yes, it did in fact get compromised, but it’s a lot worse. It’s far worse than a compromise per se. We’re going to explain, starting with the basics.

Slack is malware. Not just the ‘app’. Their Web site hardly works with any Web browser – they want the very worst and privacy-hostile browsers to be used for extraction of data. It’s a resource hog because it’s malware disguised as an IRC ‘clone’.

“It’s a resource hog because it’s malware disguised as an IRC ‘clone’.”Slack the ‘app’ is literal malware. It follows you around if you install it on a phone. The browser side is also malicious, but it’s less capable of geographical/location tracking. They use it for data-mining. See the source code (page source at least). It’s malware. GDPR should be applicable here and we suspect that EU authorities have not assessed that aspect just yet.

Slack is not a communications platform but a data harvester with an interface that looks like a communications platform. What it is to users isn’t what it is to Slack, the company. The Electronic Frontier Foundation (EFF) issued strongly-worded warnings about Slack and even Microsoft, the NSA back doors giant that kick-started PRISM, outright banned Slack for security reasons! Yes, Slack is really that bad. We won’t even call this ‘anticompetitive’ on Microsoft’s behalf; Microsoft does have a few engineers and they very well understand what Slack is and why it must be avoided. Even unqualified Microsoft hacks can understand that. Slack was always a ticking time bomb, which I warned about before, e.g. here in Tux Machines. I very much foresaw the latest disaster. I did all that I could to spread information about it, at the very least to ensure people are forewarned. Now I feel vindicated, but how much damage will be done for years if not decades to come? It’s difficult to assess or measure because it’s almost impossible to track the sources of rogue actors’ data.

“It’s the complete doomsday scenario, an equivalent of having one’s own Jabber server completely and totally hijacked, and all communications in it (names, passwords) stolen.”Slack did not have a mere ‘incident’. It was a CATASTROPHE! They knew about it for quite some time (at higher levels, too). It’s the complete doomsday scenario, an equivalent of having one’s own Jabber server completely and totally hijacked, and all communications in it (names, passwords) stolen. But in the case of Slack millions of businesses are affected. In one fell swoop. Just like that. Even the public sector. Military, hospitals, you name it…

Slack got totally ‘PWNED’, but they won’t admit that. They will lie about the extent of the damage, just like Yahoo and Equifax did (each time waiting months before revealing it was orders of magnitude worse). They game the news cycle that way. People must assume that all data is compromised. Everything! Slack sold everyone out and gave everything away. Even those who paid Slack (a small minority) were betrayed.

This is a major, major, MAJOR catastrophe. Businesses and their clients’ data is on Slack. Even HR stuff, which gets passed around in internal communications. Super-sensitive things like passwords, passports and so on.

Who was Slack data copied by? Mirrored or ‘stolen’, to put it another way? Possibly by rogue military actors that can leverage it for espionage and blackmail, as many do. Covertly. You rarely hear about blackmail because that’s just the nature of the blackmail. It happens silently. It’s like ‘hush money’.

Some would say Slack got “hacked” (they typically mean cracked). But it’s actually a lot worse than getting cracked! We’ll explain further…

About a month ago Slack got to its IPO milestone, the legendary capitalist pigs’ initial public offering (which one can reach even while making massive losses like Uber does). Big day for Slack! These people can pretend to be billionaires ‘on top of the world’. But they’re not. Especially as they’re not profitable at all and there’s no business model other than spying…

So for years these people consciously covered up this massive incident. Slack is therefore a criminal organisation. It must be shut down as a matter of law. These operations are illegal.

“Slack didn’t just “mess up”. It broke the law; yes, it committed an actual crime by not informing the customers.”To prevent the company from totally collapsing Slack lied to millions of people and businesses. That’s a fact. To save face…

So the only justice now would be federal and private lawsuits, forcing this company to shut down. Will anyone be arrested? Unlikely. White-collar crimes are ‘special’. No jail time (or rarely any, except as a symbolic token to the public, e.g. Madoff after the financial collapse more than a decade ago).

Slack didn’t just “mess up”. It broke the law; yes, it committed an actual crime by not informing the customers. They would change passwords etc. had they known. But Slack did not obey the law. It did not inform customers. It announced all this after the IPO, in order to make shareholders liable, and it did so late on a Friday (to minimise press coverage about this likely crime). The shareholders too should sue for concealment of critical information.

This is a very, very major scandal for Slack and if the company survives at the end, then it only means one thing: crime pays! Crime pays off. Just that. Because they committed a very major crime. Consciously. Now they need to hire PR people and lawyers. Maybe they can also bribe some journalists for puff pieces that belittle the severity of this mere ‘incident’.

As we said at the start, Slack is technically malware. Slack is surveillance. This is their business model, which isn’t even successful (so they will likely get more aggressive at spying or holding corporate data hostage in exchange for payments). For example, scrolling limits. This is like ransomware. It preys on businesses desperate to access their own data. They try to ‘monetise’ separating businesses from their data/infrastructure. It’s inherently unethical. It’s like a drug dealer’s business model/mindset.

“Companies may never know if past system breaches, identity thefts etc. were the fault of Slack.”Slack basically bet on being a ‘spy agency’ (without all the associated paperwork). And later they got cracked, passing all their surveillance ‘mine’ (trove) to even more rogue actors than the company itself. The Slack ‘incident’ doesn’t affect just Slack. Companies everywhere can now be held legally liable for having put their information on Slack servers. It’s an espionage chain. Centralisation’s doomsday in action…

Companies may never know if past system breaches, identity thefts etc. were the fault of Slack. It’s hard to prove that. But it’s guaranteed to have happened. Moreover, there are future legal ramifications.

Slack knew what had happened and why it waited all this time. This waiting makes the crime worse. This scandal can unfold for quite some time to come. The ramifications are immense! And we might not even know the full extent of these (ever). Privacy-centric competitors of Slack already capitalise on this very major scandal and use that to promote themselves; Keybase for instance…

It would be wise to move to locally-hosted FOSS. However, that would not in any way undo the damage of having uploaded piles of corporate data to Slack and their compromised servers.

Are managers at Slack criminally-liable? Probably. Just announcing this scandal after an IPO and late on a Friday when many people are on holiday won’t save Slack. They need to go bankrupt faster than the time period since their IPO. Anyone who still uses Slack must be masochistic.

“Just announcing this scandal after an IPO and late on a Friday when many people are on holiday won’t save Slack.”In the coming days many companies will come to realise that for years they tactlessly and irresponsibly gave piles of personal/corporate data to Slack and now a bunch of crackers around the world have this data.

“Trusting our data with one company isn’t feasible,” one person told me this morning. “The data lasts forever & we must expect that our worst enemies will have it or get it with small time delay. Otherwise encrypt everything which slows everything down & complicates everything making those “safe” uncompetitive.” That’s now how Slack works.

“These troves of Slack data are invaluable to those looking to use them to blackmail people, take over servers, discredit people, and generally cause complete chaos, even deaths.”We expect Slack to stonewall for a while, saying that it’s the weekend anyway. Slack lied to everyone for years. They’re a bunch of frauds. Anyone who now believes a single word that comes out of their mouths is a fool. They also committed a crime (punishable by law) with these lies. When it comes to Slack, expect what happened with Yahoo; First they say it’s a small incident; Months pass; Then they toss out a note to say it was actually big; A year later (when it’s “old news”): 3 BILLION accounts affected. Anyone who now believes the lies told by Slack’s PR people deserves a Darwin Award. These scammers lost millions/billions for years just pursuing an IPO (others bearing the losses); They lied, like frauds (like Donald Trump), just to get there (the IPO). Now, like Yahoo, they will downplay scope of impact. A lot of companies can suffer for years to come (e.g. data breaches, identity theft). These troves of Slack data are invaluable to those looking to use them to blackmail people, take over servers, discredit people, and generally cause complete chaos, even deaths. We’ll soon do a series of articles showing how Microsoft caused deaths at hospitals.

« Previous entries Next Page » Next Page »

RSS 64x64RSS Feed: subscribe to the RSS feed for regular updates

Home iconSite Wiki: You can improve this site by helping the extension of the site's content

Home iconSite Home: Background about the site and some key features in the front page

Chat iconIRC Channels: Come and chat with us in real time

New to This Site? Here Are Some Introductory Resources

No

Mono

ODF

Samba logo






We support

End software patents

GPLv3

GNU project

BLAG

EFF bloggers

Comcast is Blocktastic? SavetheInternet.com



Recent Posts