Beginning today, Let’s Encrypt is revoking more than 3 million of its Transport Layer Security (TLS) certificates, following the discovery of a bug that affects the way it rechecks CAA (Certificate Authority Authorization) records.
“Most subscribers issue a certificate immediately after domain control validation, but we consider a validation good for 30 days,” explained Jacob Hoffman-Andrew, Let’s Encrypt engineer, in a Feb. 29 post on the on-profit certificate authority’s website. However, in cases where cert issuance is delayed for more than eight hours, Let’s Encrypt must recheck CAA records, even though the records were originally checked during the domain control validation process. That’s where the vulnerability comes into play.
Hoffman-Andrew described the bug, which was introduced on July 25, 2019, as follows: [W]hen a certificate request contained N domain names that needed CAA rechecking, Boulder would pick one domain name and check it N times. What this means in practice is that if a subscriber validated a domain name at time X, and the CAA records for that domain at time X allowed Let’s Encrypt issuance, that subscriber would be able to issue a certificate containing that domain name until X+30 days, even if someone later installed CAA records on that domain name that prohibit issuance by Let’s Encrypt.”
Altogether, 3,048,289 certificates are infected, or roughly 2.6 percent of the approximately 116 million active certificates issued by Let’s Encrypt, which is operated by the San Francisco, Calif.-based Internet Security Research Group. One million of these are duplicates of certificates that typically are reissued on a frequent basis, Hoffman-Andrew further explained on the Bugzilla website as well as in an FAQ page on the Let’s Encrypt site.
Let’s Encrypt identified its CA software vendor is Boulder. The cert authority said the bug was originally reported by a Let’s Encrypt community member on February 18 and was fixed on Feb. 29. Let’s Encrypt has since created a tool for users to determine if they are affected by the vulnerability. Affected subscribes are encouraged to renew and replace their impacted certificates.
The oft-attacked city of Baltimore not only uses mind-bogglingly bad data storage. Its home state, Maryland, also knows how to swiftly propose mind-bogglingly bad legislation that would outlaw possession of ransomware and put researchers in jeopardy of prosecution.
It is, of course, already a crime to use the data/systems-paralyzing malware in a way that costs victims money, but proposed legislation, Senate Bill 30, would criminalize mere possession.
It’s not supposed to keep researchers from responsibly researching or disclosing vulnerabilities, but like other, similar “let’s make malware more illegal” bills before it, SB 30’s attempts to protect researchers could “use a little more work,” as pointed out by Ars Technica‘s Sean Gallagher.
It covers much of the same ground as does Federal law, but SB 30 would take it a step further by labelling the mere possession of ransomware as a misdemeanor that would carry a penalty of up to 10 years imprisonment and/or a fine of up to $10,000.
The draft could get yet more draconian still: Earlier this month, members of the Maryland Senate Judicial Proceedings Committee said they’d actually prefer to make the crime a felony, according to Capital News Service.
The problematic outlawing of “unauthorized access”
Besides mere possession of ransomware, the bill would outlaw unauthorized, intentional access or attempts to access…
…all or part of a computer network, computer control language, computer, computer software, computer system, computer service, or computer database; or copy, attempt to copy, possess, or attempt to possess the contents of all or part of a computer database accessed.
It would also criminalize acts intended to “cause the malfunction or interrupt the operation of all or any part” of a computer, the network it’s running on, and their software/operating system/data. Also verboten: intentional, willful, unauthorized possession or attempts to identify a valid access code, or publication or distribution of valid access codes to unauthorized people.
Where does that leave researchers? Partially protected by a thin blanket that doesn’t protect them from liability, experts say.
The bill does holler out an exemption for researchers, rendered in full caps in the draft:
THIS PARAGRAPH DOES NOT APPLY TO THE USE OF RANSOMWARE FOR RESEARCH PURPOSES.
But that doesn’t cover any of the extensive list of “thou shalt not touch without authorization” aspects of the bill that could spell trouble for researchers and keep them from reporting vulnerabilities. Well-known vulnerability disclosure policy expert Katie Moussouris – the founder and CEO of Luta Security and creator of Microsoft’s bug-bounty program – told Ars that as it’s now worded, the bill would…
…prohibit vulnerability disclosure unless the specific systems or data accessed by the helpful security researcher were explicitly authorized ahead of time and would prohibit public disclosure if the reports were ignored.
The truth is that organizations ignore responsible vulnerability reports all too often. That’s why responsible disclosure programs have reporting windows: once the clock ticks down, plenty of researchers give up on waiting for a response and go ahead and publish vulnerability details. The rationale: the longer a vulnerability exists, the higher the chance it will be exploited by hackers.
Maryland should follow Georgia’s lead and rethink this
SB 30 is currently still under review. Were it to pass in its current form, there is, of course, a chance that the governor might veto it. That’s what happened to the equally, similarly misguided hacking bill, SB 315, that was passed in Georgia in 2018.
From Governor Brian P. Kemp’s veto message:
Under the proposed legislation, it would be a crime to intentionally access a computer or computer network with knowledge that such access is without authority. However, certain components of the legislation have led to concerns regarding national security implications and other potential ramifications. Consequently, while intending to protect against online breaches and hacks, SB 315 may inadvertently hinder the ability of government and private industries to do so.
Hopefully, Maryland’s lawmakers will take a much closer look at the proposed bill and listen to experts like Moussouris. Hopefully, they’ll come to realize that the legislation may very well harm the very people who are working to protect the state.
Latest Naked Security podcast
Click-and-drag on the soundwaves below to skip to any point in the podcast.
An alarming security vulnerability has been discovered in several models of Android smartphones manufactured by Google, Samsung, and others that could allow malicious apps to secretly take pictures and record videos — even when they don’t have specific device permissions to do so.
You must already know that the security model of the Android mobile operating system is primarily based on device permissions where each app needs to explicitly define which services, device capabilities, or user information it wants to access.
However, researchers at Checkmarx discovered that a vulnerability, tracked as CVE-2019-2234, in pre-installed camera apps on millions of devices could be leveraged by attackers to bypass such restrictions and access device camera and microphone without any permissions to do so.
How Can Attackers Exploit the Camera App Vulnerability?
The attack scenario involves a rogue app that only needs access to device storage (i.e., SD card), which is one of the most common requested permissions and does not raise any suspicion.
According to researchers, by merely manipulating specific “actions and intents,” a malicious app can trick vulnerable camera apps into performing actions on behalf of the attacker, who can then steal photos and videos from the device storage after being taken.
Since smartphone camera apps already have access to required permissions, the flaw could allow attackers to indirectly and surreptitiously take photos, record videos, eavesdrop on conversations, and track location — even if the phone is locked, the screen is off, or the app is closed.
“After a detailed analysis of the Google Camera app, our team found that by manipulating specific actions and intents, an attacker can control the app to take photos and/or record videos through a rogue application that has no permissions to do so,” Checkmarx wrote in a blog post published today.
“Additionally, we found that certain attack scenarios enable malicious actors to circumvent various storage permission policies, giving them access to stored videos and photos, as well as GPS metadata embedded in photos, to locate the user by taking a photo or video and parsing the proper EXIF data. This same technique also applied to Samsung’s Camera app.”
To demonstrate the risk of the vulnerability for Android users, the researchers created a proof-of-concept rogue app masqueraded as an innocent weather app that only asks for the basic storage permission.
The PoC app came in two parts — the client app running on an Android device and an attacker’s controlled command-and-control (C&C) server that the app creates a persistent connection to so that closing the app did not terminate the server connection.
The malicious app designed by the researchers was able to perform a long list of malicious tasks, including:
Making the camera app on the victim’s phone to take photos and record videos and then upload (retrieve) it to the C&C server.
Pulling GPS metadata embedded into photos and videos stored on the phone to locate the user.
Waiting for a voice call and automatically recording audio from both sides of the conversation and video from the victim’s side.
Operating in stealth mode while taking photos and recording videos, so no camera shutter sounds for alerting the user.
The malicious app implemented the wait for a voice call option via the phone’s proximity sensor that can sense when the phone is held to the victim’s ear.
Researchers have also published a video of successfully exploiting the vulnerabilities on Google Pixel 2 XL and Pixel 3 and confirmed that the vulnerabilities were relevant to all Google phone models.
Vulnerability Disclosure and Patch Availability
The Checkmarx research team responsibly reported their findings to Google in early July with the PoC app and a video demonstrating an attack scenario.
Google confirmed and addressed the vulnerability in its Pixel line of devices with a camera update that became available in July, and contacted other Android-based smartphone OEMs in late August to inform them about the issue, which the company rated as “High” in severity.
However, Google did not disclose the names of the affected manufacturers and models.
“We appreciate Checkmarx bringing this to our attention and working with Google and Android partners to coordinate disclosure,” Google said.
“The issue was addressed on impacted Google devices via a Play Store update to the Google Camera Application in July 2019. A patch has also been made available to all partners.”
Also Read: Over 1,300 Android Apps Caught Collecting Data Even If You Deny Permissions
Checkmarx also reported the vulnerability to Samsung that affected its Camera app. Samsung confirmed and fixed the issue in late August, although it wasn’t revealed when the company patched the flaw.
“Since being notified of this issue by Google, we have subsequently released patches to address all Samsung device models that may be affected. We value our partnership with the Android team that allowed us to identify and address this matter directly,” Samsung said.
To protect yourself from attacks surrounding this vulnerability, ensure you are running the latest version of the camera app on your Android smartphone.
Besides this, you are also recommended to run the latest version of the Android operating system and regularly update apps installed on your phone.
Source: National Cyber Security – Produced By Gregory Evans A vulnerability detected in Amazon doorbell cameras made it possible for hackers to gain access to the owner’s household computer network. The weakness in the Ring Video Doorbell Pro IoT device was discovered by researchers at Bitdefender in June of this year. Researchers found that the credentials of […]
View full post on AmIHackerProof.com
The cyber security community is still reeling after the revelation of the KRACK security vulnerability that breaks down Wi-Fi encryption. Now it seems another Wi-Fi-based bug has also been discovered.
Presented at the global Pwn2Own hacking contest in Tokyo, a team of researchers demonstrated how a separate Wi-Fi bug could be exploited to gain entry to iPhones and install malicious apps on them without the owners knowledge.
The details of the threat haven’t been made public yet as Apple hasn’t had time to patch the flaw. It’s discovery was enough to net the Tencent Keen Security Lab the top prize of $110,000.
The hacking contest is set up and run by the Zero Day Initiative, which seeks to find vulnerabilities in popular products and services and alert the manufacturers in time.
According to theofficial event page, the Tencent Keen Security Lab team used “code exectution through a WiFi bug” to escalate “privileges to persist through a reboot.” Effectively breaking through an iPhone’s lock screen through a Wi-Fi network.
The flaw will be relayed to Apple which could offer a software patch to close the gap.
“Once we verify the research presented is a true 0-day exploit, we immediately disclose the vulnerability to the vendor, who then has 90 days to release a fix,” explains the Zero Day Institute.
“Representatives from Apple, Google, and Huawei are all here and able to ask questions of the researchers if needed.
“At the end of the disclosure deadline, if a vendor is unresponsive or unable to provide a reasonable statement as to why the vulnerability is not fixed, the ZDI will publish a limited advisory including mitigation in an effort to enable the defensive community to protect users.”
As ever, from a security standpoint it is always advisable to make sure your phone is running the latest OS version and you closely vet the permissions you give to certain apps.
Source: National Cyber Security – Produced By Gregory Evans Creating malware isn’t rocket science anymore. Unlike those old-school hackers, who had to write their own malicious code and run them to hack someone’s computer, all the new hackers need is an Android device. Yes, you’ve read it right. Now, there’s a new Android app that […]
View full post on AmIHackerProof.com | Can You Be Hacked?
SINCE TWO SECURITY researchers showed they could hijack a moving Jeep on a highway three years ago, both automakers and the cybersecurity industry have accepted that connected cars are as vulnerable to hacking as anything else linked to the internet. But one new car-hacking trick illustrates that while awareness helps,…
A WINDOWS bug could allow hackers to remotely take over your PC or laptop by sending an email which can attack your system even if you don’t open it. The alleged flaw could allow crooks to make changes to your device and steal everything you have saved on there. The terrifying problem lies in a security tool used in all …
Security researchers have discovered a new strain of malware that turns Android devices into backdoors, giving malicious attackers the ability to access any internal network that the infected device is …
I have written about rebound relationships exactly one time on this website. I wrote that post on July 27th of 2013. Now, as you can tell it has been a long time since then and we are getting questions about rebound relationships on an almost daily basis. Except here’s the difference. With the article above I mainly focused on how to know if your ex is in a rebound relationship and how long it will last. Read More….