/This Week In Security: Is RSA Finally Broken? The Push For Cloud Accounts, Encrypted DNS, And More Mobile Mayhem (via Qpute.com)
This Week In Security: Is RSA Finally Broken? The Push For Cloud Accounts, Encrypted DNS, And More Mobile Mayhem

This Week In Security: Is RSA Finally Broken? The Push For Cloud Accounts, Encrypted DNS, And More Mobile Mayhem (via Qpute.com)

Ever wondered what “cyberwar” looks like? Apparently it’s a lot of guessing security questions and changing passwords. It’s an interesting read on its own, but there are some interesting clues if you read between the lines. A General in the know mentioned that Isis:

clicked on something or they did something that then allowed us to gain control and then start to move.

This sounds very similar to stories we’ve covered in the past, where 0-days are used to compromise groups or individuals. Perhaps the NSA supplied such an exploit, and it was sent in a phishing attack. Through various means, the U.S. team quietly compromised systems and collected credentials.

The article mentions something else interesting. Apparently the targets of this digital sting had also been compromising machines around the world, and using those machines to manage their efforts. The decision was made by the U.S. team to also compromise those machines, in order to lock out the Isis team. This might be the most controversial element of the story. Security researchers have wanted permission to do this for years. How should the third parties view these incursions?

The third element that I found particularly interesting was the phase 2 attack. Rather than outright delete, ban, and break Isis devices and accounts, the U.S. team installed persistent malware that emulated innocuous glitches. The internet connection is extremely laggy on certain days, certain websites simply don’t connect, and other problems. These are the sort of gremlins that networking pros spend all day trying to troubleshoot. The idea that it’s intentional gives me one more thing to worry about.

Quantum Supremacy and the Death of RSA

Quantum Supremacy made the news, as Google announced they achieved the milestone in one of their research projects. Quantum supremacy is the term for the tipping point when quantum computers finally outperform classical computers. Google’s quantum computer performed a calculation in minutes, and they suggest that a mundane supercomputer would take thousands of years to perform the same process.

So that’s it, right? All our computers can be retired, RSA is dead, and prepare for the singularity. Not so fast. The problem solved was the “random circuit sampling problem.” Not familiar with that particular challenge? It could be thought of as a self-test for a quantum computer. In the theoretical realm, it’s still important, but doesn’t mean anything in the real world. While a few have claimed this to be the end of encryption, there are still years of work until quantum computing has a real world effect.

Encryption was again prematurely declared deceased by Crown Stirling, the creator of a brand new encryption technique, “Time AI.” The whole thing is predictably bogus. These are the guys that rented a sponsored time slot at Black Hat, got booed during their presentation, and proceeded to launch a lawsuit against the hecklers. Let’s just say that they aren’t the most well respected security company.

Local Accounts vs the Cloud

I’m not sure if you’ve installed Windows recently, but Microsoft has made local accounts even harder to create on Windows 10 installs. The stated reason for the Microsoft Account is security and convenience. It may be more convenient, but moving your account information into the cloud is certainly not more secure.

For your periodic reminder that the cloud is a hip way to describe somebody else’s computer: A Yahoo engineer has pleaded guilty to abusing his administrative privileges to access customer accounts, with the intent of gaining access to users’ compromising images. It’s a scary reminder that there are potentially malicious people working at the big companies we trust with our data.

Encrypted DNS

Google and Firefox have both begun rolling out encrypted DNS over HTTPS. This seems like an obvious security win for everyone, so why are several groups complaining and trying to block Google’s actions? The given reason is that Google is making a move to be the single centralized DNS provider. While Google’s DNS is indeed one of the most popular, the DNS over HTTPS support won’t materially increase Google’s DNS traffic.

So why the push back? The most plausible theory is that encrypting DNS will make data mining harder for ISPs, who currently use DNS lookups to monitor customers. Some of this monitoring is for positive reasons, like detecting malware infections. It’s possible that it’s also used for things like tailored advertisements.

On a technical note, even with DNS over HTTPS, domain names are still sent in the clear as part of the HTTPS handshake, in a TLS extension known as Server Name Indication, or SNI. This serves as a hint to enable a web server to serve the correct HTTPS certificate in the case of multiple web sites hosted from the same machine. Encrypted SNI is an experimental solution to this problem that is also being slowly deployed.

iOS Checkm8

[axi0mX] dropped the Checkm8 iOS vulnerability on Twitter just a few days ago. This vulnerability exists in the iOS bootloader, iBoot, all the way up to iPhone X devices. The release mentions that it’s a use after free bug in the bootloader’s USB stack, and depends on a race condition to trigger.

The sheer number of devices impacted by this vulnerability has alarmed some, but this is a tethered only attack, and on its own doesn’t break the secure enclave. What Checkm8 is useful for is jailbreaking iDevices. Apple designed their devices with hard-coded boot loaders as part of their security stack. There is absolutely no way to fix this vulnerability, so many many devices are now permanently accessible for jailbreaking. This has been called a renaissance in the iOS jailbreaking scene, and we’re sure to see many interesting ramifications from this vulnerability.

Android VoIP

On the other side of the mobile landscape, a set of Android vulnerabilities were just made public, all in the VoIP stack. The most serious, CVE-2018-9475, was patched in 2018. It was a simple buffer overflow: when the calling user name or number was longer than 513 bytes, a return address could be overwritten, allowing an attacker to jump execution into their own code.

Another interesting problem was that of a very long sip name. This is the name that would be displayed on screen for an incoming call. At the time, Android didn’t sanity check that name for length, so a long enough value would simply cover the interface and prevent answering or rejecting the incoming call.

The bugs were reported and fixed, so as long as your phone is running a reasonably recent Android version, all should be well. For those running devices that no longer receive security updates? Maybe it’s time to look at LineageOS, or one of the other 3rd party ROMs.

This is a syndicated post. Read the original post at Source link .