Notes from 29th Chaos Communication Congress – day 4

See also day 1, day 2 and day 3.

The care and feeding of weird machines found in executable metadata

A “weird machine” = an unexpected source of computation e.g. return-oriented programming, heap crafting. This talk presents a way to perform computations through ELF relocation entries.

Why bother?

  • (Checksum of the complete executable file detects this.)
  • Philosophically, “composition kills”.
  • Antivirii seem to focus on code
  • Some people apparently don’t sign metadata…
  • It’s not clear how to distinguish “good” from “evil” well-formed data [which is same problem antivirii have with code, nothing fundamentally different]

Interesting ELF relocations:

  • R_X86_64_COPY = memcpy
  • X86_64_64 = *(base + reloc.offset) = symbol + base + reloc.addend
  • X86_64_64_RELATIVE = *(base + reloc.offset) = base + reloc.addend
  • STT_IFUNC symbol type: instead of symbol value, contains a function pointer that is called, and return value used as the symbol metadata

=> we can use relocations as instructions, symbol table entries as variables.

For jumps: modify our dynamic entry that points to the desired relocation[="instruction"], then modify dynamic linker’s internal data so that the relocation table is processed “again”.

Conditional branch: STT_IFUNC is only interpreted if “section header index” !=0 => can conditionally write based on that, and use it to conditionally terminate processing the relocation table (=> continue running a “different table” = target location).

Finished this exercise in spirit, with a brainfuck => ELF compiler…

OS-X MACH-O: Similar in concept. Relocation is called “binding”; relocation entries “compressed”: bytecode operations to set various parameters, then “do bind” opcode. Probably can do similar things, or at very least, can “disable” functions (e.g. seteuid() to drop privileges) by changing the symbol name being looked up.

Windows PE: similar work already exists (“locreate”: uses relocation entries as an unpacker, contains a PE+PDF+ZIP combo file)

Suggested mitigations: [but there's no real reason why bother, just sign the whole file and be done with it]

  • Suggesting page-level permissions (“elfpack”?)
  • Look at limiting the expressiveness of the format
  • More loader sanity checking (e.g. prevent the relocation entries from overwriting linker’s private variables or stack) might help

Page Fault Liberation Army or Gained in Translation

First summarized various creative uses of the page fault mechanism:

OpenWall: decrease code segment limit to exclude stack (need to recognize and handle gcc trampolines)

SEGMEXEC: use a 1.5G segment for data, and a 1.5G segment for code starting at 1.5G => separate page tables for data and code X restricted data space, using non-zero-base segments is very slow on modern CPUs

PaX: pages with “user”=0 => always cause a trap; then check whether it is because of EIP; if not, temporarily set user=1, read the page to fill TLB (data TLB only), set user=0 again.

OllyBone: Want to trap first execution after write (=> after malware unpacking), using same technique as PaX.

ShadowWalker rootkit: similarly, use different page frame number for code and data => rootkit detection won’t see the code.

In general, “those TLB bits are memory, you can program with them”.

“Labels & flow”: PaX looks for implicit flows from userland to kernel. Spreads labels over the various bits in the page tables. “h2hc 2012 presentation absolutely recommended”.

Contribution of this talk: a full programming environment [actually a Turing machine with no I/O] in which “no instruction ever finishes executing”:

  • Hardware task switching (task gate) used for memory storage. A task gate can be used as an interrupt handler (IDT->GDT->TSS); it reloads almost all CPU state from memory (incl. page tables); supposedly atomically, but actually dword at a time.
  • SP decrement is used for arithmetics (SP -= 4)
  • Double fault (when SP decremented from 0) is used as a branch mechanisms.

=> our single instruction: { x = y; if x < 4: goto b else {x -= 4; goto a} }

  • This single instruction is enough for a Turing-complete machine.
  • Needs one TSS descriptor per instruction.
  • Uses a different IDT per instruction.
  • “X” is stored as address of current task state.
  • “Y” are the addresses of TSS.
  • TSS “busy” bit problematic, we can overlay it over the GDT so that it is always cleared. This mechanism limits us to 16 instruction virtual addresses (but we can have more physical addresses => “16-color instruction CFG”.

No publicly available emulator implements this correctly!

  • bochs can do the Turing machine, but not all.
  • Intel’s Simics reboots the VM (triple-fault?)
  • KVM, Simics can be made to crash with a few changes (incl. the host in case of KVM?)


  • 32-bit only? “Working on 64-bit”, which was cleaned up and the used legacy mechanisms were removed.
  • Not tested on AMD

Posted in Uncategorized | Leave a comment

Notes from 29th Chaos Communication Congress – day 3

See also day 1, day 2 and day 4.

CVE-2011-3402 technical analysis

= embedded font with a kernel exploit.

  • Earliest use in 2010, discovered in Duqu in 2011; now a fully working exploit is used in the Cool and BlackHole exploit kits.
  • Font rendering: win32k.sys executes TrueType font programs in ring 0 (motivation per NT 4.0 documentation: “faster operation and reduced memory requirements”).
  • “CVT” = array of point values (a “variable storage area”)
  • The TrueType VM includes a function for bitmap merging while offsetting them (to do kerning), which misses a bound check => used to set a single bit in the length of the CVT, making it possible to overwrite the global VM state which follows the CVT in memory. This is memory-layout independent: in the TTF VM code, there is a loop that flips a bit in the global state and searches for a CVT offset though which it is visible => uses the TTF VM to help with the exploit!
  • Then the VM code overwrites a function pointer in the global data (which is supposed to point to one of 6 predefined rounding functions).
  • The TrueType implementation (probably?) hasn’t changed over the years => structure layout haven’t changed over the times.
  • All memory accesses are relative, the VM loop detects a precise offset => ASLR doesn’t help.
  • Font metadata in exploit: “copyright 2003 showtime inc. dexter regular” (reference to a TV show?).

A note from the lightning talks

“Help a reporter out”: You can give interview on anything if a reporter needs last-minute experts = advertising for free.

Analytical summary of the Blackhole exploit kit

  • ~12 PHP scripts that tie together various exploits, together with reporting/management UI
  • PHP => platform independent (also requires MySQL, IonCube)
  • It seems that many of the exploits were written by someone else, and (based on a public argument) rented (and unpaid) rather than purchased (eventually dropped in 2.0, replaced by other exploits).
  • “Cool exploit kit” very similar – ripped off blackhole, or a new brand by the same author?
  • There is a tool for brute-forcing Blackhole admin passwords :) => Blackhole added a captcha
  • Author? “Paunch” There is public contact info / live tech support contact, and a public fee schedule, e.g. $1500/year.
  • Source code was leaked == copied from a running server; some files missing, IonCube-obsfuscated.
  • Exploit URL: used to be …/main.php?id=[md5 of time of exploit run] … nowadays a little more randomized, but most of the content is always the same, with various strings unique to the exploit.

Overview of secure name resolution

Largely an overview of various approaches.

UDP spoofing: need to guess source port, transaction ID (~31 bits) => difficult for “write-only” attackers, but a local attacker that can read the requests can do it easily enough.


  • Signs records, not responses, but NXDOMAIN isn’t a record=> signed NSEC response “no names between A1 and A2″, which allows zone disclosure => NSEC3: “no names between hashes H1 and H2″ => have hashes of all names, need an (off-line) dictionary attack to get names.
  • No existing OS stub resolver does validation (Windows interprets results by a DNS recursive resolver, but that’s all).
  • Failures look like general DNS errors, user can’t override them; providers blamed->Comcast is maintaining a list of failures to ignore.
  • Depends on accurate time->DoS risk, and NTP pools depends on DNS.
  • DoS amplification, but countermeasures exist.
  • ISP wild-card redirect: still possible for a TLD operator (Verisign), or when the ISP validating for the user.
  • Root zone trust: Verisign has the zone key, this is signed by an ICANN key, which has 4 HSM with copies, authenticated with 3/7 smart cards -> 3/7 physical keys

DNSCurve: on-line signatures, forwarders impossible. All 300 root servers would have to have the private key (ICANN doesn’t want this); higher CPU load requirements.

Namecoin=modified Bitcoin, with every client having a full name database (=> crazy?)

EMV walkthrough

For connecting a smartcard reader, use PC/SC; you don’t need a specialized “EMV” reader – it’s all ISO 7816.

Nothing new otherwise, just a walkthrough through the publicly available EMV standard.

Hash-flooding DoS reloaded attacks and defenses

Attack first suggested in 1989 by Solar Designer in Phrack. Published in 2003 at USENIX. Another publication in 2011.

Possible countermeasures:

  • Use a “safe” structure, e.g. a balanced tree, for handling collisions.
  • Just discard cache entries that would cause a large collision list (if discarding data is OK).
  • Not: use SHA-3: a) it’s slow, b) it doesn’t work – SHA-3 is collision resistant, but (SHA-3 mod (small hash table size)) is not collision resistant.

Common response: use an application-specific secret key to randomize the hash function

MurmurHash 2: block processing is independent of seed value; the state is set to seed, then updated by incoming data => we can create pairs of input blocks that cancel each other WRT the hash state => for 16n bytes, can create 2n collisions, irrespective of the secret seed.

MurmurHash 3 (introduced as a response to the attack), we can do the same thing.

