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.

DNSSEC:

• 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 2ⁿ 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?] http://emboss.github.com/blog. 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". https://131002.net/siphash/
  
  
  
  • 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: ~2¹²⁸ key recovery, ~2¹⁹² state recovery, ~2¹²⁸ "internal-collision forgery". With ~2^s effort probability of forgery 2^s-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.

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; www.abenteuerland.at/smrender/
  
• 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 (https://www.torproject.org/volunteer). 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 compass.torproject.org: 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."
  

FactHacks

Various loosely connected topics regarding RSA factorization. See also http://facthacks.cr.yp.to/.

• "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 >2⁵⁰² primes between 2⁵¹¹ and 2⁵¹² => 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 ~2⁴⁷ 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) => https://factorable.net/: 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 ~2⁸⁰ operations (using number field sieve) [whatever "operation" means]. This already feasible for botnets and large organizations! It is estimated that scanning ~2⁷⁰ 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 => ~2¹⁹ typical CPUs, i.e. 2⁸⁴ floating-point multiplications/year).
  
  
  
  
• Factoring via Google: "BEGIN RSA PRIVATE KEY" site:pastebin.com (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 factorable.net, 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
  

Conclusions:

• 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 km^2>); non-city areas even larger, seen 1000 km². => 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.

Countermeasures:

• 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.

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
  

Overview:

• 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.

Privacy:

• 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).

Security:

• 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.

Protocols:

• 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.

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.

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.

Outline

• 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?
    
  
  

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.

PDF

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
  http://stapbofh.krunch.be/
  
• "Hacking governments" - Talk proof of concept: graphing relationship structure of relevant people?
  
• UAVP-NG: UAV ("quadcopter") PCBs + software, GPLv3: http://ng.uavp.ch/
  
• Privacy: "transparency is more difficult than having things in the open"
  
• http://incubator.apache.org/clerezza/: "Semantic web" linking social
  networks
  
• bblfish.net = 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.

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:...@192.168.1.2, 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).

Countermeasures:

• 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.

http://fail0verflow.com/

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.

http://www.openpcd.org/HID_iClass-demystified

GSM stack on phone

http://bb.osmocom.org/

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".

FrozenCache

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.