Notes from DeepSec 2011 day 1

(The DeepSec 2011 notes were apparently never finished, and I have just found this draft. Perhaps this might still be useful.)

Here are some notes from the first day of DeepSec 2011.

How Terrorists Encrypt

Historically, terrorism was used as a justification for restricting cryptography. This includes the original proposal for Clipper, and supposedly Al-Qaeda using steganography in "X-rated pictures" (tracked down to an unknown security company demonstrating steganography in Mona Lisa).

Actually, the 9/11 hijackers did not use encryption at all - just simple e-mails back and forth, with simple code word substitution.

Similarly, various Al-Qaeda manuals, if they deal with encryption at all, only describe simple monoalphabetic substitutions and using code names. A single operation used PGP competently, but only for local storage, not communication with other groups.

In practice, use of code names and "web mail dead drops" (sharing a webmail account name+password, and storing messages in the draft folder, to defeat traffic analysis) is frequent. A single "Islamic program for secure network communication" appeared on forums, with unknown provenance (an espionage "plant" suspected) - probably only a GUI for gpg.

The presentation continued with a large list of (UK-focused) counter-terrorism operations, with vast majority using no cryptography at all. If encryption for communication is used, it is trivial substitution. One case of using PGP, one case of using TrueCrypt - both within a small group of competent people, not used for communication.

There were some interesting notes about police handling of crypto - in one case a computer (and the forensic image?) was destroyed as a "biohazard"; in another case the UK government was able to find a PGP passphrase through an unknown method (the passphrase was not exactly, but "structurally similar to" "Bowl of SSSmile").

In summary:

• Encryption is not used by terrorists for communication


• They are concerned about traffic analysis


• Some use encryption of personal data storage


• Lessons from "Why Johnny doesn't encrypt" still apply: people are lazy, do it incorrectly, don't know how to tell good crypto from bad.

Reassemble or GTFO! - IDS Evasion Strategies

A general summary of issues with IDS systems.

Inherent issues:

• Ambiguous RFCs


• Inconsistencies on implementation reactions to input - an IDS needs to be like all implementations at the same time


• Lack of resources/processing capacity


• Lack of data to analyze


• Complex protocols that cannot be understood form a single packet, e.g. MS RPC on port 135

Vendor behavior:

• Vendors talk about throughput, not about detection: A typical IDS has a 5-10% detection rate when shipped. It can be tuned to 98% detection rate, but then it becomes really slow.


• Most vendors import snort rules (they are available for free, so why write our own?)


• Most vendors only inspect first ~300 bytes, to increase throughput


• IDSes tend to fail open - perhaps set up as passive listeners, and don't want to bring the network down

Evasion methods:

• Snort has a rule for detecting shellcode: "AAAAAAAAAA" and "CCCCCCC" (each with a different, carefully tuned length to balance detection with false positives)
  
  
  
  • Just use a different fill character to avoid detection
  
  
  • Append AAAAAAAAAAAA to the end of any request, the rule will be quickly turned off due to too many alarms
  
  
  • Or put AAAAAAA into an email signature...
  
  "This is the level of sophistication we are dealing with."
  
  
  


• For HTTP, use gzip compression and chunked transfer-encoding; the resulting packets don't have enough context to be decoded.


• Cause the IDS and the final endpoint to receive different data:
  
  
  
  • Use an invalid IP checksum - IDS won't check it, and will accept the packet (but it's difficult to get such a packet past any internet router).
  
  
  • If the MTU in endpoint is larger than MTU of the IDS, set the DF flag.
  
  
  • Desynchronize TCP sequence number state: if the IDS uses a 3-way handshake, simulate it; if the IDS resynchronizes with any traffic, just send fake traffic.
  
  
  • Reassembly attacks, e.g. when fragments overlap, Windows always keeps old data, Unix always keeps new data.
    

Intelligent Bluetooth fuzzing - Why bother?

Presented results from various Bluetooth fuzzing attempts, on l2cap and above layers (= what is implemented in software). In carkit testing, 13/15 carkits were problematic, some required dealer service; 10 crashed even without pairing.

Typical "anomalies":

• Length field over/underflows, especially in type-length-value structures, e.g. simply using length 0, 0xFFFF


• In type-length-value structures, inconsistent length and NUL-termination (when both is required)


• Data structure fuzzing, e.g. buffer overflows


• Repeating valid data many times (overflows, resource exhaustion)


• Flooding with a lot of valid data (no need to fuzz): especially for low-resource devices, e.g. headsets


• Some multi-field anomalies (when more than one field is fuzzed at once)


• Sending valid messages in incorrect sequence

Implementation notes:

• Many profiles use AT commands or OBEX, but different profiles often have separate parsers, so the same input in different profiles has different results.


• Typical defense focuses on preventing unauthorized access, not robustness.


• "Anomalies" sometimes propagate to underlying systems (e.g. authentication servers on the network)


• Some headsets die after an anomalous packet and never recover.


• A lot of code sharing: the same vendor stack is used in various devices.

Some bluetooth security measures:

• Pairing
  
  
  
  • Legacy mode is only a 4-digit code. Known values: 0000, 1234.
  
  
  • Can almost always connect via L2CAP to "PSM 1" without pairing (to make scanning possible).
  
  
  • The newer "simple secure pairing" mechanism can be downgraded to legacy mode
  
  
  • SSP "justworks" method does not require authentication; supposed to only allow host->client connections, but sometimes works the other way as well
  
  
  • Some devices stop requesting pairing after receiving anomalies
  
  
  
  
• Non-discoverable mode: the device may still accept connections.

Why this works: "You are not supposed to do that" (and detecting a specific form of attack instead of fixing the cause), "It's not i the spec", "Why should anyone care if the cheap device breaks?" (but Bluetooth is becoming more critical - used in medical devices, e.g. insulin pumps), writing reliable core is difficult.