Trying this attack:

  • on Rails: need the string to pass some format checks, can just brute-force for acceptable values. For www-form-urlencoded data, Rails limits the total number of parameters => safe, but JSON data is not protected. Lesson: patching this kind of vulnerability in applications doesn’t work: too much code, too many opportunities for loopholes.
  • on Java: the only issue is that you need to construct “char” (16-bit) character strings.

Both cases reported, with CVEs [what about other languages?] Reactions: No response from Java; The Ruby problem was fixed in cruby, jruby, rubinius.

Possible fixes:

  • “Don’t use MurmurHash”?
    • CityHash: even weaker than MurmurHash – can find more collisions for the same length of string.
    • Python’s hash(): a little better than MurmurHash, but still not good: uses hash input as a key to encrypt the seed, takes this as a hash result; so if we can see the hash value, we can just decrypt the value to get the seed – and randimization is optimal anyway.
    • Marvin32 (.NET): no results for now, looking at it
  • Introduced SipHash: “fast short-input PRF”.
    • rigorous security analysis (peer-reviewed research paper).
    • 256-bit state, 128-bit key. Can use an arbitrary number of “rounds” for compression, or for finalization => SipHash-X-Y naming. Proposing SipHash-2-4 for general use.
    • Strength claims: ~2128 key recovery, ~2192 state recovery, ~2128 “internal-collision forgery”. With ~2s effort probability of forgery 2s-64.
    • ~1200-200 cycles per 8-64 bytes, 1.44 cycles/byte for long messages => < 2x slower than CityHash, SpokyHash.
    • 18 third-party implementations in 8 days already.
    • Now used in Perl 5, cruby, jruby, others
  • Why not use other cryptographic hashes? SHA-3 is much slower than siphash. “Blake” is 2-3x slower than SipHash.

The future of protocol reversing and simulation applied on ZeroAccess botnet

Introduces “Netzob”:

  • Infers protocol “vocabulary” and “grammar”
  • Can simulate a client/server/fuzzing
  • Can export the analyzed protocol in various formats, including a Wireshark dissector.

ZeroAccess botnet: 2 ways to gain money: click fraud and bitcoin mining

Protocol inference:

  • Split messages to fields:
    • Find fixed-width fixed/variable fields
    • Find delimiter-based fields
    • “Sequence alignment” – find maximal-length common sequences (=> maximal-length fixed fields) for the sample, then convert into a regexp.
    • Supports hierarchical message format, with each level using a different method
  • Cluster similar messages. Similarity = “ratio of dynamic fields / bytes”, “ratio of common dynamic bytes”. Use UPGMA hierarchical clustering.
  • Find values that vary depending on context (IP address, time, …)

Encoding (XOR, ASN.1), encryption: can define transformation functions, and add more functions; apparently must be selected manually.

Finding field relations automatically: Try various transformations of a field (or a field combination), then use “maximal information coefficient” for finding correlated values. Includes environmental context as possible information sources.

Protocol rules: collect message sequences => build automata (with probability, reaction time on arcs). Then Angluin L*a to infer a grammar.

There is GUI to help with all of this, interactively naming fields / changing display format and the like.

Posted in Uncategorized | Leave a comment

Notes from 29th Chaos Communication Congress – day 2

See also day 1, day 3 and day 4.

Certificate Authority Collapse

DigiNotar notes:

  • A single MS Exchange controlling all servers.
  • Administrator password Pr0d@dmin.
  • 30 software updates ignored, including some years-old ones.
  • Mitigations:
    • Dutch government overtook DigiNotar, no known legal basis(!): “On a private law basis = DigiNotar submitted voluntarily”
    • Trust revocation was delayed in the Dutch market for weeks by Microsoft.
    • The mitigation considered a success story by the Dutch government.
  • The government allowed digiNotar certificates in e-commerce (tax submissions) 11 months after the cert breach!
  • DigiNotar is still running as an intermediate CA. [What does it mean after blacklisting?]

“Systemic vulnerabilities”:

  • Any CA can vouch for any domain name.
  • CAs trusted “by default” – you go through a paper trail, not audit trail.
  • Intermediate CAs “sublet” root status.
  • it’s difficult to attribute an attack to a specific attacker.
  • Information asymmetry – victim can hide the risk to its users.
  • CA revocation: connectivity vs. security trade-off, and “the end user only wants connectivity”.
  • Poor HTTPS implementation (see SSL pulse)

EU eSignature regulation:

  • “Regulation” => once adopted at EU, directly binding in all member states
  • Covers “trust service providers established in the EU”, incl. CAs; other stakeholders (HTTPS servers) unregulated (the only known argument for this restriction is that EU organizations are also insecure).
  • CAs to be liable for “any direct damage” => better incentives, but the possible liability is very large => large insurance expense => barrier to entry.

“EU should”:

  • Apprise all underlying values, incl. privacy
  • Evaluate incentives of all stakeholders X no specific problem mentioned
(The speaker suggested that the liability should be with websites instead; overall looked looked a little like a lobbying effort to ease CA burden.)

Some interesting lightning talks

  • SMrender = z programming language for OpenStreetMap data;
  • GNUnet: secure p2p networking, “censorship resistant DHT”. Anonymous NAT traversal (established by an ICMP reply forwarded to the inside)
  • OpenITP peer review board: “qualified” projects will be audited by commercial firms, sponsored by OpenITP.

The Tor software ecosystem

A fairly long list of various Tor software projects, asking for help ( Only a few highlights here:

  • “Thandy”: a package installer/updater that protects against attacks on the update system, e.g. pretending that there isn’t an update. Might be interesting for Fedora as well?
  • TLSDate = a time client using TLS for transport. Not a good NTP replacement, but cryptographically protects current time (=> can detect obsolete “Tor consensus” etc.)
  • Tor cloud bridge images (for amazon and others). Can be used to contribute to Tor, or for personal use (to spin up a personal bridge on Amazon when Amazon is available through the firewall)
  • Some statistics from 31% of exit nodes in Germany, 21% in the US; a single German AS owned by CCC accounts for 19%. 500k users/day.
  • Flashproxy: any client visiting a web site is turned into a Tor bridge (!) Implemented as AJAX, which can do only outgoing connections => it connects to Tor, and to the “censored user” X still need to somehow pierce NAT.
  • Tor is 80% funded by the US government. When asked why it should be trusted, the answer was “It’s the only system where you can read the source code and see whether it can be trusted.”


Various loosely connected topics regarding RSA factorization. See also

  • “Factoring probably isn’t NP-hard.”
  • The sage math package can factor a 256-bit modulus factored in 500s.
  • Instead of factoring, can we just guess? There are >2502 primes between 2511 and 2512 => in the ideal case unusable, but if the RNG is weak…
  • A fairly difficult attack: buy various devices, generate billions of keys, check whether any of the primes divide the attacked N. This actually works:
    • In 1995, the Netscape browser generated only ~247 keys in a specific second.
    • Debian key generator bug
  • Easy attack: take two keys, look for a common factor. Use batch GCD for testing all pairs (the “Minding Your P’s and Q’s” paper by Heninger et al. describes this in more detail) => found tens of thousands of keys. There was another similar paper in the same time frame.
  • More examples of bad randomness: Chou 2012: factored 103 Taiwan Citizen Digital Certificates (out of 2,26 million), corresponding private keys are stored on smart cards.
  • Overview of algorithms for factorization:
    • Trial division takes time about p/log(p) to find p.
    • Pollard’s rho method: typically about sqrt(p) steps.
    • Pollard’s p-1 method: also about sqrt(p) steps, but only for “smooth” primes (p-1 has lots of small factors). We can avoid such p values, but there is a generalization…
    • = “Ellliptic curve method”: works if the number of points on a curve modulo p is smooth; there are many such curves => we can’t exclude “weak” p values => we want to choose p and q of same size to avoid small factors (but shouldn’t take p and q too close to each other, then it’s possible to brute-force the area around sqrt(N))
    • Fermat factorization: always works, but O(p) steps if the primes are not close
    • ~1024-bit RSA key can be factored in ~280 operations (using number field sieve) [whatever "operation" means]. This already feasible for botnets and large organizations! It is estimated that scanning ~270 differences will factor any 1024-bit key; the Conficker botnet can do that in < a year (but it would need to remain be undetected over the year => can’t use full CPU power). On the other hand, a private computer cluster (e.g. NSA, China) might do it. (NSA plans a computer center with 65 MWats => ~219 typical CPUs, i.e. 284 floating-point multiplications/year).
  • Factoring via Google: "BEGIN RSA PRIVATE KEY" (15 000 results (!)).
    • As a special case, there is a pasted key with the “middle” missing; a RSA private key may contain many precomputed values => there is redundancy, and only if you have a part of a single value of the private key, you can get the rest.
  • Lessons:
    • Stop using 1024-bit RSA.
    • Make sure your primes are big enough.
    • Make sure your primes are random.
    • pastebin is not a secure cloud store
    • … and you shouldn’t put keys even in a secure cloud store anyway.

Q/A session:

Would you recommend ECC or multiple-prime RSA?
ECC will give you much higher security level if you have performance limitations. OTOH DSA (including ECDSA) is much worse than RSA in terms of randomness failures.
What is a recommended alternative to 1024-RSA?
For 5-10 years “very comfortable recommending” 256-bit ECC.
Can you quantify the proportion of “weak” primes?
For 1024-bit keys they are rare enough that it is not necessary to worry about it.
How do I know that my RNGs are fine for generating keys?
“Seed them”: Linux has patched some problems we found. Generating keys on a general-purpose computer that has been running for a long time is probably fine; wouldn’t generate keys on a low-power computer.
Can I estimate the quality of a generator from a sample of keys?
Use, check against the internet-scraped key list; or do the same on a large sample of keys generated by the RNG under question.
How much effort would it be to upgrade to RSA 4096 or 8192 key?
  • You’ll notice degradation of performance (2048 is not a big deal)
  • US govt recommends to stop using 1024-bit key as of 2010, still used everywhere, so in practice expect difficulty.
  • Financial standards impose 1984 bit maximum while at the same time requiring 4096 :)
  • 2048-bit RSA may make a busy server unable to handle the load => ECC preferred
