day 1, day 3, day 4.
Lightning talks - day 2
- Data Privacy Management: http://www.daprim.de/
- Starfish: http://www.kemenczy.at/ "Fully distributed, user-controlled
network": Not a network of star topologies, each node has redundant links;
no centralized authority. - FreedomBox: http://wiki.debian.org/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: http://gitorious.org/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: http://bit.ly/tsarights
"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: http://code.google.com/p/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: http://nebelwelt.net/projects/fastbt/ - 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
http://www.eff.org/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",
127.0.0.1.
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:
ec.gnost.info/ec-18s/ 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
coderpunks.org/ecdumper 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.
No comments:
Post a Comment