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 onmalloc(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.
No comments:
Post a Comment