How do I unit-test a key generator?
NIST standards for RNG testing isolate the random and deterministic parts of the code => can unit-test the deterministic part. Unfortunately, ECDSA needs RNG for each operation, so the two parts are mixed. (Story: a manufacturer had a testing step in the production that switched all devices in a group at the same time => all inputs were the same => long-term keys generated on first boot were all generated the same.)

Defeating Windows memory forensics

Memory forensics is increasingly popular:

  • It’s easier to detect malware in memory than hidden on disk, there is also memory-only malware.
  • You can see resource use, connections (incl. recently terminated)
  • You can find passwords.

Memory acquisition methods:

  • Hibernation file
  • Memory dump on blue screen
  • External tools: use a kernel-mode driver to access the physical memory (often just a proxy to \Device\PhysicalMemory, or uses low-level APIs). Such a crash dump may or may not include device memory or register contents.

Dump Analysis: “Personal choice” of what tool to use: “Volatility” framework.

Current antiforensic techniques:

  • Block acquisition: Prevent loading the (well-known) driver (E.g. a metasploit script, not available any more). Possible evasion method: just rename the process or driver.
  • “1-byte modification”: Every tool has “abort factors” that break the analysis implementation => just make small modifications to the OS in memory. This doesn’t let you hide anything you choose, and breaking analysis will be noticeable.
  • “Shadow walker” = custom page fault handler: data access redirected elsewhere, code execution allowed (desynchronized code/data TLB). This is “really unstable”, unusable on multi-processor, code of the page fault handler can’t be hidden. Impacts performance.

The weakest link in dump acquisition process: storing the dump => a rootkit can fake the dump as it is being stored. Something similar was already done in 2006 for disk forensics.

