DefCon 22 presentation notes

Aug 20, 2014

Behind the cut are the notes I took during DefCon 22, organized by name of presentation. Where appropriate I've linked to the precis of the talk. I make no guarantee that they make sense to anybody but me. One Man Shop: Building an Effective Security Program All By Yourself - Medic

  • Integrate with environment
  • Continuous monitoring
  • People and Process -> Secure Network Architecture -> Secure Systems Design -> Continuous Monitoring -> External Validation -> Compliance
  • Compliance, per usual, means dick in the final analysis
  • Roughly five year plan w/ deliverables
  • Needs organizational supprt. Still answers to the Business.
  • Supports, !replaces Business
  • Security will not mature past the business' maturity level
  • Be realistic about what you want to achieve
  • Schedule time for firefighting
  • Develop little plans, achieve each, build on top of them
  • Be realistic. You're probably not one of China's targets.
  • Security through simplicity. Easy to verify and audit.
  • ID existing processes. Improve with security.
  • Ad-hoc environment == ad-hoc security programme
  • Match people to roles and tasks. What and how are things done? Negotiate ownership of systems and processes. Who does what?
  • RACI matrix
  • Set and communicate expectations on all sides
  • The Business is the hook for everything
  • Be realistic. Don't use FUD or scare tactics.
  • Recruit help. Communicate plans.
  • Make the SA the liason. Find out what they do. Make a checklist. Insert security protocols into that list. Automate provisioning where you can.
  • Workstations get secured by attrition - part of the hardware refresh lifecycle.
  • Identify and use hand-offs of tasks.
  • Swim lane flowcharts
  • Identify where security fits in best
  • Identify mitigation strategies
  • Know your environment. If you don't, do it. Nmap. Netviz. Something!
  • Nmap results -> Nessus -> Visualization
  • Zenmap will make visual network maps for you
  • ID endpoints and uses
  • Categorize users by what they do. Use that to ID sensitive data, architect networks appropriately.
  • Perl script -> Nmap output diff
  • Centralize sensitive services
  • Network segmentation works. Use it.
  • Go outside in to establish a perimeter.
  • Group endpoints based on roles, risks, exposures, trust levels. Do it somehow.
  • Requires knowing what you have. Get organized!
  • Build security zones around those groups.
  • If systems don't need to talk, isolate them.
  • For each zone, what risks do each face?
  • Deny by default. DPI the rest.
  • Log everything you can't DPI.
  • Normal operation comes first.
  • Exceptions should be documented and approved.
  • Internal firewalls. Protocol enforcement. ID/PS. Netflows. DPI. File extraction and analysis.
  • Netflows -> traffic patterns. ID anomalies.
  • File extraction: IDs executables on the wire, write to disk, scan and examine.
  • Central logging
  • Figure out how to re-organize everything
  • Migrate everything into appropriate zones
  • Build all new stuff in secure environments
  • Cross as few security zones as necessary.
  • Host based firewalls work. Use them.
  • "If you can't talk to it, you can't hack it."
  • Back everything up. Snapshot VMs.
  • Automate account provisioning.
  • If you can do SSO, do it.
  • Disable once, disable everywhere.
  • Standard desktop image. Least privilege. NO LOCAL ADMINS! Centralized administration. Enable automatic updates; OS killing patches are rare.
  • Microsoft WSUS is free. Use it. It lets you patch by groups for testing. Test before rollout. Can also roll patches back. AV is better than nothing; use it anyway.
  • Use EMET for additional defense. Hardens apps by injecting itself into the memory field.
  • MAC filtering at the switch.
  • Nmap portscan -> Nessus -> Daily reports.
  • MBSA on Windows boxen
  • Automated log review. What and who comes from where?
  • Log and analyze dropped packets. Means stuff is talking to things that they shouldn't.
  • Event logs from privileged accounts
  • Snort with ETpro rules
  • URLsnarf from Dsniff
  • TCPdump spanning ports - grab DNS traffic. ID sketchy boxen by what they're trying to look up.
  • execap
  • WMIc for remote incident response
  • When you get bored, introduce a new monitoring tool and see what shakes out
  • SANS Top 20

