Key Flaw With GPL | TechSNAP 234

chris

7 years ago

D-Link publishes its private code signing keys, exploiting Windows Symbolic Links & why encryption is not sufficient protection.

Plus some great questions, our answers, a rockin roundup & much, much more!

Thanks to:

Get Paid to Write for DigitalOcean

Direct Download:

RSS Feeds:

Become a supporter on Patreon:

— Show Notes: —

D-Link accidentally publishes its private code signing keys

As part of its GPL license complain, D-Link makes its firmware source code available for many of its devices
“He had purchased the DCS-5020L-surveillance camera from D-Link and wanted to download the firmware. D-Link firmware source code of many open source under a GPL license available.”
“When looking through the files I accidentally stumbled upon 4 different private keys used for code signing. Only one — the one belonging to D-Link itself — was still valid at the time. I have successfully used this key to sign an executable as D-Link”
“In fact, in some batch files were the commands and pass phrases that were needed.”
The certificates have already been revoked
Fox-IT confirms: “The code signing certificate is indeed in the firmware packages, firmware version 1.00b03 released February 27 of this year, was released this certificate was therefore issued for expired, a big mistake.”
We’ll have to cover this in more detail once more information is available, in English

“Investigating the Computer Security Practices and Needs of Journalists”

A survey found that 50% of journalists do not use any security tools
Those that do, may not realize that the tools they are using are ineffective, or that the way they are using them hurts their security
“Observation: The computer security community builds a lot of tools that might be useful for journalists, but we don’t deeply understand the journalistic process!”
“I report on unauthorized immigrants a great deal and have concerns about how to communicate with them without putting them at risk. That said, asking them to use encrypted methods of communication I think would create a greater sense of threat about talking to me and make it more difficult to report. Many are also not extremely computer-savvy. This is something I struggle with a great deal”
“Objective: Conduct in-depth interviews with full-time journalists at recognized media organizations operating across a range of media, including print, digital, broadcast and wire services”
Figure out the typical workflow for a journalist, model security tools that work with them, instead of forcing them to a workflow dictated by the tools
Findings:
- “Audio recording and digital note-taking were primary forms of interview documentation.”
- “Many participants use third-party cloud services, but few voiced concern about possible security risks”
- Long-term sources are common
Sources like Snowden, a big one-time data dump, are rare
Security Concerns:
Negative effects on source
Loss of credibility if source information was exposed
Government identification of sources
Disciplinary actions (e.g., losing job)
Loss of competitive advantage
Potential financial consequences
The project found that in most cases of a journalist using security tools, it was because the source requested it, or because the journalist had had specific security training
“A lot of services out there say they’re secure, but having to know which ones are actually audited and approved by security professionals — it takes a lot of work to find that out.”
“There were different kinds of litigation software that I was familiar with as a lawyer, where, let’s say, you have a massive case, where you have a document dump that has 15,000 documents. […] There are programs that help you consolidate and put them into a secure database. So it’s searchable [and provides a secure place where you can see everything related to a story at once]. I don’t know of anything like that for journalism.”
It will be interesting to see what comes out of this research

Exploiting Windows Symbolic Links