=> Newly introduced tool in this talk: Dementia.

  • Kernel implementation: can hook NtWriteFile() (not supported by MS, prevented on 64-bit), or use a filesystem mmfilter driver.
  • Detecting that a memory dump is being written by “patterns” (NtFileWrite arguments/process name/driver / FILE_OBJECT values/flags).
  • then either scan the data being written for what we want to hide (which is slow), or build a list of all “somehow related” pointers, then find them and replace them (e.g. remove the structure from a linked list); this relies on internal data structure layout but “windbg can do it” (using MS PDB symbols, DbgHelp API). Still, “traces of activity are everywhere”. [In Volatility: Just deleting the "proc" allocation will fool most of the plugins - dereferencing a pointer/handle that doesn't point to a known process aborts the analysis step]
  • (The talk contained a detailed list of activity done by Dementia to hide information…)

Actually… almost all memory dump tools are copying the data from the physical memory to user mode, and from then to the file => an user-mode-only attack is sufficient to hook the dump file writing (it would still need admin privileges because the dump tool runs as admin) – but it’s actually more difficult to do in user mode-only: no knowledge of kernel addresses of data structures, physical/virtual mapping (because the only known information is what has already been written, we can’t do random access inside the image being written to search for information).

Limitations of Dementia:

  • Quite a few object types not hidden
  • Not even hiding itself fully
  • x64 port not yet done


  • Dump acquisition tools should write image from kernel-mode: it’s more secure and faster
  • Hardware acquisition methods (e.g. Firewire) preferred
  • USE native crash dumps instead of raw dumps
  • Perhaps search for rootkits first? It’s not clear whether it would be effective.

Let me answer that for you

“GSM paging”: paging channel (downlink only broadcast) is used to start a “service” (call/sms). Each message contains mobile identity (IMSI/TMSI) (t = “temporary” mobile subscriber identity, for privacy]. On paging receipt:

  • The phone sends a channel request.
  • The phone gets a channel assignment.
  • The phone responds to the paging message.
  • Then communication happens on the assigned channel, authenticated/encrypted. This is supposedly not possible to easily hijack, the authentication/encryption uses a SIM-based key.

We can send a bad paging response => duplicate responses on the air, typically a DoS.

  • Not limited to a single BTS, paging is sent to a wider “location area”.
  • How to respond faster then the victim? Weather etc. are a factor, but the baseband latency is most important. => modified osmocombb, integrated the relevant L2/L3 code inside L1.

To identify victim address:

  • Just block everyone.
  • Use 3rd party services to lookup the number->IMSI mapping in HLR.
  • If TMSI is used: create a call, drop it soon enough (=> no ring), or send a silent SMS; then sniff for the paging request, and capture the TMSI.

Hijacking content delivery:

  • Handling encryption: India reportedly still uses no encryption. Some networks use A5/2, which is too weak. A5/1 broken now as well, almost in real time. A5/3 is not deployed now (some phone manufactures haven’t implement it correctly, so deploying it would break networks).
  • Handling authentication: 50% of networks authenticate only 10% of SMSs/calls [because they earn money only by outgoing calls?] => 90% of services can be hijacked (the victim never receives it)

In O2 Germany: the hijacker sets up a channel, but doesn’t respond to auth request; victim then responds to the paging request and authenticates ordinarily => hijacker is now authenticated as well!

Attacking larger areas:

  • It’s enough to be within the same “location area” of the HLR, not limited to a single BTS. Based on GPS logs, ~5 Vodafone locations areas in all of Berlin (Berlin: 100-500 km2>); non-city areas even larger, seen 1000 km2. => paging DoS is way more effective than jamming such a large area.
  • To make the attack more efficient, instead of reacting to every paging request, can send a “IMSI DETACH” (ordinarily sent by the phone when shutting down, request is not authenticated at all!).
  • On a real network, Vodafone sends about 1200 paging requests per second. The current attack takes about 1 second per request … but the necessary Motorola phones are cheap [active attackers are just not taken into account by GSM standards].

Once you can hijack a SMS, you can do MITM – there are gateways that allow specifying a sender; or just don’t ACK the transmission and it will be resent to the victim.

3G: in theory using the same system, but it is on a separate network => we can’t use the current GSM attacking hardware.


  • Authenticate 100% of the time to protect against hijacking
  • Authenticate paging requests to protect against DoS (=> changing this is infeasible.)

ESXi Beast

Introduced “Canape”, a free-as-beer protocol testing tool, “GUI IDE”, in .NET. For traffic capturing, supportws SOCKS, port forwarding MITM, application level HTTP/SSL proxy.

ESXi protocol: network management of virt products. Actually several protocols over one connection: remote desktop, file transfer, database, …; transitioning from/to SSL over the socket over time.

The talk was mostly a demo of the tool.

Posted in Uncategorized | Leave a comment

Notes from 29th Chaos Communication Congress – day 1

See also day 2, day 3 and day 4.

Not my department

  • Called the US a totalitarian society / surveillance state
  • “Anonymity will buy you time, but it will not buy anyone justice.”

ISP blackboxes

CMWP = CPE WAN management protocol: used to manage “CPEs” (Customer Premises Equipment = home router) by the ISP. Bidirectional SOAP/HTTP, the CPE connects to a configured server URL. Can read/modify configuration, reboot/reset/flash firmware.

New projects:

  • libfreecmwp / freecmwp: a client, intended for OpenWRT.
  • freeacs-ng: server; uses a separate “provisioning backend” connected through AMQP for the actual data.

Interestingly, configuring the CPE enough to be able to use IP/TCP/HTTP/SOAP and talk CMWP is out of scope of the standard.

Our daily job: hacking the law

A set of recommendations for lobbying:

  1. You need to have a clear goal.
  2. Be prepared [take a multi-year view, take advantage of opportunities].
  3. Frame your message well.
  4. Know what the legitimate interests of the opponent are.
  5. Stay focused.

Setting mobile phones free

Introduces a new Dutch mobile virtual operator. An interesting feature is the ability to route all incoming calls to customer’s SIP server (=> the customer can direct them to the cell phone as usual, or do something else)

Most of the talk described various aspects of pricing throughout the network operator ecosystem. The only thing I found new was that incoming roaming calls may be more expensive than the EU-regulated maximal end-user price; some virtual operators thus simply don’t provide this service.

As for wiretapping: the law requires wiretapping, but they were asked to sign a NDA before setting the wiretapping up. Because the law doesn’t mandate any NDA, they refused to sign it, it’s unclear how this will develop.

Re-igniting the Crypto Wars on the Web

An overly sensational headline for essentially an invitation to review the proposed W3C JavaScript crypto draft.

Trust assumptions: re: “JavaScript cryptography considered harmful”, it is “essentially right given presuppositions”: we still trust the server, CSRF is still a problem, yes, this doesn’t fix it. Still, the proposal provides some otherwise impossible functionality (secure RNGs, constant-time operations, secure key storage…) right now. Also, “it’s easy to seize client devices; server-based security ["in the cloud"] is not a terrible thing”.

Currently there are ~30 open issues.

API design:

  • Originally started with a high-level idiot-proof API, but gave up on it for now as too difficult; so the current proposal is a low-level API
  • Old and broken algorithms are available for compatibility. We could exclude the currently broken algorithms, but once something is included now, it will be impossible to remove and it still can become broken later, so treating the currently broken algorithms as a special case is not that useful.
  • Provides asynchronous interface to crypto ops.
  • Haven’t decided about key derivation design

Key storage: “as supercookies”. Keys could be used for fingerprinting like cookies:

  • So, we want keys to be at least as safe as cookies
  • Also, we want to give the users a “clear keys” operation; therefore this is aimed at more or less ephemeral keys, (Long-term persistent keys are not the primary use case, multi-device key synchronization/management is out of scope.)

Privacy and the car of the future

Describes a “DSRT” (Digital Short-Range Communication) mechanism:

  • “short” = 380m;
  • Vehicle-to-vehicle communication: for safety
  • Vehicle-to-infrastructure communication as well (e.g. no red lights on an empty street)

“It already is happening”:

  • Large-scale tests under way to quantify impact of the system on accidents.
  • All auto-makers are involved.
  • HW ready to ship, SW still being developed.
  • US dept. of transportation considering mandating this for new cars, German govt. considering infrastructure deployment


  • Basic safety messages sent every 10 seconds; ~50 elements
  • Not a CANbus bridge
  • Radio: 5.9 GHz, 802.11p, fixed-length => “similar to slotted aloha”
  • Not an “automatic system”; only to warn drivers

Authentication: Everything is cryptographically signed, certs issued by a central authority based on “system fingerprint” (but without a paper trail to owner); on malfunction, the cert is revoked and system fingerprint is blacklisted => the radio unit needs to be replaced.


  • MAC layer: all-zero source address for vehicles (to reduce tracking) => protocol is unrouteable; making it routeable would require ID tracking.
  • Basic safety message: contains a “temporary ID” to allow contacting application; suggested creating an open source implementation to avoid broken implementations.
  • Certificates: identity vs. validity conflicts
    • For privacy, certificates with short validity and refreshed (X how often? We could instead pre-generate certs in advance, but that won’t update the blacklist; updating the blacklist requires on-line connectivity anyway.)
    • Fingerprints hard-coded in the device “strongly discourage hacking” because of the cost of replacing, but it’s difficult to ensure fingerprints won’t be disclosed and tracked.
    • How to deliver certificates? Cell phone, wifi infrastructure contains source addresses. (The HW was shipped, even though this is still not resolved.)
  • The original proposal included road pricing / toll road integration, abandoned as incompatible with privacy.
  • Is it all worth the effort, when one can already identify the person using a cell phone?
  • “Worrisome noise” related to this:
    • Geo-targeted advertising and similar “funding” schemes.
    • “Data brokers” might be interested in running the fixed infrastructure to access data.
    • law enforcement: speed is broadcasted, correlating this with camera identification would be fairly easy (X that would hinder adoption) (the cameras can already identify a car, but to precisely measure speed the radar needs to be “calibrated” (?))

What can be done now:

  • Hack the radios (commercially available)
  • Hack the protocols (802.11p public)
  • Politically engage (US: nat. HW security administration; EU: ETSA); Decisions are mostly made by unelected standards bodies. Help them find funding without “selling out”

Insurance impact:

  • “Regulation will probably only allow rate reductions” based on this.
  • Insurers will want the data, but probably don’t have the political power.
  • Car black boxes are already mandated in the US

Infrastructure-to-vehicle: Discussed in Europe for traffic management (“accident ahead” etc.) abandoned in US because of funding isues (little money for roads expected).


  • Nothing stops one from relaying a message to a different location (but the message contains location, so it isn’t an attack); and this will be wanted for various statistics
  • Similarly, can replay an old message (but each message contains a GPS-originated time stamp)
  • “You can send all sort of funny stuff”, e.g. fake sensor input “I don’t like to talk too much about it, covered by NDA”.
  • “Auto manufactures recognize CANbus is so insecure that they don’t trust it” => DSRC would use a separate, independent control unit.
    • “I might believe they are ready to abandon CANbus”.
    • “The real problem with CANbus are the weird extensions”, like USA-mandated tire pressure sensors

SCADA strangelove

Europe is the region with most internet-exposed SCADA vulnerabilities; Italy the most vulnerable country (not sure why – perhaps highly industrialized country, wide deployment of smart grid).

Industrial users think SCADA are isolated networks, on special => “safe” platforms, but:

  • 100% of tested networks are (typically indirectly) exposed to internet.
  • 99% can be hacked with metasploit (some reboot on TCP connect scan)
  • 50% of “HMI” engineering stations are also used as desktops
  • Standard network protocols, standard OS, DPMs, apps, are used (typically Windows/SAL for SCADA, Linux/QNC for PLX) … but no security; ICS experts don’t view it as a computer system

ICS transports: Ethernet, GSM/GPRS, RS-232/485, Wifi, ZigBee, others.


  • Sniffing: Wireshark supports most it, some 3rd party protocol dissectors. Also industry-grade tools (“FTE NetDecoder”).
  • Spoofing/Injection: Tools available for modbus; need to use generic tools (scapy) otherwise – but can just replay packets for most protocols.
  • Fingerprinting: Well-known ports used
  • Fuzzing: most devices will crash within a minute

PLC: “just a network device”

  • Finding vulnerabilities: Getting a PLC for a lab is difficult, but getting a firmware from the internet is easy.
  • Siemens S7 PLC: Found a hard-coded private “certification authority”, apparently found also the private key.

SCADA: = network application connecting to PLCs, running on top of an OS/DBMS

  • => Not necessary to hack SCADA, can attack OS/DBMS. Typically has a restricted OS configuration (kiosk mode etc.) [e.g. PLC firmware updates have to be signed by a key on a HW token, but a PLC has a root/toor ssh account that bypasses this.]
  • WinCC: uses a database to store most information.
    • Had hard-coded passwords; noticed in 2005, abused by StuxNet in 2010, and fixed in 2010, but still works almost everywhere. [username/password was published on a Siemens forum :) )]
    • MS SQL listening on the network (=> all security needs to reside in the DB, difficult to rework this design)
    • Inside the database: passwords are XORed using a fixed ASCII string
  • DiagAgent:
    • Not started by default, Siemens recommends not using it
    • No auth at all
    • XSS, path traversal, buffer overflows.
  • WebNavigator:
    • HMI tool as a web application
    • XPath injection, path traversals, ~20 instances of XSS… fixed now
    • XSS in HMI => can use operator’s browser as a proxy to SCADA network
    • Looking at plugin lists, a lot of companies/companies/industries access the network using IE with HMI plugins… (was asked “how do I install Firefox on Windows 3? this IE won’t run Facebook”). How to mitigate? “A guy with a gun standing behind the user is also a way to do risk management”.

The authors released some SCADA tools:

  • ??? “dorks”?
  • Device scan/fingerprint tools for modbus and S7
  • metasploit module for WinCC
  • “SCADA Security Hardening Guide” published

Summary: There’s lots of low-hanging fruit, it’s scary.

Highlighted great experience with Siemens’ security team: good cooperation, quick replies, even provided patches.

A lot of companies have no patch management, (“It’s working, don’t touch it”) => need vendors to push customers (“Guys, you need to update to make it work”). Also, companies can’t change things because it would break certification.

The worst thing they found: Windows 95, Windows 3.1 (typical situation: bought the system ages ago, got “spare parts” (=replacement computers) in stock if they fail, have no idea how these things work or what’s in there)

A commenter noted that supposedly nuclear plants now use wifi instead of Ethernet because Ethernet means validating “every meter” of the cable, whereas wifi works everywhere.

Posted in Uncategorized | Leave a comment

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.

Posted in Uncategorized | Leave a comment

Do Not Believe in Structured Logging

This is based on my first-hand involvement in the audit attempt at structured logging, and on the results of documenting the audit records that were actually sent by various programs. It is rather long, I’m afraid—but please read at least the “issues” section; these lessons were learned the hard way, and any plan that ignores them will fail.


  • Issues:
    • Any generic log parsing tool WILL need to handle unstructured text. Always.
    • Any structured logging format WILL be used inconsistently.
    • There WILL NOT be an universal field name namespace.
  • Implications:
    • You can only “trust” data that always comes from the same piece of code.
    • Most log analysis code must specifically know what record it is working with.
    • Structured logging formats can not deliver what they promise.
  • A potential recommendation:
    • Do not define new structured logging formats.
    • Define an universal field syntax. Make it trivial to use.
    • Treat unstructured text as the primary format, and optimize its use.
    • … but is it really worth it?
Continue reading

Posted in Programming | 1 Comment

Notes from 27th Chaos Communication Congress – day 4

Here are some notes from the final day of the 27th Chaos Communication Congress. See also day 1, day 2, day 3.


Can have a PDF that displays different output depending on OS/Locale – even without JavaScript. Can do a lot from JavaScript, Postscript if “signed by trusted cert”. PDF is a container – can contain Flash that is auto-started.

