Reverse-Engineering NSA Malware
Interesting articles reverse-engineering DEITYBOUNCE and BULLDOZER.
Entries Tagged "security engineering"
Page 12 of 15
Security as Interface Guarantees
This is a smart and interesting blog post:
I prefer to think of security as a class of interface guarantee. In particular, security guarantees are a kind of correctness guarantee. At every interface of every kind user interface, programming language syntax and semantics, in-process APIs, kernel APIs, RPC and network protocols, ceremonies —explicit and implicit design guarantees (promises, contracts) are in place, and determine the degree of “security” (however defined) the system can possibly achieve.
Design guarantees might or might not actually hold in the implementation —software tends to have bugs, after all. Callers and callees can sometimes (but not always) defend themselves against untrustworthy callees and callers (respectively) in various ways that depend on the circumstances and on the nature of caller and callee. In this sense an interface is an attack surface— but properly constructed, it can also be a defense surface.
[…]
But also it’s an attempt to re-frame security engineering in a way that allows us to imagine more and better solutions to security problems. For example, when you frame your interface as an attack surface, you find yourself ever-so-slightly in a panic mode, and focus on how to make the surface as small as possible. Inevitably, this tends to lead to cat-and-mouseism and poor usability, seeming to reinforce the false dichotomy. If the panic is acute, it can even lead to nonsensical and undefendable interfaces, and a proliferation of false boundaries (as we saw with Windows UAC).
If instead we frame an interface as a defense surface, we are in a mindset that allows us to treat the interface as a shield: built for defense, testable, tested, covering the body; but also light-weight enough to carry and use effectively. It might seem like a semantic game; but in my experience, thinking of a boundary as a place to build a point of strength rather than thinking of it as something that must inevitably fall to attack leads to solutions that in fact withstand attack better while also functioning better for friendly callers.
I also liked the link at the end.
The Security of Various Programming Languages
Interesting research on the security of code written in different programming languages. We don’t know whether the security is a result of inherent properties of the language, or the relative skill of the typical programmers of that language.
The report.
EDITED TO ADD (5/14): Direct link to The report.
How NIST Develops Cryptographic Standards
This document gives a good overview of how NIST develops cryptographic standards and guidelines. It’s still in draft, and comments are appreciated.
Given that NIST has been tainted by the NSA’s actions to subvert cryptographic standards and protocols, more transparency in this process is appreciated. I think NIST is doing a fine job and that it’s not shilling for the NSA, but it needs to do more to convince the world of that.
RCS Spyware and Citizen Lab
Remote-Controlled System (RCS) is a piece of spyware sold exclusively to governments by a Milan company called Hacking Team. Recently, Citizen Lab found this spyware being used by the Ethiopian government against journalists, including American journalists.
More recently, Citizen Lab mapped the software and who’s using it:
Hacking Team advertises that their RCS spyware is “untraceable” to a specific government operator. However, we claim to identify a number of current or former government users of the spyware by pinpointing endpoints, and studying instances of RCS that we have observed. We suspect that agencies of these twenty-one governments are current or former users of RCS: Azerbaijan, Colombia, Egypt, Ethiopia, Hungary, Italy, Kazakhstan, Korea, Malaysia, Mexico, Morocco, Nigeria, Oman, Panama, Poland, Saudi Arabia, Sudan, Thailand, Turkey, UAE, and Uzbekistan.
Both articles on the Citizen Lab website are worth reading; the details are fascinating. And more are coming.
Finally, congratulations to Citizen Lab for receiving a 2014
The Insecurity of Secret IT Systems
We now know a lot about the security of the Rapiscan 522 B x-ray system used to scan carry-on baggage in airports worldwide. Billy Rios, director of threat intelligence at Qualys, got himself one and analyzed it. And he presented his results at the Kaspersky Security Analyst Summit this week.
It’s worse than you might have expected:
It runs on the outdated Windows 98 operating system, stores user credentials in plain text, and includes a feature called Threat Image Projection used to train screeners by injecting .bmp images of contraband, such as a gun or knife, into a passenger carry-on in order to test the screener’s reaction during training sessions. The weak logins could allow a bad guy to project phony images on the X-ray display.
While this is all surprising, it shouldn’t be. These are the same sort of problems we saw in proprietary electronic voting machines, or computerized medical equipment, or computers in automobiles. Basically, whenever an IT system is designed and used in secret – either actual secret or simply away from public scrutiny – the results are pretty awful.
I used to decry secret security systems as “security by obscurity.” I now say it more strongly: “obscurity means insecurity.”
Security is a process. For software, that process is iterative. It involves defenders trying to build a secure system, attackers—criminals, hackers, and researchers—defeating the security, and defenders improving their system. This is how all mass-market software improves its security. It’s the best system we have. And for systems that are kept out of the hands of the public, that process stalls. The result looks like the Rapiscan 522 B x-ray system.
Smart security engineers open their systems to public scrutiny, because that’s how they improve. The truly awful engineers will not only hide their bad designs behind secrecy, but try to belittle any negative security results. Get ready for Rapiscan to claim that the researchers had old software, and the new software has fixed all these problems. Or that they’re only theoretical. Or that the researchers themselves are the problem. We’ve seen it all before.
DRM and the Law
Cory Doctorow gives a good history of the intersection of Digital Rights Management (DRM) software and the law, describes how DRM software is antithetical to end-user security, and speculates how we might convince the law to recognize that.
Every security system relies on reports of newly discovered vulnerabilities as a means of continuously improving. The forces that work against security systems—scripts that automate attacks, theoretical advances, easy-to-follow guides that can be readily googled—are always improving so any system that does not benefit from its own continuous improvement becomes less effective over time. That is, the pool of adversaries capable of defeating the system goes up over time, and the energy they must expend to do so goes down over time, unless vulnerabilities are continuously reported and repaired.
Here is where DRM and your security work at cross-purposes. The DMCA’s injunction against publishing weaknesses in DRM means that its vulnerabilities remain unpatched for longer than in comparable systems that are not covered by the DMCA. That means that any system with DRM will on average be more dangerous for its users than one without DRM.
STUCCOMONTANA: NSA Exploit of the Day
Today’s implant from the NSA’s Tailored Access Operations (TAO) group implant catalog:
STUCCOMONTANA
(TS//SI//REL) STUCCOMONTANA provides persistence for DNT implants. The DNT implant will survive an upgrade or replacement of the operating system—including physically replacing the router’s compact flash card.
(TS//SI//REL) Currently, the intended DNT Implant to persist is VALIDATOR, which must be run as a user process on the target operating system. The vector of attack is the modification of the target’s BIOS. The modification will add the necessary software to the BIOS and modify its software to execute the SIERRAMONTANA implant at the end of its native System Management Mode (SMM) handler.
(TS//SI//REL) STUCCOMONTANA must support all modern versions of JUNOS, which is a version of FreeBSD customized by Juniper. Upon system boot, the JUNOS operating system is modified in memory to run the implant, and provide persistent kernel modifications to support implant execution.
(TS//SI//REL) STUCCOMONTANA is the cover term for the persistence technique to deploy a DNT implant to Juniper T-Series routers.
Unit Cost: $
Status: (U//FOUO) STUCCOMONTANA under development and is expected to be released by 30 November 2008.
Page, with graphics, is here. General information about TAO and the catalog is here.
In the comments, feel free to discuss how the exploit works, how we might detect it, how it has probably been improved since the catalog entry in 2008, and so on.
SIERRAMONTANA: NSA Exploit of the Day
Today’s implant from the NSA’s Tailored Access Operations (TAO) group implant catalog:
SIERRAMONTANA
(TS//SI//REL) SIERRAMONTANA provides persistence for DNT implants. The DNT implant will survive an upgrade or replacement of the operating system—including physically replacing the router’s compact flash card.
(TS//SI//REL) Currently, the intended DNT Implant to persist is VALIDATOR, which must be run as a user process on the target operating system. The vector of attack is the modification of the target’s BIOS. The modification will add the necessary software to the BIOS and modify its software to execute the SIERRAMONTANA implant at the end of its native System Management Mode (SMM) handler.
(TS//SI//REL) SIERRAMONTANA must support all modern versions of JUNOS, which is a version of FreeBSD customized by Juniper. Upon system boot, the JUNOS operating system is modified in memory to run the implant, and provide persistent kernel modifications to support implant execution.
(TS//SI//REL) SIERRAMONTANA is the cover term for the persistence technique to deploy a DNT implant to Juniper M-Series routers.
Unit Cost: $
Status: (U//FOUO) SIERRAMONTANA under development and is expected to be released by 30 November 2008.
Page, with graphics, is here. General information about TAO and the catalog is here.
We have already seen the codename VALIDATOR. It’s the code name for a default, or basic, NSA exploit. It’s the exploit that FOXACID defaults to using.
In the comments, feel free to discuss how the exploit works, how we might detect it, how it has probably been improved since the catalog entry in 2008, and so on.
SCHOOLMONTANA: NSA Exploit of the Day
Today’s implant from the NSA’s Tailored Access Operations (TAO) group implant catalog:
SCHOOLMONTANA
(TS//SI//REL) SCHOOLMONTANA provides persistence for DNT implants. The DNT implant will survive an upgrade or replacement of the operating system—including physically replacing the router’s compact flash card.
(TS//SI//REL) Currently, the intended DNT Implant to persist is VALIDATOR, which must be run as a user process on the target operating system. The vector of attack is the modification of the target’s BIOS. The modification will add the necessary software to the BIOS and modify its software to execute the SCHOOLMONTANA implant at the end of its native System Management Mode (SMM) handler.
(TS//SI//REL) SCHOOLMONTANA must support all modern versions of JUNOS, which is a version of FreeBSD customized by Juniper. Upon system boot, the JUNOS operating system is modified in memory to run the implant, and provide persistent kernel modifications to support implant execution.
(TS//SI//REL) SCHOOLMONTANA is the cover term for the persistence technique to deploy a DNT implant to Juniper J-Series routers.
Status: (U//FOUO) SCHOOLMONTANA completed and released by ANT May 30, 2008. It is ready for deployment.
Page, with graphics, is here. General information about TAO and the catalog is here.
In the comments, feel free to discuss how the exploit works, how we might detect it, how it has probably been improved since the catalog entry in 2008, and so on.
Sidebar photo of Bruce Schneier by Joe MacInnis.