“For the past couple of years I’ve been researching Windows elevation of privilege attacks. This might be escaping sandboxing or gaining system privileges. One of the techniques I’ve used multiple times is abusing the symbolic link facilities of the Windows operating system to redirect privileged code to create files or registry keys to escape the restrictive execution context.”
“Symbolic links in themselves are not vulnerabilities, instead they’re useful primitives for exploiting different classes of vulnerabilities such as resource planting or time-of-check time-of-use.”
A time-of-check time-of-use vulnerability works like this:
- You setup a symlink to a file you are allowed to access
- You try to access a resource
- The software checks that you are allowed to access the resource, you are
- You quickly re-target the symlink to something else
- You try to access the resource, and the software allows you, since it has already checked that you are allowed
- You now have access to a resource you should not
“This blog post contains details of a few changes Microsoft has made to Windows 10, and now back ported (in MS15-090) as far back as Windows Vista which changes who can use certain types of symbolic links. There’s not been many mitigations of this type which get back ported to so many older versions of Windows. Therefore I feel this is a good example of a vendor developing mitigations in response to increased attacks using certain techniques which wouldn’t have traditionally been considered before for mitigations.”
Almost everything in the Windows file system is a symbolic link. Even C: is actually a symbolic link to \Device\HarddiskVolume4 (since NT 3.1)
Microsoft has released three new mitigations:
“Registry Key Symbolic Link Mitigation (CVE-2015-2429) — The simplest mitigation implementation is for registry keys. Effectively a sandboxed process is not allowed to ever create a registry key symbolic link. This is implemented by calling RtlIsSandboxToken function when creating a new key (you need to specific a special flag when creating a key symbolic link). It’s also called when setting the SymbolicLinkValue value which contains the link target. This second check is necessary to prevent modifying existing symbolic links, although it would be unlikely to be something found on a real system.”
“Object Manager Symbolic Link Mitigation (CVE-2015-2428) — If an application tries to create an object manager symbolic link from a sandbox process it will still seem to work, however if you look at where the check is called you’ll find it doing something interesting. When the symbolic link is created the RtlIsSandboxToken function is called but the kernel doesn’t immediately return an error. Instead it uses it to set a flag inside the symbolic link kernel object which indicates to the object manager a sandboxed process has created this link. This flag is then used in the ObpParseSymbolicLink function which is called when the object manager is resolving the target of a symbolic link. The RtlIsSandboxToken is called again, if the current caller is not in a sandbox but the creator was in a sandbox then the kernel will return an error and not resolve the symbolic link, effective making the link useless for a sandboxed to unsandboxed elevation.”
“NTFS Mount Point Mitigation (CVE-2015-2430) — The final mitigation is for NTFS mount points. In early technical previews of Windows 10 (I first spotted the change in 10130) the check was in the NTFS driver itself and explicitly blocked the creation of mount points from a sandboxed process. Again for presumably application compatibility reasons this restriction has been relaxed in the final release and the back ported mitigations. Instead of completely blocking creation the kernel function IopXxxControlFile has been modified so whenever it sees the FSCTL_SET_REPARSE_POINT file system control code being passed to a driver with a mount point reparse tag it tries to verify if the sandboxed caller has write access to the target directory. If access is not granted, or the directory doesn’t exist then setting the mount point fails. This ensures that in the the majority of situations the sandboxed application couldn’t elevate privileges, as it could already write to the directory already. There’s obviously a theoretical issue in that the target could later be deleted and replaced by something important for a higher privileged process but that’s not very likely to occur in a practical, reliable exploit.”
“These targeted mitigations gives a clear indication that bug hunting and disclosing the details of how to exploit certain types of vulnerabilities can lead into mitigation development, even if they’re not traditional memory corruption bugs. While I didn’t have a hand in the actual development of the mitigation It’s likely my research was partially responsible for Microsoft acting to develop them. It’s very interesting that 3 different approaches ended up being taken, reflecting the potential application compatibility issues which might arise.”
“Excluding any bypasses which might come to light these should make entire classes of resource planting bugs unexploitable from a compromised sandboxed process and would make things like time-of-check time-of-use harder to exploit. Also it shows the level of effort that implementing mitigations without breaking backwards compatibility requires. The fact that these only target sandboxes and not system level escalation is particularly telling in this regard.”

Encryption as Protection? Maybe Not

We often see as part of the coverage of a data breach how the data was not “encrypted”
As it turns out, having data encrypted on the disk, doesn’t necessarily help, if the data is still “live” on the system
If your laptop hard drive is encrypted, but you leave it unlocked at the coffee shop and visit the restroom, anyone can access the files on your computer. Having them encrypted did nothing for you
The way hard drive encryption works, it only protects you if you lock or shutdown the computer, and require a strong passphrase to decrypt the disk to mount it again
The same applies to a file server or database at a company. Encryption is only useful if access to the data is still strictly controlled
“A recent espionage prosecution in West Palm Beach, Florida demonstrates that encryption may not be the panacea that organizations think it is. So rather than relying on encryption alone, companies need to adopt and maintain strategies that continue to provide layered security.”
“After every data breach, we hear the same mantra, “If only the data were encrypted!” As if encryption of data is the answer to data breaches.”
The case centers in this article centers on Christopher Glenn, a 35-year-old former defense contractor living in his mother’s retirement community
He worked for the US Government in Honduras
“He was convicted of stealing and retaining classified documents he obtained which related to U.S. policy in the Middle East”
“In preparation for his theft, Glenn, a “computer specialist” with a U.S. defense contractor, read up on data security in general and encryption in particular. He apparently read articles about TrueCrypt, a popular freeware encryption product used for On-The-Fly Encryption (OTFE), noting in particular an October 2011 article entitled, “FBI Hackers Fail to Crack TrueCrypt”. Glenn figured that he could create an encrypted partition (called 2012 Middle East) on his drive. He created a 30-character passphrase, thinking that the data would be secured. Indeed, he estimated that it would take the FBI “billions of years” to crack the crypto through brute force.”
“He was wrong. And he was sentenced to 10 years in jail.”
“According to case reports, the FBI’s counter-intelligence agents were able to decrypt the encrypted files on Glenn’s computer, which became evidence in his case. Given that this is 2015, they did so in substantially less than the “billions of years” that Glenn anticipated.”
There is no information on how exactly the FBI decrypted the data, but it was likely an attack against the passphrase, or the machine Glenn had used to encrypt the data
“Companies need to evaluate not only WHETHER they encrypt data, but when and how they encrypt data. For example, RAM scrapers capture credit card numbers and other personal information, which is encrypted, before the data is encrypted.”
“All of this must be part of a comprehensive data security program which includes access control, data management, ingress and egress reporting, data loss prevention processes, intrusion detection and prevention, managed and monitored firewalls and other services, threat intelligence, and comprehensive incident response. There are no shortcuts here. Oh yes, and encryption, the right encryption.”
Encryption of “data at rest” in servers