PDF streams: ambiguous syntax for determining input size – can overlap other data in the file. Document metadata is readable and writable in JavaScript. Lots of metadata that can be used for storing arbitrary data. Redefinitions of a PDF object – last one wins, even ignores the xref table.

%PDF header can be anywhere in first 1024 bytes => can make a file that is both valid PDF and {ZIP, EXE, GIF, HTML}.

Antivirus evasion: Not tested – most AVs didn’t find even a very common exploit; if they did, then only using a generic signature. Various format confusion methods confuse some AVs.

Lightning talks

  • TV-B-Gone for N900 – N900 has an IR xmitter
  • Monitoring spyware – CERT-Polska monitoring ZeUS (not a virus, needs to be dropped by something else).
  • SystemTap: “a code injection framework” – need only 3 lines to sniff IM from libpurple
  • “Hacking governments” – Talk proof of concept: graphing relationship structure of relevant people?
  • UAVP-NG: UAV (“quadcopter”) PCBs + software, GPLv3:
  • Privacy: “transparency is more difficult than having things in the open”
  • “Semantic web” linking social networks
  • = W3C federated social web XG: “WebID”

Data monitoring in terabit Ethernet

It is easy to monitor bus topology; point-to-point harder – especially duplex (2x link capacity needed). Observing optical traffic can be done using a splitter, but must be done for each direction separately. This is easier with switches – can copy traffic, but combined traffic may be too much for the analysis port.

“Data Mediation Layer”: a device that collects observed traffic from >=1 sites, distributes it to >=1 analysis machines (based on rules): aggregation (>1 input → 1 output), regeneration (1 input copied to >1 output), distribution (depending on content), filtering (L2-L4), manipulation (“packet slicing” = discarding packet content, masking (to hide sensitive data), timestamping, annotation with input port number). The DML allows can filtering out most traffic and consolidate it (therefore fewer and weaker analyzing machines are necessary).

Examining existing filters: stored on device – could perhaps use serial TTY for access?

Web GUI: firmware updates not automated. Gigamon allows getting the filter list without authenticating.

DML machines have default accounts.

How the Internet sees you

Autonomous system = a network operated under a single policy: only sees what passes through (assuming no cooperation between entities, or data collection by law enforcement). A tap = mirror port, optical splitter, or a function in the switch.

Surveillance (e.g. law enforcement): can see everything, but have to store / analyze it all.

A “flow” = set of IP packets passing during a certain time interval = (src IP, src port, dst, IP, dst port); ~50B/flow, flow ID and data volume is stored. “Netflow” = export of flow records: lower data rate, but no packet contents, higher router overhead (could fill up the flow table?).

NetFlow v5: common, need v9 for IPv6. IPFIX ~ NetFlow v9: uses “information elements” = (field ID, value) pairs.

Storage requirements: large ISP (2M flows/s: 2 PB/s all data, 4 TB/day netflow).

sFlow: sampling – only e.g. 1/4000 packets => little data, easy overhead (only need to copy headers, not parse the packet), can miss data.

Handling meaning of IP addresses: By log DNS queries and answers, can understand virtual hosts without parsing HTTP. Also can reveal otherwise unannounced domains (completely new domain with millions of users probably means malware).

Using this, ISPs can do accounting/billing, but can also build an user’s profile – based on (restricted set of) used services, but also by connections to automatic update servers (a signature visible on IP/DNS level).

Experiment on 27c3: 1/4k packets captured, anonymized IPs => can’t do DNS, nothing stored.

“If you want to be anonymous, be a sheep” so as not to stand out – no clearing cookies, no Tor… “Do not connect to a known Tor exit – use a special bridge”. IPv6 privacy: enabled by default on Windows, disabled on Linux – probably does not help anyway.

Open source tools: NFSen, ntop

RC4/WEP key recovery attacks

Goal: automated cryptoanalysis tools.

Overview of WEP: Uses RC4 stream cipher = key stream generator to XOR with plaintext. WEP can lose packets, so each packet is encrypted independently, RC4 key = (secret key, 24b counter = IV), IV contained in the packet.

RC4: consists of key schedule and a pseudo-random generator. Key scheduling has a strong bias towards secret key. PRGA: Only 2 bytes in S swapped per PRG byte => can find biases of PRGA, allowing to guess at scheduled key from keystream (then we can guess at keystream bytes).

Looking for more PRGA biases:

  • Starting with 1st keystream byte and all relevant inputs, statistically find biases. Too many possibilities still – restrict some values to {-1, 0, 1} => Found new biases, with strength varying by round and values.
  • To try other than values than {-1,0,1}, used Fourier transform chosen such that the key schedule correlation applies, and found more biases.

“Black box approach”: Just use first 256 bytes of keystream and key bytes as a linear equation. This is too large => limit to first L bytes of both key and output => found new biases again (new because we observe correlations “caused” by PRGA rounds).

Attacks on WEP – improvements: Can recover sum of key bytes (again through a bias). => To recover WEP key with P=1/2, need only 9,800 encrypted packets.

Posted in Conferences | Leave a comment

Notes from 27th Chaos Communication Congress – day 3

Here are some notes from the third day of the 27th Chaos Communication Congress. See also day 1, day 2, day 4.

SIP source routing

SIP: derived from HTTP. Typical flow: A→B invite; B→A ringing; B→A OK; A→B ACK; RTP flow. Can talk through proxies or directly (typical case: SIP – home router – SIP proxy + RTP relay – PSTN gateway). Every SIP phone is a server! Names: foo@bar, client registry. Can have multiple clients with 1 address, call will be forwarded to all.

Principle: stateless core => state is in the message = “source routing” - describing all proxies on the way.

Authentication: RFC says use HTTP digest – but you can’t authenticate on/through a proxy. This allows faking caller IDs.

Can send data to internal LAN: Contact sip:…@, or use source routing (either invites, or “RTP” = arbitrary UDP!)

It might be possible to open a port by sending SIP-like XMLHTTP requests (make the browser send a request from the client to attacker, confuses the NAT router).


  • Drop SIP that doesn’t come from a trusted proxy: IP spoofing still a risk.
  • Ignore IP addresses in SIP: this violates end-to-end principle, we have both huge messages and stateful proxies.
  • TLS: Needs stronger hardware.
  • IPSec: Difficult to deploy. “3GPP IMS” (mobile) uses IPSec to replace some other SIP auth functions.

Console hacking

Wii summary: 9 firmware updates, out of that 1 real feature (the rest vulnerability fixes). ~30M/73M machines manufactured with vulnerable bootloaders. ~1M users of “Homebrew Channel”. “Pretty much broken from the beginning”.

XBox360: only 2 major hacks, both minor bugs that were fixed.

PS3: Supported Linux => everything worked (except 3D which was intentionally disabled). Now that Linux was removed, becomes “interesting”.

Statistically, if Linux is not available, then it will be hacked so that it can be used. Most hacks to run Linux, not piracy – but piracy is made possible as a side effect.

PS3 architecture: PPC + 8 SPUs. An “isolation mode” available – most of SPU’s memory becomes inaccessible to the PPC. In PPC: LV1 = hypervisor, LV2 = GameOS, games in user mode. SPUs are accessible from LV[12]. The boot process consists of “interleaving” SPU and PPC execution.

PS3 has encrypted storage, but uses the same key and IV for each sector => if we store known data, we can use the PS3 for decryption.

“Geohot exploit”: glitch memory address lines (“really amazing hardware”) to be able to manipulate HV’s view of memory allocation.

PSJailbreak (+clones): USB device exploits a kernel bug => LV2 code execution. The device is an “USB hub + devices”: Device 0 contains payload in USB descriptor. Device 4: because the descriptor size read twice, it can change between reads, which confuses code and causes buffer overflow, overwriting vtables. PS3 doesn’t have W^X protection on LV2, hypervisor does not authenticate executable code (unlike Xbox), so LV2 is compromised, HV is not – but still allows pirating games. Sony fixed this, but downgrade is possible: USB service mode authentication uses HMAC, the key was leaked. => AsbestOS: replace LV2 in memory by Linux – just like OtherOS but 3D is enabled.

Encrypted ELF format: encrypted metadata key, encryption metadata authenticated by ECDSA, this authenticates rest of the system. We don’t need the keys, the secondary SPE will happily decrypt the data for us :)

Boot loader revocation mechanism: list of software that should not be booted. Buffer overflow on revocation list decryption => can run arbitrary code, get keys … => boot chain of trust broken.

ECDSA signature on executables: ECDSA depends on randomness and uniqueness of a random nonce, but Sony reuses a single “random” value => can extract private key => can sign own executables – LV2, revocation lists, etc.

Analyzing a modern cryptographic RFID system

HID is an US company, making RFID systems. HID Prox (1991): no security. HID iClass (2002) claims (3)DES security (“one of the first to claim DES”).

“Wiegand” – a name all over RFID: Wiegand effect => Wiegand wire => Wiegand format of access control cards. Wiegand {interface, protocol}: between the door reader and security panel (=backend).

Wiegand interface: (GND, DATA0, DATA1), very widely used, especially in US. Legacy control systems have Wiegand interface input, so even new HID readers have Wiegand interface output. The interface sends simply: (8b facility ID, 16b card ID), so a MITM can replay identifiers.