Measuring the IQ of your Threat Intelligence feeds - Alex Pinto and Kyle Maxwell

  • Something about hacker spirit animals
  • Threat Intelligence 102
  • Data preparation and testing
  • Tools: COMBINE, TIQ-Test
  • Capability and intent. What are they able to do? What are they planning to do?
  • Not IPs or hashes
  • What are they doing right now?
  • Signatures vs indicators. Don't use the latter as the former.
  • Signatures - signs that something is happening right now
  • Indicators - Less confidence, no proof, no blocking
  • Data vs intel. Data needs context. Add intent, capability.
  • Tactical vs strategic.
  • Tactical - Now and what?
  • Strategic - Continuum. Who and why?
  • What type of intel?
  • Atomic vs composite
  • Atomic - IP, hash
  • Composite - Pulling together data points
  • TTPs - Tactics, Techniques, Procedures. How They do what They've been doing. (modus operandi?)
  • IPs have roughly the same value as hostnames. Finite resource. Managed and controlled because they're issued. Has an intrinsic cost. Some providers play close attention, others don't care.
  • Ultimately, who's after YOU?
  • Can we measure how much an intel feed ultimately helps us?
  • The TIQ-tools implement these tests
  • Statistical analysis suite, uses R.
  • IPs, hostnames, structured data
  • Inbound and outbound traffic flows
  • Scanning, spam. Connecting to C&C, links to droppers.
  • IP -> hostname(s) more interesting
  • Passive DNS from Foresight Security's DNSDB
  • Partition RFC-1918 addresses out
  • AS name and number for IPs - Maxmind ASN DB + country from Geolite DB + RHOST from PTR record
  • Maps are NOT a good way of representing data. Bigger countries look more threatening. The way the brain works, bigger anything always looks more threatening.
  • Novelty - how often do they update or change?
  • Overlap - how do they compare to what data you already have?
  • Compare everything to everything to seee what's happening. Compare to commercial feeds.
  • Can data actually teach us about foes? Do patterns actually exist?
  • You need to reach your own conclusions which fit what you're actually doing
  • Novelty test - add and drop indicators?
  • Data from honeypots is a good start
  • Updates which are hourly or daily are probably from automated sources. Weekly updates are probably human curated. Hourly updated human curated feeds are probably optimal (you'll probably pay through the nose for that kind of access)
  • Overlap - more data is better but avoid unnecessary duplication of data points
  • Identical data points in different feeds can be a sign of quality because they're all seeing the same thing
  • Outbound traffic has significantly less overlap. For specific hunting of $foo. Tracking internal activity.
  • Population testing. What parts of the Net are hitting you? Where is exfiltrated data going?
  • Tailor for specific ASes/countries that fit your data
  • Filter out the stuff that you don't have - ancient Joomla installs, stuff like that
  • Number of IPs vs proportion of IPs/country
  • Exact binomial tests
  • Chi-squared proportion tests
  • Be conservative with P-values
  • https://github.com/mlsecproject/combine
  • Harvesting and processing threat feeds
  • reaper -> thresher -> winnower -> baler
  • Can input JSON, CSV, HTML, text as feeds
  • Analyze your data and extract value from it

The NSA Playset: RF Retroreflectors - Michael Ossmann

  • Hardware and software attack tools
  • Building our own toys
  • Tiny implant that modulates an incoming signal and reflects it. Picked up and demodulated into data.
  • "illumination"
  • Very small device, very low power. No battery. Remotely powered.
  • No reverse engineering done. Recreated from knowledge of physics, radio theory, electrical engineering. "Forward engineering," cloning.
  • Research capabilities by the open security community
  • Emission security. Passive techniques welll known. Active techniques much less so.
  • TEMPEST was the earliest and publically the first. (Van Eck phreaking, Wim Van Eck's original paper)
  • RF. Thermal. Conducted electical interference. Accoustic.
  • (illegible) Kuhn. Read his stuff. (Anybody know so I can fix this?)
  • Classic example: The Thing designed by Leon Theremin. The Great Seal of the United States of America in the US Embassy in Moscow during the Cold War, discovered as a bug in the 1960's.
  • A condenser mic. An antenna. That's all it was.
  • Sound modulated the output of the condenser mic by altering its impedance
  • Illuminate the Seal with RF (GHz range, probably), listen for the return signal
  • It'd been there since the 1940's, they think
  • 53 years of rumor and speculation (1960-2013)
  • So little data, few experiments. We're a decade behind.
  • PoC or GTFO
  • Brief mention in Kuhn and Anderson's paper: Keyboard cable illuminated, keypresses returned. Mentioned once, referenced a declassified German paper.
  • Presumably keyboard was unmodified, i.e., no implant involved
  • Not enough information to reproduce
  • VGA video implant, "enhanced return"
  • See GBPPR's experiments on Youtube
  • Unintentional RR - design flaws
  • Intentional RR - implant
  • Intentional illumination
  • Unintentional illumination - harmonics, cellular comms, 50/60Hz hum... interference
  • Very small omnidirectional antennae in implant
  • More directional variants are certainly possible
  • RF backscatter communication. Harry Stockman's paper.
  • Most in the UHF band
  • UHF and RFID tags are very similar
  • Police radar > 20GHz, an order of magnatude too high
  • Can be acquired on eBay
  • Hot Wheels Radar Gun - 10GHz, closer to what the implants actually use
  • The microcontroller on the Hot Wheels Radar Gun usually fails but you don't need it. Take the unit apart, remove the circuit board at the back where the hammer of a gun would be.
  • Three wires. Power goes into two of them, the RF signal travels on the third.
  • Arduino radar, cheap, around 10.5 GHz. Still pretty high.
  • Coffee can radar, baseband capture w/ sound card
  • FM CW radar (this is what's actually used)
  • HackRF One - open source SDR
  • Can (officially) operate between 10 MHz and 5 GHz
  • Base bandwidth is 20 MHz, 3 orders of magnatude greater than that of a sound card
  • Half duplex, two units needed (one to send, one to receive), each with a directional antenna
  • 2.482 GHz - top of the ISM band
  • The implants operate between 1 GHz and 4 GHz
  • Prototype - CONGAFLOCK - kinda huge
  • MOSFET (source). Resistors are mostly optional. Testing. 10k resistor protects MOSFET's gate, also optional.
  • target <-> antenna <-> MOSFET
  • Data switches antenna on and off, modulates external signal
  • Two antenna wires, about one inch long
  • Can build one in the RF Village
  • FLAMENCOFLOCK - test type - taps PS/2 keyboards, picks up keys pressed and emits them
  • Tap clock or data line. Both work, but the data line is exactly what you need.
  • AM demodulation on the receiver
  • Aiming the antennae precisely is essential
  • TANGOFLOCK - USB interceptor - low speed devices
  • SALSAFLOCK - VGA signal interceptor
  • Vertical sync and modulation, probably works
  • Lower resolution is easier, need high speed sampler
  • Countermeasures - not much
  • We don't know enough yet
  • Better validate our kit to see how it acts
  • Figure out how to detect illumination
  • Are implants actuallly needed for (at least some of) these attacks?
  • Designs on Github
  • DO LOWER POWER EXPERIMENTS.
  • http://www.nsaplayset.org/
  • http://greatscottgadgets.com/

Hacking US (and UK, Australia, France, etc.) traffic control systems - Cesar Cerrudo

  • Highways -> poles, traffic lights -> weird devices, cameras
  • Wireless traffic detecction systems: London, countries pretty much all over the world
  • Commercially available
  • DC alone has 1300+ wireless sensors
  • Sensors go in roadtop. Miniature magnetometers. Detect disruption of magnetic fields by cars.
  • 3 year battery life
  • Top is a flat plate antenna
  • PCB - transceiver, microcontroller
  • Batteries, chassis
  • Access Point - white box on pole next to lights
  • Collects sensor data, relays into traffic control system
  • Runs embedded variant of Linux
  • Repeaters - bigger white boxes
  • Two channels - sensors in, relays out
  • Range: 150 feet without repeaters, 1000 feet with repeaters
  • Traffic control systems use sensor data to modulate stoplight timing and regulate vehicle flow
  • Can uniquely identify cars by correlating sensor data
  • Windows app to develop and write configs into APs
  • Configure sensors through APs
  • Server side software concentrates and analyzes sensor data from the entire network
  • Can remotely control any AP
  • Traffic isn't encrypted. Surprise, surprise.
  • The vendor lied. Surprise again.
  • Communications aren't authenticated. Nothing prevents attackers from accessing the sensor network.
  • APs don't authenticate sensors or repeaters
  • Firmware images aren't signed or authenticated
  • IEEE 802.15.4 PHY
  • 2.4 GHz band x16 channels
  • Low data rate
  • TDMA, 64 slots
  • Anybody can send data to the AP and it'll accept it
  • Sensors actively avoid collisions
  • APs ACK traffic
  • Packet format in bytes: [packet type x2][sequence number x1][hardware address x2][data...]
  • APs do not have specific addresses
  • 4-50 byte packets
  • Types of traffic: Battery level, firmware revision, synch data, config data, firmware updates
  • Firmware image is a proprietary format. Reverse engineered.
  • Microcontroller manufactured by Texas Instruments, development kit downloaded from their website
  • Use USB SDRs to sniff traffic in realtime
  • Field tests successfully carried out in Las Angeles, Seattle, and Washington DC
  • Can reconfigure sensors, send arbitrary packets into the network and be accepted alongside actual sensor traffic, fake vehicular traffic, monitor traffic in realtime, can even plot data on Google Streetview
  • PoC available (though I haven't had time to find it yet)
  • SenSys Traffic DoT Software

Saving Cyberspace by Reinventing File Sharing - Eijah

  • DemonSaw
  • ...walked in late...
  • Redefining authentication
  • Authentication that can be redefined
  • Stateless authentication
  • Social networks have immense data that can be leveraged
  • Modular security leads to layered security
  • Obfuscated, disjoint separation of duties
  • Plausible deniability
  • Leverage existing protocols to build on top of
  • Blend in with other traffic. Interoperable. Keep a low profile.
  • Need a more flexible and adaptable model. Simple and effective are essential. Run on as many things as possible. Portable, OS-agnostic.
  • No fixed servers, no direct peer to peer
  • DemonSaw - your files, your way
  • Three components of file sharing: Client / router / server
  • Network routing, traffic patterns
  • Separates those functions - compartmentalization
  • Windows based router app
  • Client only: Share, search, browser, transfer
  • Router: .NET app, drop into a hosting provider that supports .NET v4.5
  • Secret groups defined by AES key generated from a shared secret. Like a certain picture from a certain party that only everyone in the group has. Everybody who has it is in the group.
  • Change the shared key and bounce everybody who doesn't have it
  • No revocation
  • Global/Default Group - no image used to generate key
  • IPs aren't revealed. Traffic is opaque.
  • Routes and servers can change often
  • Multiply encrypted. Stateless.
  • No logging, registration, or data retention
  • Messages and content are separated
  • Uses HTTP - much harder to filter
  • Proxy aware

Practical Aerial Hacking & Surveillance - Glenn Wilkinson

  • Drones and suchlike.
  • UAVs, toy copters
  • Surveillance, data interception with hardware on board the UAV
  • Beyond radio or video horizons - too far away to see or hear
  • Low visibility - > 300 feet up, you're just not going to see it
  • Multifunction sensor package
  • Semi-autonomous UAVs have greater range
  • Can spy over entire cities
  • Aerial platform
  • Ground control/automation
  • Hacking/surveillance payload
  • Form factor? Mass? Power required? Transmission bandwidth?
  • Multi-rotor or fixed wing?
  • Semi-autonomous drones have greater range because they can go beyond C&C transmission distance
  • 3 >= number of rotors <= 8
  • How much lift is required? Maximum flight time? Mass budget?
  • Flight controller - CPU. Arduino? Cortex A-something?
  • Sensor package aids in piloting
  • CPU can automatically compensate for environmental conditions
  • Cameras - high resolution, long/short range
  • GPS
  • Aids in retrieval!!!!
  • Fixed wing drones have better range, they burn less power
  • Four rrotors, 40 cm diameter seems to be a sweet spot
  • Arducopter. ADM. Open Pilot. KK Board. NAZE32.
  • You can't debug firmware at 300 feet
  • http://flyawayclub.com/
  • Cameras. Sony GoPro. Chipcam for first-person view through the drone. Live video feed throuh goggles. HUD.
  • Can lock drone's position to current GPS coordinates. Can do breadcrumb navigation to return to earlier waypoints.
  • Some are GSM enabled so you can SMS/MMS rescue information
  • 5000 mAh power cell
  • Tailor power cell to system specs
  • 1 W transmitter ~~ 6 mile range
  • Automatic flight software. Tablet -> radio -> UAV
  • https://www.dronedeploy.com/
  • http://www.qgroundcontrol.org/
  • Payload - hacking kit
  • Snoopy: A distributed tracking and profiling framework
  • Runs on any device you can run Linux on
  • Fixed or mobile units, multiple sensors scattered around a geographic area
  • Sends data back to a server for correlation and analysis
  • Detection. Surveillance. Wireless gear. Cellular. Data drill-down.
  • Hooked into flight controller
  • Hooks into https://wigle.net/
  • DTF - Digital Terrestrial Footprint. All of the wireless data you leak just walking around.
  • Sample, aggregate, use to build a profile
  • Everyone has a unique collection of wireless devices which are fingerprintable
  • (badass demo here - welcome to the future!)
  • OpenCV for image recognition
  • Drop "de-authentication bombs" to force wireless devices to deassociate, reassociate, capture handshakes to crack WPA protected wireless networks
  • Maltego to visualize and explore data

Secure Random by Default - Dan Kaminsky

  • RNG's keep getting things pwned
  • Persistence of bad data on drives
  • Evverything in a box has general purpose CPUs in it. And they all trust each other.
  • Hard drive == computer with direct memory access to another computer
  • S^X - Storage XOR Execution
  • Hackers are willing to work from first principles
  • The best thing hackers break is assumptions.
  • Many things require unpredictable numbers
  • They may not be strong. Or strong generators. But how do we know?
  • @reversity - WPS attack
  • You want random secret keys. Means that you can predict the keys ahead of time and try them.
  • Disconnect between how we get pwned, and what we actually talk about.
  • Only two problems: No entropy at all, using crappy generators which aren't actually random (LFSR)
  • Take a few bits, generate billions of values that have nothing in common at all
  • You actually need all the bits you say you need
  • Kernel RNG's seed from hardware events
  • Remember, there are lots of CPUs in your average computer
  • Ultimately, entropy gathering means you're measuring slow systems with much faster systems
  • The scale differential means a lot of inaccuracy. That's the entropy.
  • It doesn't have to be perfect.
  • Force synthesis of events. Slow $foo must ping fast $bar.
  • Don't be afraid to do this in userspace.
  • Whitening - Debiasing bitstreams, removing obvious patterns like long runs of 1's and 0's
  • You'll fail less than the status quo.
  • Langauges use shitty CSPRNGs
  • Security must be easy and the default!
  • Testers like predictable test results. Test mode off by default. Fixed (test) seeds make some bugs stay hidden.
  • Should we use userspace CSPRNGs?
  • There's no advantage to sucking. You can be fast and secure.
  • Mixing time in works. It's actually hard to make processes happen simultaneously on computers.
  • Cryptomnemonics - Remembering the bits
  • Human brains need spaced out repetition to remember
  • We remember stories and narratives. Represent bits that way.
  • Storybits v0.1 - software (not released yet) which makes it easy to remember bits (i.e., your key)
  • Python - Node Box linguistics suite
  • Generate passphrases and issue to users
  • Phidelius - use passphrase to seed an asymmetric cryptosystem
  • Just now catching on two years later: Brainwallets, miniLock
  • Both are vulnerable to low entropy attacks (leading to predictable keys)
  • Storybits increases memorable entropy
  • Inadvisable right now. Local shrinking. It's easier to remember 24 bits than 128 bits.
  • Still relatively unique
  • Passphrase -> hash function -> truncate output
  • Local stretching - complexification of passphrase - sagans of times
  • Can be done in the client before the data is even sent
  • Examine passphrase pattern, stretch those patterns individually
  • Java - write once, pwn everywhere!
  • Web browsers constantly allocate and type memory
  • Gotta free it sometime
  • There are sagans of ways for objects to point to one another
  • Two object contexts, one pointer
  • Google's solution - typed heaps. Memory segregated by types of objects.
  • Microsoft's solution - nondeterminstic freeing. You don't know if memory has been free()'d or not.
  • Iron Heap - you can't use after free() if you never free()
  • Physical memory is re-used while handles are not
  • 64-bit address spaces make this feasible
  • Finite number of active allocations
  • Guard pages - unallocated pages between allocated pages
  • Probabilistically done
  • The attacker never knows if an exploit worked or not
  • Done in userspace
  • Many defenses assume that corruption has already occurred and try to remediate it
  • Prevent memory corruption from happening in the first place.
  • Firefox needs to catch the fuck up.
  • DDoS attacks
  • 2013: 1 > 100 Gbit attack
  • 2014: 114 and still inccreasing > 100 Gbit attacks...
  • Most are spoofed DNS traffic
  • The most bandwidth you can consume is that of the slowest link in the network
  • BCP38 - network ingress filtering
  • Stochastic tracing
  • "Background traceroute" done by the routers themselves
  • "Router: Set up a GRE tunnel and send me 1 out of every 1,000,000 packets."
  • Go to destination and source
  • If you're spoofing, you don't get privacy. Suck it.
  • in-addr.arpa IN ADDR records can hold more than reverse records
  • There will be a long-term reaction to the NSA.
  • Political FUD vs technical merit
  • Talk of breaking BGP routing to keep all traffic within the geographic and political borders of the United States.
  • Even obviously good advice is being treated with deep suspicion

NSA Playset : GSM Sniffing - Pierce and Loki

  • GSM: The most widely used cellular standard in the world
  • Invented in late 80's, deployed in early 90's
  • Traffic encrypted with A5/1 stream cypher most often, A5/3 stream cypher less often
  • A5/1 has been cracked several times in the private sector
  • A5/3 (KASUMI) is thought unbroken
  • 1994 - First A5/1 attack proposed. First publication of an open A5/1 implementation.
  • 1997 - First formal cryptanalysis of A/5 at Eurocrypt. Time/memory tradeoff attack.
  • 2000 - Paper on realtime cryptanalysis of A5/1 published. Later that year slightly different version published.
  • 2003 - Ciphertext-only realtime cryptanalysis of A5/1 published. Requires 32 terabyte rainbow table.
  • 2006 - Improved version of that attack which requires much more data but a smaller rainbow table
  • 2007 - COPACABANA - NSA technique which uses an FPGA-based hardware implementation. (Now commercially available - STINGRAY?) Brute force, not realtime. Requires 30 minutes/phone call.
  • 2008 - GSM rainbow tables generated by h1kari, announced at Shmoocon. Only 2 TB in size, a significant reduction.
  • 2009 - A5/1 cracking project started at Blackhat
  • Release of Kraken, a massively parallel, GPU capable rainbow table generator for A5/1. First A5/1 rainbow tables publically released.
  • 2010 - Airprobe published, which does realtime capture of GSM traffic with USRPs.
  • OsmocomBB - F/OSS implementation of the GSM baseband, can capture traffic and decrypt with Calypso in addition to setting up your own GSM cellular stations.
  • Uses hacked, cheap Motorola cellphones as sniffers.
  • GSM is broken and still isn't fixed.
  • 2012 - Use RTL-SDRs as traffic monitors. Community went berserk.
  • 2013 - HackRF, BladeRF SDRs for both transmitting and injection.
  • Then the ANT catalog leaked.
  • The NSA Playset: If a 10 year old can't do it, it doesn't count!
  • Carriers have fixed NOTHING 20 years later.
  • All these things have been collected into a single application platform
  • There is a respin of Kali Linux which has all the GSM toys added to it.
  • TWILIGHTVEGETABLE - Automatic collection and decryption of all GSM traffic within range
  • Will support all software-defined radio platforms
  • Capture clients: SDRs -> database server -> Kraken --> session keys -> TMZ/DMZ dumps
  • ARFCN - Absolute RF Channel Numbers
  • Detects "Switch to this channel," "Begin crypto" messages which are known plaintext
  • Dispatcher stores packets
  • Kraken does plaintext statistical analysis of packets to classify and identify. "I think this is $foo kind of packet." Stores cracked keys with TMSI. Decrypts voice, SMS with those cracked keys, saves with the IMSI.
  • Kraken server allows queuing of crack requests from multiple clients.
  • Parallel instances, can be loaded into the cloud (bluh bluh hate that word), load balancing.
  • RTL-SDRs are more than sufficient for monitoring.
  • GENESIS chipset - Motorola Sliver A9 cellphone. Hackable.
  • LEVITICUS chipset - Motorola C139 cellphone. Well documented, also hackable. C123s are also usable.
  • Can be bought new on eBay for around $5us. Dead cheap.
  • Interface cable is an FTDI to standard micro audio jack serial device. Can also be bought on eBay for this purpose. Can be used to push custom firmware images onto the phone.
  • Custom firmware isn't permanent, only runs in RAM. When power is lost it reverts to the manufacturer's code.
  • PoC available.
  • There is a respin of Kali Linux that includes Kraken preconfigured and ready to go.
  • Download and run. With the appropriate RF gear you can pretend to be a GSM celullar tower. Wireshark dissects the traffic.
  • Make sure your code points at the correct serial devices. Oops.
  • Do not leave phones charging unattended because charging management is software only, not hardware, and isn't perfect. Keep an eye on it.
  • http://gsmmap.org/. Plug in phone. Boot USB stick. Wardrive GSM towers!
  • Avoid Tracphones, they're harder to reflash. Just buy a Cingular C139, it works right out of the box.
  • DRIZZLECHAIR - A5/1 rainbow tables on a USB-3 drive. Tables are on the partition, not in a file system.

NSA Playset: PCIe - Joe FitzPatrick & Miles Crabill

  • SEXviaHEX - Software EXploitation via Hardware EXploitation
  • Part of the NSA Playset
  • Early phase of research, poor citations
  • There is lots of prior PCIe DMA work
  • Trying to make it accessible
  • PCIe - PCI with fast I/O, but not exactly
  • Backwards compatible
  • Packets are sent across lanes
  • Switched and routed bus architecture
  • Pretty much a network protocol
  • Amazingly simple spec to facilitate hardware design
  • If you don't follow the spec, your board will still probably work
  • Boards can be internally clocked
  • 2.5 GHz TX and RX, 100 MHz clock (optional)
  • Adapter which lets you string cable and plug devices into the bus without seating them on the mainboard
  • SLOTSCREAMER - PLX Tech ASIC - PCI/USB bridge chip
  • PCIe devices over USB
  • Computer looks like a mass storage device
  • Easy to hack after that point
  • PCI OUT endpoint
  • "I <3 undefined behavior"
  • In the Linux kernel endpoint functionality is explicitly disabled in the driver "for security reasons."
  • 16 bytes of firmware set up the PLX Tech ASIC on the board
  • Fake the device ID to make it happen. Some device IDs seem to be implicitly trusted, so pretend to be one
  • pyUSB to interact with endpoints
  • INCEPTION - exploits firmware DMA to search through RAM, inject code into arbitrary locations in the memory field
  • Added "INTOPCIe" to make it possible to do this over PCIe
  • Volatility - memory dump analysis framework
  • Apple Thunderbolt - PCIe without the benefit of a USB bus
  • HALIBUT DUGOUT - SLOTSCREAMER in an external Thunderbolt enclosure
  • On the PLX board, put a jumper on pins 1 and 2 to enable writing to the EEPROM, flash the firmware
  • BusMaster mode gives you access to the entire memory field
  • Virtualized hardware via IOMMU
  • Don't plug anything sketchy into your Display Port or Thunderbolt port. Ever.
  • Bad Things(tm) can be hidden inside legitimate devices, like adapters or the cables themselves.
  • ALLOYVIPER - practical implementation of this attack and live demo on stage

Is This Your Pipe? Hijacking the Build Pipeline - Kyle Kelley and Greg Anderson

  • Source code control
  • Continuous integration
  • Open source software, builds, and testing
  • Everything needs secrets of some kind to operate. API keys. SSH keys. Passphrases...
  • Those secrets have to be managed in some way. When automated processes are involved, those secrets can easiliy leak.
  • For example, search Github for the string AKIAJ (if that link still works in a week or two, something is really, really wrong in DevOps land...)
  • Leaked credentials WILL be abused
  • Instances need to be locked down
  • EVERYBODY NEEDS TO READ THIS
  • Mount someone else's EBS instance read-only, read everything on it
  • Append SSH keys for deployment in new instances
  • OS_PASSWORD
  • rackspace_api_key
  • api_key
  • (note: I really, really, REALLY hope those last three searches return nothing but false positives.)
  • Creative partitioning of searches
  • Tell people when they screw up, otherwise they'll never know to fix things
  • https://github.com/gitsec/nanny
  • Search for leaks and report them
  • config/initializers/secret_token.rb often contains API keys and credentials
  • Travis CI
  • Encrypted secrets: Can they be decrypted? Can they be leaked?
  • Only barrier is code review, and that's insufficient
  • Jenkins - continuous integratioon and deployment suite
  • Implements a build pipeline - detect push, check out, compile, run unit tests, analyze output, package good builds, deploy
  • The end of the pipeline is a production server or another repository that all production servers pull from
  • github_token - exploit leaked credentials
  • Propagate vulnerable code into the pipeline via the repository, wait for someone to do a push, and then exploit everything running the gigged code later
  • Jenkins sets up internal environment variables to set up build prrocesses
  • Crack the Jenkins install directly, get it to overwrite the [user]/config.xml file
  • Submit a build that corrupts users' config.xml files when Jenkins runs it
  • Put the config files only on the master node
  • sleep(3) buys you time
  • Do lots of commits to all repositories a Jenkins box works on
  • Automatic pull request builds
  • (Yes, this is incomplete, they really flew at this point and I didn't have time to write everything down. Sorry.)