BootJacker puts malware underneath the running operating system:

1. Force reboot
2. Boot malware
3. Resume OS session preserved in memory

(found here)

.. that Microsoft might have invented cross site scripting? The term, that is, not the technique.

(videolink)

(videolink, via)

After the videos on threat modeling an example seems in order. Securology provides us with a good one in Selecting a Pistol Safe as (part of) the basis of a procurement decision. This is his set of requirements:

So, I needed a way to “securely” (that’s always a nebulous word) store a firearm– namely a pistol– such that it could meet the following criteria:

1. Keep children’s and other family members’ hands off of the firearm
2. Stored in, on, or near a nightstand
3. Easily opened by authorized people under stress
4. Easily opened by authorized people in the dark
5. Not susceptible to power failures
6. Not susceptible to being “dropped open”
7. Not susceptible to being pried open
8. Not opened by “something you have” (authentication with a key) because the spouse is horrible at leaving keys everywhere.
9. For sale at a reasonable cost
10. An adversary should not know (hear) when the safe was opened by an authorized person

But I didn’t care a lot about the ability to keep a dedicated thief from stealing the entire safe with or without the firearm inside.

Read on at Securology to see how various products fail to fulfill this set of requirements. This example is illustrative in that it addresses several distinct threat aspects and tradeoffs. The pistol is not simply an asset needing protection, it is also by itself a security mechanism against certain threats. The resulting optimization problem is pretty interesting: keeping (some) unauthorized people from accessing the pistol while maintaining availability to the authorized in a practical sense.

[See only posts in English]

Kevin M. Williams talking on Death Star Threat Modeling at The Last HOPE , 2008 (via No Tricks)

Part 1:

Part 2:

Part 3:

[See only posts in English]

Microsoft’s BitLocker is, for all we know, a proper disk encryption software. It encrypts data at rest against attacks originating outside the running system. If you use BitLocker and your computer is stolen while turned off, there is essentially no way of reading data from the disk without having the proper key(s)—your BitLocker PIN, a key file on a USB stick, or both. If an attacker gets access to the machine while it is running, there may be ways of compromising it through Windows or in other ways, but such attacks are clearly outside the scope of disk encryption.

We know, however, another class of attacks against disk encryption: evil maid attacks. This term describes a general strategy rather than a particular implementation. If you leave your computer unattended, let’s say in a hotel room, an attacker, let’s say an evil maid, might manipulate it such that your data will be compromised as soon as you return and provide it with your encryption keys. There are various ways of doing so, for instance installing a hardware keylogger if your keys are based on passwords, or altering the unencrypted boot code to install a Trojan horse that will leak your keys later.

BitLocker is different from other software-based disk encryption products, such as TrueCrypt, in that it supports Trusted Computing technology for added security. If used with a Trusted Platform Module (TPM)—a small chip inside your computer—BitLocker needs not only your key(s) but also another key stored inside the TPM to decrypt your data. First and foremost this implies that stealing just your disk is futile if the target is your data, since without the TPM part of the key will be missing.

But this is not all the TPM does. It also watches the boot process to ensure your system hasn’t been tampered with before releasing its part of the encryption key. This won’t solve the hardware keylogger problem, but many people seem to believe that this would be sufficient to prevent software-based variants of evil maid attacks. After all, you can either boot the unaltered system and get your data encrypted or boot a system that has been tampered with, which will fail to obtain the key from the TPM, right?

Well, almost. BitLocker needs to interact with you, the user, to obtain its keys. As the TPM merely records properties of boot components, it will not prevent the software asking for your keys from being altered, or the altered software from being executed. This means that an attacker can alter code on your computer to obtain your PIN or USB key. The TPM only ensures that the cannot boot right into Windows in its altered state. But if the attacker can get away with a single forced reboot—think bluescreen—the malicious code may remove itself before and just leave your keys somewhere on the disk for later retrieval.

The TPM as it is and as it is being used by BitLocker is therefore not sufficient to fend off evil maid attacks, not even the software-based subset. We discussed such and similar attacks in a paper published earlier this year. Now we also demonstrate the BitLocker version of an evil maid attack in a short video starring two of my Fraunhofer colleagues, Jan and Jan. Hence we call this attack the evil Jan attack.

The evil Jan attack does not imply that the BitLocker is broken as a disk encryption scheme. It does not even imply that the TPM would be entirely useless. Our attack has a particular objective, getting unauthorized access to encrypted data in a targeted attack. We show that this remains quite feasible despite the use of the TPM. Attacks with different objectives and side conditions may still get considerably harder due to Trusted Computing. For instance it seems no longer possible for an attacker with physical access to the computer to install malicious software into the running operating system in a single pass.

Security Maxims

[See only posts in English]

Just a quick note: The final papers for the New Security Paradigms Workshop 2009 are now online, including my own (also here). Two of them got their share of public attention already, Maritza Johnson’s Laissez-faire file sharing (in Bruce Schneier’s blog) and Cormac Herley’s So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users (Schneier’s blog; New School of Information Technology;  Heise.de). For those of you who can afford the trip, the authors will present these two papers again in a session at ACSAC, December 7-11.

Cryptographic Voting the MIT style.