HID supports other “formats” = data layouts. Advertised as a security measure: “Cards with proprietary formats are more difficult to fraudulently obtain.” HID will create a customer specific format :) [lock-in].

Card organization: blocks of 8 bytes. 2 application areas per page, application area = set of blocks. Page layout: serial #, flags, keys (not readable by app), app data. Can change space allocation for apps within page.

Access control app: 1st app. Access control ID = Wiegand ID. Security levels:

  • “Standard”: 2 keys shared across all HID readers world-wide (any card “accepted” by any reader)
  • “High”: Site-specific keys
  • “iCLASS Elite”: Like “high”, with keys stored at HID.
Customer-generated keys are discouraged – e.g. HID doesn’t sell programmers.

A configuration card can change reader’s mode to high security by loading specific keys, therefore “standard” keys are a desirable attack target.

Readers use a “security sealed” connector – with black tape. The Connector is a PIC in-system-programming connector.

It is possible to circumvent copy protection fuses: can not read data directly, but can erase a block that stores the copy protection bit and replace it with a dumper code (to get the boot loader as well, erase program and replace it with a dumper).

Extracting 3DES keys: 4 random blocks easily visible, by bytewise changes we can identify the function of the data. The keys are permuted, but documentation of the permutation exists. Access to protected HID access control is possible with the extracted keys.

Encryption is ECB without IV => can copy encrypted blocks between cards even without decrypting them.

Authentication between card and reader sniffed: There is no RNG in card, so replay attacks are possible. 4-byte authentication of each party is used. Each write is authenticated using 4 bytes. Otherwise, no message authentication-only CRCs

Security summary of “standard security”: Auth key derived only from card serial #. Verbatim copy of blocks is possible. No MAC => MITM leads to privilege escalation: do mutual auth, then fake other communication.

GSM stack on phone

GSM is not scrutinized – only 4 closed-source implementations, even handset manufacturers don’t get source. The network side is similar. “Operators are mainly banks” – outsource network {planning,deployment,servicing}, billing.

To start with handset experiment, we need at least an Xciever; we want the “air” interface fully SW-controlled.

Baseband CPU: usually an ARM with an RTOS, and a DSP (for radio signals, A5). No “modern” security features (stack protection, …). GSM components that are not generally available can be bought on grey market as surplus. Lazy approach: take an existing phone – started with TI Calypso.

Implemented L1-L3, limited UI, good PC interface. Starting with L1 on phone, L2-L3 on PC.

Firmware update done via RS232 over the audio jack connector.

Can do GSM phone calls. Can’t do: Neighbor cell measurement (=> handover), UI, GPRS, data calls.

Can modify cell response timing, this allows faking location of the phone.

Fully integrated Wireshark support available.

Also implemented logging of found cells, can triangulate cell positions; accuracy of location: 500m.

Security analysis to be done.

Reverse-engineering a real-world RFID payment card

Taipei: “Easy Card” for transportation. Uses MIFARE – this does not in itself mean the system is broken. Can buy card for cash, reload card, also take out all cash. Used to be transportation only, now a general payment system for up to €240.

We can use existing MIFARE holes to recover keys, read contents => observe effect of transactions: we can see the value is stored on card, some other changes observed: transaction log is stored on the card (the internal station code exposed as a parameter on web pages).

Tampering: retroactively increasing cost of something bought = removing money: everything works, so apparently there’s no on-line database. Decreasing cost of something bought = adding money.

“Building hardware without thinking about upgradability is negligent”

0-sized heap allocations

Microsoft research.

Problem: malloc (untrusted == 0) leads to heap overflow. Similarly malloc (untrusted + sizeof (header)). (Linux with PaX returns 0xFFFFF000 on malloc(0), which is an unmapped page, so writes result in a crash.)

Theorem-prover-based tool used to find cases where allocation may be 0-sized.

Storage analysis methods:

  • Data-flow analysis: in compiler, but hard-coded, may be too conservative, which results in false positives
  • Model checking: formal logic, searching for an invalid state. States are mode detailed, don’t lose information between paths like data-flow analysis. Easily automated, tools exists (SPIN, SLAM, BLAST, SPOT), combinatorial explosion is a problem.
  • Theorem proving – looking for a specific proof that “input conditions” guarantee a specific condition. Tool: HAVOC based on “Boogie” theorem prover, which is available open-source. A plug-in for MS C/C++ compiler is available (binary-only).

Could prove 98% of situations are safe => 100 warnings/1M LoC, which is manageable to verify manually. To reduce the size of code to analyze, we can “pull” assertions (= preconditions) to higher-level APIs.

Only handling 0-sized allocations because general buffer overflow detection is “super noisy”.


Want to keep crypto data only in chip cache – there is no real interface to get data out, CPU reset clears cache (unlike external RAM).

Caches on CPU: L1 (I/D), L2 (combined). Cache control: CR0 – cache disable, no write through (nowadays not fully supported). MTRRs, PAT control cacheability as well.

FrozenCache mode: wipe data in RAM, write data to CPU cache, so that it remains there and is not written out.

Need an L2 emulator to make sure the code+data will actually fit into cache. Interrupts need to be disabled throughout. The rest of OS is not cached, so it is really slow, should only activate this when “necessary” = when screen locked (X the various keys are in memory throughout the OS). Hooked gnome-screensaver to automatically switch into this mode.

Need to protect: keys, key schedule, intermediate data. We need hooks to register locations used to store relevant data – but we’re never really sure they are in cache. To verify this, use MSR cache statistics, or use non-existent addresses.

Messy details: It is necessary to consider cache associativity. Hyperthreading, multi-core: reserve 1 CPU, bind thread to CPU (therefore we can let others run at full speed, but there is a risk of cache snooping). Unknown impact: SMM, HW virtualization, CPU’s speculative prefetching.

Will release source code within 3 months.

Guessing cache can be used to store data of perhaps 5% of “raw” cache size.

Posted in Conferences | Leave a comment

Notes from 27th Chaos Communication Congress – day 2

Here are some notes from the second day of the 27th Chaos Communication Congress. See also day 1, day 3, day 4.

Lightning talks – day 2

  • Data Privacy Management:
  • Starfish: “Fully distributed, user-controlled network”: Not a network of star topologies, each node has redundant links; no centralized authority.
  • FreedomBox: An alternative to closed clouds: privacy control, decentralization, personal information stored at home.
  • Arduino: “An easy way to get into microcontrollers, for non-geeks”
  • Telecomix DNS: A decentralized DNS server network, an alternative to ICANN: reliability, stopping domain seizures.
  • SAP insanity: General complaints about the product: On-screen keyboard only. Column mapping GUI between tables only with arrows, with hundreds of attributes results in a mishmash of lines.
  • SMS port scan: Set up a SMS interface to a port scanner, running on the CCC GSM network.
  • TSAscreening: “You are next”, “they’re the ones being terrorists”. By law, search can be only only reasonable and necessary; you have right to record on a camera; you have right to bring medical liquids (juice!).
  • NetS-X: “A hacking game” = e-learning on net security, sandboxes for playing

I Control Your Code

The idea is to use separate identities/rights for each (user, application) pair.

The “proposal” is “user-space virtualization” to authorize all syscalls: use binary translation of all code, prevent:

  • control flow transfers to unexpected code (only to .text areas, only to known functions in inter-module transfers)
  • unexpected returns/indirect jumps (only to valid targets, shadow all stack)
  • jumps into middle of instruction
  • switching between 32-bit and 64-bit code
Therefore, all instructions are guaranteed to be validated, so we can have a policy authorizing system calls.

Also can be used to track “unmodified” execution.

Implementation: – 6-8% overhead

Policy strength / comparison with SELinux: Can enforce a list of allowed syscalls + arguments, has also a learning mode. Can add specific checks (by writing code).

Comparison with HW virtualization: overhead 3-5%, but it’s not possible to get instruction-level control.

SSL Observatory

SSL problems: Too many trusted parties; CA bugs allowed e.g. the \0 attack. We should be afraid of X.509 – too flexible, ugly, history of implementation vulnerabilities.

EFF SSL observatory: contacted all allocated IPv4 addresses. 16.2M IP addresses listening, 11.3M started SSL, 4.3M used valid certs (1.5M distinct valid leaf certs)

Found 1482 trustable CAs (incl. intermediate CAs)! – 1167 issuer strings, 651 organizations (~200 are German universities through a single intermediate). Notable cases: dept. of homeland security, US defense contractors, CNNIC (China – root CA controversy is really irrelevant), Etisalat (Dubai - installed malware on customer’s hardware), Gemini observatory

~30k servers still have Debian broken keys (out of which ~500 had valid CA signatures)

There is no general way to contact a CA (e.g. to ask them to revoke a cert).

Weirdness found: certs that both are and aren’t CAs, certs for “localhost”,

Firefox and IE cache intermediate CAs, so we can’t say for sure if a cert is valid – it may be valid only if the user has “validated” the CA by visiting a different site where the CA was signed; there are 97K such certificates.

EV certificates: Identified by (CA-specific) OID. Don’t work all that well with browser Same Origin Policy – EV to non-EV references considered “same origin”. Problems found: RFC-1918 addresses, unqualified names, weak keys, long expirations. 13 issuers violated EV spec by signing a weak key (even a 512-bit key!) Found EV certs with wildcards, also violate policy.

Data is available for download.

