Ah, phone phreaking. Some of us are just old enough to remember the ubiquity of land lines, but just young enough to have missed out on the golden years of phreaking. There’s something nostalgic about the analog sounds of the telephone, and doubly so when you understand what each click and chunk sound means. If this wistful feeling sounds familiar, then you too will appreciate [Evan Doorbell] and his recordings of 1970s telephone sounds. He’s been slowly working through his old recordings, and compiling them into a series of narrated tours of the phreak subculture.
[Evan]’s introduction to exploring the phone system started from a misdialed number, and an odd message. He describes that recorded “wrong number” message as being very different from the normal Ma Bell messages — this one was almost sultry. What number did he have to dial to hear that unique recording again? What follows is a youth spent in pursuit of playing with the phone system, though it would be more accurate to say the “phone systems”, as discovering the differences between the various local phone exchanges is a big part of the collection. Check out the first tape in the series after the break. Continue reading “Evan Doorbell’s Telephone World”→
Code signing is the silver bullet that will save us from malware, right? Not so much, particularly when vendors can be convinced to sign malicious code. Researchers at G DATA got a hit on a Windows kernel driver, indicating it might be malicious. That seemed strange, since the driver was properly signed by Microsoft. Upon further investigation, it became clear that this really was malware. The file was reported to Microsoft, the signature revoked, and the malware added to the Windows Defender definitions.
The official response from Microsoft is odd. They start off by assuring everyone that their driver signing process wasn’t actually compromised, like you would. The next part is weird. Talking about the people behind the malware: “The actor’s goal is to use the driver to spoof their geo-location to cheat the system and play from anywhere. The malware enables them to gain an advantage in games and possibly exploit other players by compromising their accounts through common tools like keyloggers.” This doesn’t seem to really match the observed behavior of the malware — it seemed to be decoding SSL connections and sending the data to the C&C server. We’ll update you if we hear anything more on this one. Continue reading “This Week In Security: Bad Signs From Microsoft, An Epyc VM Escape”→
There’s been yet another technique discovered to fingerprint users, and this one can even work in the Tor browser. Scheme flooding works by making calls to application URLs, something like steam://browsemedia. If your machine supports the requested custom URL, a pop-up is displayed, asking permission to launch the external application. That pop-up can be detected by JavaScript in the browser. Detect enough apps, and you can build a reasonable fingerprint of the system the test is run on. Unlike some previous fingerprinting techniques, this one isn’t browser dependent — it will theoretically give the same results for any browser. This means even the Tor browser, or any browser being used over the Tor network, can give your potentially unique set of installed programs away.
Now for the good news. The Chrome devs are already working on this issue, and in fact, Chrome on my Linux desktop didn’t respond to the probes in a useful way. Feel free to check out the demo, and see if the results are accurate. And as for Tor, you really should be running that on a dedicated system or in a VM if you really need to stay anonymous. And disable JavaScript if you don’t want the Internet to run code on your computer. Continue reading “This Week In Security: Schemeflood, Modern Wardialing, And More!”→
For some small percentage of the Hackaday crowd, our world got turned upside down at the end of last year, when Red Hat announced changes to CentOS. That distro is the official repackage of Red Hat Enterprise Linux, providing a free, de-branded version of RHEL. The big problem was that CentOS 8 support has been cut way short, ending at the end of 2021 instead of the expected 2029. This caused no shortage of consternation in the community, and a few people and companies stepped forward to provide their own CentOS alternative, with AlmaLinux and Rocky Linux being the two most promising. AlmaLinux minted their first release in March, but the Rocky project made the decision to take things a bit slower. The wait is over, and the Rocky Linux 8.4 release is ready.
Not only are there ISOs for new installs, there is also a script to convert a CentOS 8 install to Rocky. Now before you run out and convert all your CentOS machines, there are a few caveats. First, the upgrade script is still being tested and fixed as problems are found. The big outstanding issue is that Secure Boot isn’t working yet. The process of spinning up a new Secure Boot shim and getting it properly signed is non-trivial, and takes time. The plan is to do an 8.4 re-release when the shim is ready, so keep an eye out for that, if you need Secure Boot support.
The future looks bright for enterprise Linux, with options such as Rocky Linux, AlmaLinux, and even CentOS Stream. It’s worth noting that Rocky has a newly formed company behind it, CIQ, offering support if you want it. The Rocky crew is planning a launch party online on June 25th, so tune in if that’s your thing. Regardless of which Linux OS you run, it’s good to have Rocky in the game.
Raise your hand if you remember when PulseAudio was famous for breaking audio on Linux for everyone. For quite a few years, the standard answer for any audio problem on Linux was to uninstall PulseAudio, and just use ALSA. It’s probably the case that a number of distros switched to Pulse before it was quite ready. My experience was that after a couple years of fixing bugs, the experience got to be quite stable and useful. PulseAudio brought some really nice features to Linux, like moving sound streams between devices and dynamically resampling streams as needed.
First off, Apple has issued an update for some very old devices. Well, vintage 2013, but that’s a long time in cell-phone years. Fixed are a trio of vulnerabilities, two of which are reported to be exploited in the wild. CVE-2021-30761 and CVE-2021-30762 are both flaws in Webkit, allowing for arbitrary code execution upon visiting a malicious website.
The third bug fixed is a very interesting one, CVE-2021-30737, memory corruption in the ASN.1 decoder. ASN.1 is a serialization format, used in a bunch of different crypto and telecom protocols, like the PKCS key exchange protocols. This bug was reported by [xerub], who showed off an attack against locked iPhone immediately after boot. Need to break into an old iPhone? Looks like there’s an exploit for that now. Continue reading “This Week In Security: Updates, Leaks, Hacking Old Hardware, And Making New”→
It’s a way to Man-In-the-Middle an HTTPS connection, without actually needing to break the encryption. There are two primary observations at the core of the attack. First, multiple subdomains will often share the same TLS certificate. Secondly, TLS is regularly used to protect more than just HTTPS. So what happens if an HTTPS request is redirected to an SFTP server run by the same company? The TLS handshake will complete successfully, but the data returned by the server is not at all what the browser expected.
The specific details are a little light on this one, but the authors identified three broad categories of attack. The first is an upload attack, where the attacker has privileges to upload files to an FTPS server. From what I can tell, an attacker initiates an FTP upload over SSL, using the control port, and then redirects the victim’s connection to the data port on that server. The entirety of the HTML request is then saved, decrypted, on the FTPS server. This request could contain session cookies and other secrets.
The second identified attack is the opposite, the attacker uploads a malicious file, initiates a download, and then redirects a browser’s request to the FTPS data port. The malicious file is grabbed and the browser may interpret it as code to be run. The third is a reflection technique. This one’s a bit different. Essentially the attacker sends a request for DoBadThings();, and then connects the victim browser to the data port. The response is sent, Cannot find file: DoBadThings();and the browser might just execute the script fragment. This isn’t one of those attacks that are going to be applicable to just every server, but in just the right setup, it could lead to problems.
VMWare Flaw Exploited
There is a serious VMWare flaw under active exploit right now. It’s apparently in the VMware vCenter control program, and exploiting it is as simple as six curl commands. The flaw is pre-authentication and only requires access to HTTPS port 443. At least one researcher has already seen his VMware honeypot attacked and observed the web-shell the attacker installed. This one looks like a big deal, so make sure you’re up-to-date if you run VMware.
That Time the FBI Ran a Darknet
AN0M was a popular encrypted communication tool for the underworld, really a network consisting of locked down mobile devices with a specialized app running on them. The reality was a bit different, though, the tool was actually being run as Operation Ironside, a join operation by the FBI and the Australian Federal Police (AFP). The story is a weird one, and really raises some legal and ethical questions, so buckle up.
First off, things got started back in 2018 when Phantom Secure CEO Vincent Ramos was prosecuted for RICO charges, related to his company’s work on secure phones. They specialized in taking Blackberry phones, yanking out all the IO hardware, like camera, microphone, and even GPS chips, and then installing encrypted communication apps. In short, very similar to AN0M. Phantom Secure was walking a very thin line between being a legitimate provider of secure hardware, and actively supporting criminal enterprise. When Ramos told an undercover FBI agent that his phones were specifically for drug smuggling, it became obvious that he had strayed far onto the wrong side of the law. He and many in the company were charged for related crimes.
One employee already had drug charges on his record, and agreed to cooperate with the FBI in exchange for avoiding further charges. That developer had already been developing his own device, which he called AN0M. The deal he cut with the feds was to turn over his work for immunity. A scheme was hatched, apparently over beers between agents, to complete the development of AN0M and distribute the devices, but to include a complete back door for law enforcement. This is actually very similar to what was done with Crypto AG, under Project Rubicon.
The turned developer distributed the devices to his contacts, and law enforcement agencies around the world got involved, quietly helping to make them popular. The devices served their purpose of providing messaging to all recipients. It just wasn’t known at the time that law enforcement agents were BCC’d on every message. It’s not clear what triggered the raids and announcements, but this was definitely a coordinated action.
There is a lingering question, however. Namely, do law enforcement really have the legal authority to develop and distribute a malicious device and application? Did a warrant actually cover this? Can it? There is sure to be much consternation over such questions in the months to come. Just imagine that WhatsApp is eventually revealed to be an app secretly developed by the Chinese government, then how would you feel about it?
Ransomware and Bitcoin Seizure
And in another major victory for the FBI, The majority of the funds paid by the Colonial pipeline have been recovered. It’s not entirely known how the recovery happened, but you can read the FBI Affidavit that describes the path the Bitcoins took. There’s a strange little statment at the end of that document. “The private key for the Subject Address is in the possession of the FBI in the Northern District of California.” One has to wonder a couple of things. First, how was the FBI able to track those bitcoins? And second, just how did they happen to end up in a wallet that they knew the key for? Could The AN0M story be related?
The private key for the Subject Address is in the possession of the FBI in the Northern District of California
Now here’s another angle to this. Colonial was given the choice, to pay in Bitcoin or Ethereum, and they chose Bitcoin, even though there was a 10% extra fee for that currency. They had their networks mostly back up, and they knew the decryptor wouldn’t be very helpful. They were working with law enforcement, and they still paid. This raises the very real possibility that the payment was made specifically to trace the Bitcoin transactions.
Next, remember how proud JBS was of their incident response? Now we find out that they did indeed pay an $11 million ransom. However, that was in cooperation with federal officials, and was not necessary to recover files. Oh, and paid in Bitcoin. Sound familiar? At this point, it’s a fair guess that the FBI or another agency helping them has an angle on tracing Bitcoin transactions. AN0M is one possibility. Another is that the FBI is running a “mixer”, essentially a Bitcoin money laundering service. (Shoutout to @MalwareJake for that idea.) Regardless, there seems to be a more serious stance taken towards ransomware as a result of the high profile hacks of the last few weeks.
Rocket.Chat Goes Boom
Running a Rocket.Chat instance? Go update it! This popular Open Source messaging platform uses a NoSQL backend for managing users. If you thought getting rid of SQL means you don’t have injection vulnerabilities, think again.
The MongoDB database backend passes requests and data in a JSON-like format. The first attack is to stuff a regex pattern into that JSON, and leak the password hash one character at a time. The second vulnerability uses the $where operator in MongoDB in a clever way. Rather than try to leak information directly, they used error messages to get information out. Put both together, and you can go from simply knowing a user’s email address to a shell on the hosting server in seconds. All in all, it’s an impressive hack, and the video demonstration of it is worth the watch:
Agent Smith Takes Over The Matrix
Include Security found an interesting bug in the Unity engine, where a malicious game object can run arbitrary code on the machine running the engine. It’s the sort of thing that game designers don’t think too much about until it’s a problem. I couldn’t help but think of VR Chat, a multiplayer experience that allows players to upload their own avatars. It’s built in Unity, and uses game objects for those avatars. I haven’t been able to confirm whether it has this vulnerability one way or another, but I’m very much reminded of Agent Smith copying himself onto all the other citizens of the matrix. If VR Chat does indeed have this problem, it would be rather trivial to build an avatar worm to do the same thing. Life imitates art.
Don’t Use a Password Manager?
And finally, one of the hallowed bits of cybersecurity wisdom gets challenged by [Tavis Ormandy] of Google project Zero fame. His take? Don’t use a password manager! Well, actually, it’s that you shouldn’t use a password manager that is a browser extension, because websites can actually interact with the hooks that make them work. There’s more to his argument, and his conclusion is simple. Use the password manager built into Google Chrome. Or Firefox, if that’s what you use. His argument is rather compelling, that many of them aren’t as secure as they claim to be.