Jon Ronson has found a way of writing a commedy about torture and warfare. Best thing about it – many of the ideas behind it like many of the non-lethal weapons are real. Funny, isn’t it? Here some of the ideas.

Subliminal Sound Weapon

LED-Flashlight

Dangerous Microwaves

Grotesque Weaponry

The Hippies behind it

The Ultimate Porn Tracker

(video link)

(video link, lyrics)

Baloney Detection Kit

(Link, via)

(videolink, Misha Glenny, books)

(video link, via 1 Raindrop)

For the collectors and slide producers among you:

SANS Cyber Security Survey 2009
The survey found that Web server-side applications are the target of more than 60% of all Internet attacks and that “Web application vulnerabilities such as SQL injection and cross-site scripting flaws in open source as well as custom-built applications account for more than 80% of the vulnerabilities being discovered. Despite the enormous number of attacks and despite widespread publicity about these vulnerabilities, most Web site owners fail to scan effectively for the common flaw.” http://www.sans.org/top-cyber-security-risks/

(See Making Sense of the SANS “Top Cyber Security Risks” Report at The New School of Information Security for a critique of the report.)

X-Report von IBM 2009
According to the report, criminals are leveraging insecure Web applications to target users of legitimate Web sites. These attacks intended to steal and manipulate data and take command and control of infected computers. The report states that SQL injection attacks rose 50 percent from Q4 2008 to Q1 2009 and then nearly doubled from Q1 to Q2.
http://www-935.ibm.com/services/us/iss/xforce/trendreports/

Sophos Security Threat 2009
23,500 new infected webpages are discovered every day. That’s one every 3.6 seconds, four times worse than in 2007.

http://www.sophos.com/sophos/docs/eng/papers/sophos-security-threat-report-jul-2009-na-wpus.pdf

[See only posts in English]

Cold reading is a technique used by mentalists to simulate psychic powers and impress people. Essentially, the cold reader is supplying words and the other person supplies their meaning as well as hints for the reader.

The CSS history hack, which seems to impress quite a few people, is nothing more than the Web’s version of cold reading. Your impression is that any Web site can read your browser history. Now there is indeed an information leak and no Web site should get access to history information. But this leak is very small. It doesn’t reveal the history altogether to anyone daring to ask. The CSS history issue only gives us an oracle. We can ask the oracle whether a particular URL is in the history or not. So to find out that you’ve read this blog post we would have to ask the oracle about the precise URL of this post.

Nonetheless demonstrations of the history hack impress people. The trick is simple and similar to the cold reading technique. History hack demos use a set of URLs that leads to a hit for almost every Internet user on the world: Google, YouTube, Microsoft, Wikipedia, Flickr, Apple, Slashdot, Amazon, and so on. A mentalist would guess and suggest these until you start giving feedback on which to hook. The CSS history hack replaces this interaction with asking the oracle to avoid wrong guesses. The trick is really to use a set of Web sites that guarantees a hit, and use a minor information leak to remove the wrong guesses from the set that would spoil the effect. This works well with the top 20/top 50/top 1000 sites on the Web, but it won’t scale to arbitrary URLs.

I’m off for the New Security Paradigms Workshop in Oxford, where I will present what I currently call the Swiss Cheese security policy model. My idea is to model security mechanisms as classifiers, and security problems in a separate world model as classification problems. In such a model we can (hopefully) analyze how well a mechanism or a combination of mechanisms solves the actual problem. NSPW is my first test-driving of the general idea. If it survives the workshop I’m going to work out the details. My paper isn’t available yet; final versions of NSPW papers are to be submitted a few weeks after the workshop.

KPMG – eCrime Report 2009 (March)

[See only posts in English]

Software testers increasingly have to deal with production systems. Some tests make sense only with production systems, such as Nessus-style vulnerability scanning. And an increasing number of systems is hard to reproduce in a test bed as the system is really a mashup of services, sharing infrastructure with other systems on various levels of abstraction.

Testing production systems imposes an additional requirement upon the tester, production safety. Testing is production-safe if it does not cause undesired side-effects for the users of the tested or any other system. Potential side effects are manifold: denial of service, information disclosure, real-world effects caused by test inputs, or alteration of production data, to name just a few. Testers of production systems therefore must take precautions to limit the risks of their testing.

Unfortunately it is not yet very clear what this means in practice. Jeremiah Grossman unwittingly started a discussion when he made production-saftey a criterion in his comparison of Website vulnerability assessment vendors. Yesterday he followed up on this matter with a questionnaire, which is supposed to help vendors and their clients to discuss production-safety.

The time is just right to point to our own contribution to this discussion. We felt a lack of documented best practice for production-safe testing, so we documented what we learned over a few years of security testing. The result is a short paper, which my colleague and co-author Jörn is going to present this weekend at the TAIC PART 2009 conference: Testing Production Systems Safely: Common Precautions in Penetration Testing. In this paper we tried to generalize our solutions to the safety problems we encountered.

The issue is also being discussed in the cloud computing community, but their starting point is slightly different. Service providers might want to ban activities such as automated scanning, and deploy technical and legal measures to enforce such a ban. They have good reason to do so, but their users may have equally good reason to do security testing. One proposal being discussed is a ScanAuth API to separate legitimate from rogue scans. Such an API will, however, only solve the formal part of the problem. Legitimate testing still needs to be production-safe.