Plan for a decentralized SSL observatory, code in progress. Design: use Tor to send observed raw certs – may get a reply notifying about a MITM; this only works with a delay, but better than nothing.

DNSSec: no longer sure about it being a good thing, due to recent domain seizures by US.

High-speed high-security cryptography (DJB)

I’m not summarizing this- go read the slides! Relevant, inspiring, perhaps not quite practical as presented.

Data recovery techniques

The process goes through all layers of the mechanism: data acquisition (complete or partially destroyed), disk array composition, iSCSI/NAS data layout handling (iSCSI disk is a file, optionally fragmented), handling virtualization, file systems, file formats (e.g. a database), verification of the result (is the data valid?).

HW lab setup: Clean atmosphere necessary – “most of dust comes from customer’s drive”. Stereo/video microscopes used for observing head alignment. “Buy the best tools” – “no tools are better than bad tools”. Disks needed both for making a 1-1 copy to physical disk, and as spare parts – there are ~10K drive models on the market; sometimes spare parts don’t match even on the same model # (manufacturer fulfills contract to ship legacy models by shipping new model with firmware-limited capacity).

Tool examples: flash chip reader, “head lifter” (custom), a tool to extract the platter out of the bearing, a press to put the platter onto a spindle.

Data acquisition from a disk: spinning the disk – in its shell or a replaced shell; can’t get data without spinning the drive in <1 month => impractical. Used to use a “spin stand” – today it is almost impossible to align the platter correctly. As a last resort: magnetic microscope – can handle broken platters, but reading a single surface takes ~5 years.

Data acquisition from flash: PCB damage: can be fixed, but rare; otherwise desolder chip, read it, reorder blocks.

Kinds of damage for disks: surface damage; bent spindle (=> stuck); defective heads (stuck to surface); electronic failures; firmware corruption; media contamination (e.g. bearing fluid); fire; water. Hard drives are not sealed/devacuated – there are little holes to even out pressure, so water can get in. Fire damage is normally not hot enough to damage magnetic data. For flash it is about the same, except for physical damage.

Drive heads: with >1 head, only 1 activated/pre-amplified at a time. Some firmware just fails, if other head is on an unexpected position => need to align heads correctly to each other.

Validating recorded files: replace unread blocks with a pattern (which includes some metadata) => can check if a recovered file has been damaged, can focus on priority missing data.

Fun with firmware: There is a separate HW connector – on Seagate serial I/O, 3.3V, only starts talking after Ctrl-Z. HD commands are family-specific.

Best way to kill a drive for sure: “really difficult”. In most cases overwriting data 1x is OK – overwriting multiple times doesn’t help. LBA and physical addresses aren’t 1-1, so one never knows if the data was actually overwritten.

HW firmware implementation: standard CPUs, ARM is popular. Reverse engineering: the firmware contains several megabytes of code and data, most firmware is actually loaded from the media!

Backdooring embedded controllers:

Exitsting laptop backdoors: hardware (keyloggers etc.), software (OS), BIOS, ACPI; Firmware, other devices – will ONLY cover the EC here.

EC = Embedded Controller: 8- or 16-bit MCU, “beefed up 8042 keyboard controller”, “Renases” on ThinkPads. Controls sensors, actuators (temperature, battery, fans, brightness, LEDs). Handles hotkeys (VGA output, brightness control) => needs key press data. (MacBook has an USB keyboard => different architecture).

Focus: ThinkPad’s “Renases”: Based on H8S, running when laptop has power (even when “off”). BIOS and EC can be flashed via LAN! Some laptops have it enabled by default!

Easy to work with: Commented disassembly for T43 already exists: The author of the patch to swap Fn and Ctrl allegedly never had Lenovo hardware.

The implemented backdoor can record and provide keystroke data – 4kB space available, 5:1 compression => 20K keystrokes. To get data out, can use ACPI results, or use a LED wire as an antenna. To send data remotely: can use a covert timing channel (manipulating keystroke timing).

Defense: Dump EC firmware (reliable – implemented through HW, malicious firmware can not tamper), then we can verify it. Plan to use to see if it is a known version (but what about trust, i.e. an attacker submitting a hacked version?).

Future plans: Examine other reflashable devices. “Would like to see” vendors signing firmware, verifying it on boot (TPM enabled probably can’t [currently] detect this). We need “fundamental discussion” about firmware trust.

Dumping firmware is done via a protocol over ports 60/61. The original firmware was found in a DOS version of BIOS updates, *.FLZ contains both BIOS and EC firmware. Tools used: GNU binutils, a checksum recomputation tool.

Posted in Conferences | Leave a comment

Notes from 27th Chaos Communication Congress – day 1

Here are some notes from the first day of the 27th Chaos Communication Congress. See also day 2, day 3, day 4.


5 years ago speaker said at CCC “we have lost the war”: a perfect storm: post-9/11 paranoia, EU data retention, climate change. As of today, war not actually lost: German constitutional court started protecting privacy - OTOH Netherlands has a constitution, but not a court, so the majority can ignore constitution => fearmongering and other aspects of usual politics; Netherlands has now become an cautionary tale WRT privacy.

Political recommendations: watch party funding, “literally by all means defend the constitution”.

Speaker “mildly bipolar”, was recommended anti-depressants – “being unhappy has become socially unacceptable”. If depression is a force that pushes us to make painful but necessary changes, antidepressants prevent necessary change – perhaps there might be a political-pharmaceutical complex one day?

Success on voting machines: Illegal in both Germany and Netherlands (Germany “safe” – constitutional court, in Netherlands will need to fight this war over and over again with each single mayor) E-voting in Brazil: black box, gets an ID card from each voter – future versions will event collect a fingerprint.

Wikileaks: Speaker did not participate in the latest release, “possible ramifications scared the bejezus out of me”, “I can’t live from a backpack”. Important, but outcome is uncertain: “Not sure what has been unleashed” - attacks on Internet freedom will certainly increase. US proposes to be able to get plaintext from any service – “Crypto war 2.0 starting”. “Anonymous is getting on my nerves” – “real hackers would not release real names in PDF metadata”, lacking a “level of maturity” – “we” [at CCC] might attack, but nothing good comes out of it.

Politicians don’t know what’s going on, can’t control it, can only pretend they are in control for the voters. “Hackers don’t have the answers”, but understand the dangers of complexity – “lack of slack”; “CCC does not cause chaos – we have prevented some aspects, and we understand chaos a little”.

Living in a world of separate viewpoints/narratives, from “Apple, Google, Facebook and the geographically-challenged traditional governments”

Future: Basic story remains – we lost the war. “It’s going to be a mess”: “difficult times, not end times” – build trust relationships, diverse skill sets, be flexible.

CCC logistics: too many of us, need to move out to be able to attract new people. DEFCON given as a counterexample for expansion, probably does not apply here – CCC never had their problems..

Code deobfuscation by optimization

An IDA plugin to decode/simplify semantics on an obfuscated code, optionally “assemble” into a new code segment for further processing in IDA.

Handling obfuscation: Small basic blocks, “push+return” to break IDA graphing are simplified/converted. Fake paths (conditional jumps to nonsensical bytes) are simplified. Overlapping instructions are duplicated.

Implementation: Build a CFG. For instruction semantics, use “MazeGen’s XML at” to track all inputs/outputs. Optimizations performed: JMP threading, conditional jump simplification, dead code removal, various heuristics, e.g. push+ret->jmp. Constant propagation/folding unimplemented.

Contemporary Profiling of Web Users

Research on defeating web proxies / anonymizers / Tor. etc. “In private communication research, dummy traffic was researched in the last 20 years and has never been a solution”

Proxies that remove JavaScript:

We want to limit JS: it can e.g. get screen size, local date (=>clock offset and drift). Existing proxy projects are dead.

The proxies 1) remove <script> 2) move content out of <noscript>, both using regular expressions. PHProxy attack: <noscript><scr</noscript>ipt> . Glype: same attack on <object> . Also, Java can load JS as well: ...showDocument(..."javascript:..."...) .

When JavaScript is enabled, but filtered: When DOM modification are used to hide objects, it is usually possible access the originals. NoScript can forbid 3rd party JS for tracking, but code can still load 3rd party CSS. Another specific problem is filtering <object archive=...>, but not <object><param name=archive .../> .

Identifying users by web profile

Assuming an anonymizer, or watching users on a DNS server. Identifying the user is easy with static IP; dynamic IP “should” protect (changing IP address on DSL, or Tor changing the routing each 10 minutes).

Using standard machine learning using mechanisms for word frequencies to learn on host access frequencies, using a “multinomial naive Bayes classifier”. In experiment, successfully identified 77% of “links” (user on day D => user on day D+1). Accuracy is good even with 10-minute sessions (i.e Tor). Longer time between learning and classification doesn’t hurt much.

Recommendations: Change IP address frequently and do not continue previous activities after the change. Use separate proxies for each activity. Randomly distributing activity across multiple proxies does not help – each proxy has similar data. Visiting only popular pages does not help much.

Detection of bots and other strange users

