Tag: computer security

Car Privacy Not Included – Week 3

Although I concede that this isn’t specifically cyber security, privacy is almost synonymous with security in general, and in that spirit, I encountered this review of Car Privacy Policies: It’s Official: Cars Are the Worst Product Category We Have Ever Reviewed for Privacy

In their conclusions, they summarize that consumers really don’t have choices among brands; “they’re all bad.”

Like we mentioned, all of the cars we researched earned our *Privacy Not Included warning label. All of the car brands we researched got our “data use” and “security” dings — and most earned dings for poor data control and bad track records too! We can’t stress enough how bad and not normal this is for an entire product guide to earn warning labels.

The worst problem is that the review could not conclude or even test how data is being secured on just the car, itself, or how companies are managing the data that they do collect. And the privacy policies are implicit since who reads the Privacy Policy of a car that they’re boarding. To add to the problem, Minnesota has enacted legislation in 2022: https://www.revisor.mn.gov/statutes/cite/169.475 that requires motorists to use hands-free connectivity with their vehicle, which compounds this issue because motorists are compelled to connect their smart phones if they intend to use it while the vehicle is in operation on motorways.

Many people have lifestyles that require driving. So unlike a smart faucet or voice assistant, you don’t have the same freedom to opt out of the whole thing and not drive a car.

Well – I am grateful that my car is most assuredly, “dumb.” In most cases, the on-board Bluetooth merely permits interoperability for hands-free operation, like making a phone call or changing audio tracks.

If you want to join Mozilla’s petition to get this fixed, you can do so: https://foundation.mozilla.org/en/privacynotincluded/articles/car-companies-stop-your-huge-data-collection-programs-en/

VPNs Still Don’t Work – Week 2

Original posting by Feisty Duck: Feisty Duck: VPNs Still Don’t Work, which based their Newsletter from TunnelCrack.

The Feisty Duck reiterates TunnelCrack’s conclusions so I’ll try to articulate the two vulnerabilities/attack vectors identified by TunnelCrack. The first attack dubbed “LocalNet Attack” is where the malicious actor clones a WiFi hotspot, which are commonly available in public spaces, like the WiFi at StarBucks. The user, thinking that this is owned and operated by the establishment, foolishly connects to it, where the hacker assigns an IP address from their private pool. The malicious actor can then exploit the vulnerability because VPNs are notorious for permitting LAN address communication. When the user tries to connect with a site, the malicious actor injects or monitors web traffic between its unsuspecting user and a legitimate site.

The second attack, dubbed “ServerIP Attack,” is a little more complex, but the principle is the same; “while establishing the VPN connection, the victim will add a routing rule so that all traffic to the VPN server, in this case the spoofed IP address 1.2.3.4, is sent outside the VPN tunnel.” And because VPNs don’t re-encrypt traffic between the user and its VPN server, the user connects to an unsafe point, which leaks information.

The TunnelCrack team did testing for a broad set of VPN clients and platforms, and they discovered that Apple users are most susceptible, whereas other platforms and VPN clients did better; Android, after version 12, is least affected.

The reason why Feisty Duck posted about these attacks is because they’re a good source for SSL/TLS configuration. Feisty Duck concludes that when a “combination of TLS, valid certificates, and HTTP Strict Transport Security” are implemented, users are far better protected from these exploits. It’s easy to spoof DNS and masquerade as a legitimate server until TLS is properly vetted since most 3rd Parties, like Verisign and GoDaddy, protect their private keys like Crown Jewels.

I did notice that from the TunnelCrack post that VPNs are also susceptible since, like in OpenVPN, the host configuration keyword is often accompanied by a DNS hostname, which can easily be spoofed.

One thing that I didn’t see in these blog posts/newletters was mention of DNSSEC, but I guess, DNS — when it performs a forward lookup — may not be running the gauntlet to validate that the DNS reply is using properly configured DNSSEC; it’s probably less likely.

Continue reading VPNs Still Don’t Work – Week 2

Reverse Shells – Week 1

I was on Reddit.com, and I encountered a question regarding reverse shells. So, I pulled up this resource: https://marketsplash.com/tutorials/bash-shell/reverse-shell-bash/ regarding reverse shells.

The OP (original poster) of the question was asking about reverse shells for the purpose of testing the security awareness of his tool, like Whitehat Sentinel, CrowdStrike FalconHost and Tenable.IO. The security tools are classed as “network vulnerability scanners.” In some cases, the vulnerability scanner will connect with a host, and execute a reverse shell to execute its test(s). This is a valuable and genuine use for reverse shells; however, attackers also use this method to deploy payloads.

I have used PiHole to blackhole selected DNS requests, but I always cringe at their “One-Step Automated Install” method: https://github.com/pi-hole/pi-hole/#one-step-automated-install, where you pipe a downloaded script into BASH. I would advise users who encounter this installation method to download the script, run it through a virus scanner — perhaps it happened automatically during download, then if you’re virus scanner gives its blessing, you can just execute the file like any other BASH shell.