Motivation: heavy load by bots, proprietary databases crawled by competitors.

  • If load balancing: make it deterministic (e.g. md5 of client’s IP), look for “incorrectly” connecting users. This is trivial, but actually works - many bots are lazy and just connect to host 0.
  • Observe behavior: client that does not access images/JS, connects too often.
  • User-Agent: Fake user agents are often too old (IE 5.5). HTTP header characteristics (order/capitalization) allow quite specific user-agent detection, allow detection of faked User-Agents. These techniques are both easier to do “after” load balancing proxies because the proxies will defragment the input, making evasion more difficult.

Local attacks on Tor

“Local” = connection between client and Tor entry node. Attempting web site fingerprinting using traffic analysis only (timing, packet sizes), want to see if a specified site was visited. Timing information is mostly useless due to Tor’s load and circuit changes; Tor “should” protect against size fingerprinting dues to fixed-size cells.

Machine learning again: Need to train this with each browser separately, and extract separate requests (not mixed with unrelated sites). Using “Multinomial naive Bayes”, “Support Vector Matrices”, training on packet sizes and direction, “ignoring ACKs” = counting the total size of a transfer in one direction until the direction changes.

Detection accuracy when training against “all possible sites” is >95% on OpenSSH,OpenVPN, IPec. Tor started with 3%, can now get 55% => feasible. “Jap”: interestingly the problem is more difficult on the free version than on the premium one.

Detection when distinguishing between a few “interesting” sites and “rest of Internet”: training with a representative sample for “rest”. With 5 “interesting” sites need ~2000 samples for <1% false positives, will get 67% false negatives.

Recommendations: Do multiple things at the same time (tabs, Internet radio…) – decreases success to ~10%.

Automatic identification of crypto primitives in software

A master thesis, limitations: Assumes no obfuscation, no JIT/interpretation, only limited to crypto (nothing else, and not block cipher mode).

Existing tools: signature based, or dynamic instrumentation measuring percentage of “bitwise” operations (globally / in a basis block / function), looking for loops that change entropy

Implementation: Intel’s PIN for dynamic instrumentation to get insn-level execution trace. Then reconstructs CFG (“dynamic” = including indirect jumps), jump taken/not taken statistics, detects loops, memory ranges/areas.

Algorithm identification methods:

  • Excessive use of bitwise instructions.
  • Sequences of (instruction mnemonics, constant operand) pairs, find fingerprints – e.g. combinations unique for an implementation.
  • Loops (X often unrolled): observe (number of executions of the loop as a whole, number of iterations, number of instructions in a loop).
  • Look for a specific relation (e.g. AES (input, key, output)) between blocks of data with a suitable size


A generic introduction to USB – releases, limitations, transfer types, endpoints, descriptors, usage of libusb on various OSs.

Desktop on Linux

From a PoV of an UNIX sysadmin… It seems difficult to keep up with the technology changes. Presentation overshadowed with explanations by Lennart Poettering.

Distributions focusing on “Dumbest Assumable User”, few sysadmin controls available/visible.

MM frameworks: too many layers (=> loses relevant information on the way with Phonon+GStreamer+PulseAudio). GStreamer backend to Phonon unmaintained, still used by default in “some distributions”

GDM: complicated – why do we need a full GNOME session? (Answer: a11y pulls audio, which pulls bluetooth, …; g-p-m necessary for default power policy). GDM doesn’t handle systems with many users well; Can’t show all 3.5k names in any case. When that is disabled, still shows recent users and “Other” – users mistake login screen for a screen lock.

ConsoleKit: Sorry state of documentation: “Defining the problem: To be written” after all these years. Intended to manage separate seats, but ACL changes illusory without revoke(). Not robust – changes persistently-stored ACLs but keeps only in-process state => ConsoleKit crash leaves around obsolete ACLs.

D-Bus complaits: Nonsensical name spacing (“you need a domain”, “narcissistic naming: based on project name, doesn’t tell what it actually does). Would like implementation-independent interfaces [X where to get the implementations?]. TCP transport: “no authentication, no authorization, no encryption”. (Lennart: ['we' agreed that] “D-Bus won’t be used across the network full stop”)


Many “old” vulnerabilities were carried forward from IPv4, previously presented:

  • Neighbor discovery spoofing < -> ARP spoofing
  • Duplicate address detection DoS [answer "this is a duplicate" to everything]
  • Rogue autoconfiguration server < -> rogue DHCP server

Routerless networks: Sending a router advertisement with 0 lifetime “kills” the router for clients. Per RFCs clients treat any address as link-local if no router exists.

Unexpected RA on an IPv4-only network: switches on dual stacks. Thus we can bypass IPv4-only firewalls, can MITM on IPv6 because IPv6 transport is preferred to IPv4.

RA flooding: 1m bogus RAs DoSes Cisco, Windows, old Linux (100% cpu).

Remote ping scans: Originally thought infeasible due to large address space, broadcast doesn’t exist. But we can still use search engines, DNS, common addresses. Randomly chose 17k DNS names. The following “host address” (= host part within network) sources exist:

  • Autoconfiguration: either link-local = based on MAC (can guess if you know the (company standard) manufacturer), or “Privacy option” = random and changing from time to time
  • DHCP: allocated sequentially! => “if you got one, you got all”; common ranges based on example documentation
  • Manually configured: ::1, ::2, …, or ::service_port, IPv4 address, and simple variants of these.
Overall, can easily guess ~70% of host addresses. A scan only needs to try ~2100 host addresses (1-20 seconds) to get 70-80% of hosts, similarly try ~1500 common host names. A scan may return a router’s “not available” message for a different network, giving us more targets. We can iterate between guessing hosts on a network, and using reverse DNS to get more starting points. Altogether we can identify~90-95% of servers (not counting other kinds of hosts).

Multicast DoS: Multicast background: A “query” router periodically prompts for confirmation of existence of multicast receivers. We can spoof “unsubscribing” message, but this will cause another prompt and resumption of traffic. If we become the “query” router, we can avoid sending the prompt. “Query” is voted by local link address => 0000000 wins [nobody configures a router on 0]. Then we can unsubscribe the network, except that other routers would assume the router is dead if no prompts were seen. To avoid this, send the prompts – but only to a “router-only” multicast MAC.

To see if a Windows/Linux computer is sniffing the network: Send a packet (ping) to an unused multicast address, see if the host responds.

Side channels in IPv6: “IPv6 is a side channel” – too much functionality, cannot be reasonably filtered

Code available at . Will start www.ipv6{security,hacking}.info for secure configuration advice.


  • ACLs on L3 switch (e.g. don’t allow RAs from client ports), if supported
  • IPSec, but a pain
  • Secure Encrypted neighbor Discovery – basically happening in the switches, not supported yet anywhere, still has problems.
  • More secure client configuration – not always possible
  • Detection of attacks is easy, prevention unknown

Analyzing Stuxnet

Presented by Microsoft “to set the facts straight”. Analyzed within a few weeks after this came in, but not allowed to talk about it at the time. 2 interesting things: 4 0-day vulnerabilities, attack on SCADA.

Discovered: by VirusBlokAda (Belarus, not known by Microsoft) sent a sample in ~July, eventually got the original LNK files. Others are looking at this as well – need to “know ahead” about threats, ~1 MB of binary; full knowledge sharing with Kaspersky.

Methodology: “initial triage” – identify surprising code, clues for vulnerabilities, then discuss details with developers of relevant code. Total time ~30-40 man-hours in 3-4 days to find the vulnerabilities. Later completely decompiled 2 components to buildable C.

Attackers: “Don’t ask me who the author was”. Components were written by different people. Aiming for 100% reliability, high impact. Developed on removable media (path embedded in file is B:…). Shell code does not use simple “call” insns – always “ret”.

Attack 1: LNK files

Dumped LNK as text, identified the buggy DLL; all done in ~1 hour. Bug: .CPL has icons inside => must do LoadLibrary(), which calls DllMain(). Fix: limit icon loading to only registered .CPLs.

Impact: Arbitrary code execution without privilege escalation – only a foothold for further attacks. Looked at attack vectors – in addition to USB, could use WebDAV (remote attack) => fixed it “out of band”, “telemetry” told them users were being affected. 100% reliable attack vector. Apparently some people knew about this for years.

Attack 2: Task scheduler

Debugging was not really helpful => using process monitor, event logs - noticed that task files were accessed. Bug: XML file storing task data (including the user to run it as => can escalate to LocalSystem) writable by user, authenticated using a CRC32 hash (which was protected against user access); CRC32 collisions are easy. Fix: use SHA256 (kept files writable “for compatibility” [with what??? the authentication would break writing anyway])

100% reliable – but only works on >= Vista.

Attack 3: Keyboard Layout

Eventually found “not immediately obvious” code – searching in win32k.sys, NtVirtualAllocateMem, keyboard layout loading, some IDA-unidentified code. Tried various things, finally noticed the code looks like a shell code and inserted a break point in it to get a back trace. Bug: <=XP allowed loading keyboard layouts from any directory, indexed a function array using an unvalidated user-controlled integer. Attack looked for a suitable user-land address following the original table, copied attack code there.

100% reliable – only <= XP, so we can assume the attacked environment is not monolithic.

Attack 4: Printer spooler

Kaspersky reported suspicious spooler RPC. Network trace: guest printing to files in %system%. Spooler should have switched to the client account, but it doesn’t for Guest because it is too limited, so it uses System instead. Windows by design automatically runs a .MOF file dropped in there :)

This all only works if anonymous connections are allowed, which is very uncommon in corporations

Posted in Conferences | Leave a comment