DEFCON 21- Day 3

August 3rd at 12:00am

SDR's jump out at me the most from today. Maybe because the session was awesome and the last one I attended today? :) Overall I had a great time today, even if there were some issues with AV equipment and soft-spoken presenters.

Summary of my Third day at DEF CON 21:

10:00am - Do-It-Yourself Cellular IDS

How would you know if your cellular phone was comprimised? In recent years, malware on phones has increased 614%.
Cellular phones make appealing targets for botnet managers. Once installed, botnet activity can happen over cellular data connections with very few indicators to the user whose phone has been compromised. It would not be surprising to see groups of cellphone-bots go up for sale in shady circles.
In Enterprise environments IT staff are used to having control over the network. While this is still the case when it comes to WiFi, if phones are using cellular data it is out of reach. Nobody in the enterprise can examine the traffic and the cellular carriers are bombarded with enough traffic that it isn't practical for them to sift through the traffic looking for compromised devices (Perhaps the NSA could help?</snark>)
To remedy the situation, the folks over at LMG Security created an IDS out of a femptocell (follow the link for a detailed whitepaper)

They used the Verizon Samsung SCS-2U01 and SCS-26UC4 femptocells
Once they rooted the femptocells, they routed the traffic to a SNORT box using IPTables NFQueue and netcat. They also had to make modifications to the U-Boot that came bundled with the Femptocell

A note on NFQueue. I'd never heard of it before today. Sounds like it lets you set up a rule at the IPTables firewall level and export the packets. It exports them as hex so this team wrote a wrapper app to convert it to PCAP before attempting analysis with WireShark

To get netcat and NFQueue on the femptocell, they had to follow an elaborate series of steps to get the MonteVista Linux toolchain (a specific older version) downloaded so they could compile NFQueue support for IPTables as well as get netcat working. Fortunately for them, one of the Texas Instruments OMAP processors had something to do with MonteVista so they grabbed the toolchain from the downloads page.

They left a few words of wisdom to anyone who may follow them down this path:

To interrupt the boot process on the femptocells they were working on, Press S, Y, S and then the Return key (assuming you have the Serial port setup using pins 16 and 17 from the HDMI Connector
Note that Cntrl-C is not mapped to SIGTERM, so if you run something like ping without arguments to stop, you will have to reboot the femptocell before you can start working again.
When analyzing the packets you capture from the device, be prepared to see some serious crazy: Data is nested many times in redundant encapsulations. I think they mentioned something like this: HTTP inside TCP inside PPP inside GRE inside TCP inside IPV4 inside a Frame (not 100% accurate, but you get the idea how much dissection has to go on to get at the real data)

They had to write their own CDMA 2000 dissector since Verizon doesn't use the latest version of the standard. They will be uploading this dissector sometime soon.

Even with the custom dissector, they still had to manually reassemble some packets for analysis which was tedious.

While there is more detail to what they did with the Femptocell (See the whitepaper mentioned in their blog post), they also discussed a particular Android malware called android.stels and how they can Man in the Middle it to point to their own Command and Control servers

They use Snort rules to check for android.stels
They make a valid point that this can come in handy if you know the malware signatures for phone malware. You can redirect the bots to your own benign servers and buy IT some time to track down which device is compromised. Especially useful in context of BYOD.

My personal thoughts are that you could take their approach one level further and either deny authentication to devices that are detected to be compromised, or you could notify them of the need to contact their administrator (or some message that is more appropriately phrased).

12:00 - Defeating Internet Censorship with Dust, the Polymorphic Protocol Engine

Brandon (the presenter) has worked on Freenet, curious yellow (Superworm meant to destroy the internet), bit torrent (used to work there, first heard of Deep Packet Inspection when working there), TOR and has written a book for O'Reilly titled 'Peer-to-Peer'
He believes the internet to be the major technological marvel of our time and works a lot anti-censorship technologies
More information about Dust can be found on the Dust Github Page
The presentation started with a story about what people like to do online. Obviously they care about looking up, exchanging, downloading and uploading cat pictures. Since the internet is comprised of a number of systems with varying max-packet sizes, things like cat pictures are split up into packets and reassembled on the other side. This is great because cat pictures can easily be shared

But what happens when you add a robot into the mix? Robots hate cat pictures and block then whenever they are found. Sometimes the robots send a Sad Panda picture in place of the original cat picture. Robots only care about whether something is or is not a cat picture. If something is NOT a cat picture, it can pass. In this case, the robot will let any banana pass because it is obviously not a cat picture

So, how do we get a cat picture to pass the robot? Make it look like a banana.

Key to the story:
Cat Picture = free speech
Sad Panda = Censorship and those who don't want a free and open Internet
Robots = Filtering hardware
Banana = Stuff the filter hardware doesn't care about
Filtering Hardware (robots) can use a variety of methods to determine whether or not something should be blocked. These days protocols are more likely to be blocked than specific content (easier to block ssl, vpn and tor than to Deeply inspect EVERY http packet!).

Here are methods that Filtering hardware has been known to use:

Packet Length analysis: If packets are a certain size in bytes, it must be a certain protocol. Brandon showed statistical analysis of different protocols and their respective packet sizes. Yep, looks like this could be one filtering mechanism (alteit naive)

Statistical Pattern Seeking: This method relies on checking for certain patterns of bytes in data packets. Using statistical analysis you can see which protocols are in use. For example, since HTTP is comprised of predominantly lower-case ASCII characters, those byte patterns show up more than in other protocols. SSL also has spikes around lower-case ASCII Character strings as SSL has an unencrypted header.

Byte Pattern at Packet Offset: This is the most popular way to filter packets (over 90% of filtering hardware devices use this). It examines the first packet in a stream at a certain offset for a certain combination of bytes. If it finds what it is looking for, it blocks it.

Block Random Packets: If packet data looks 'random', some DPI hardware will reject it out of hand.
The Dust project does a few things:

Obfuscates packet lengths to match a protocol other than the one you are using
Hide your data inside the patterns that appear in another protocol
Removes statistical content information to make your data look like a target protocol

To use Dust:

Need a server
Need a client
Need to exchange public keys out of band (no handshake negotiation here)
The client needs to know: Server IP, Server Port and Server public key/certificate
Server side needs:

Defined set of properties for a protocol
Defined set of rules for the protocol classification
Dust then generates an encoding that can be used to transform input data
The properties of the original data are altered to avoid leaking information
The distribution of byte sequences are altered to force the Deep Packet Inspection Hardware to re-classify the traffic

Brandon has written a few tools that relate to Dust:

Shaper which lets you test hardware Deep Packet Inspection devices (DPI)
Replay which lets you find out specifically what bytes hardware DPI devices are using to determine a protocol. It does this by replaying a set of packets with different bytes 'blanked out' to see how it makes the DPI Hardware respond
Message Server lets you pass 'data' in and get 'data encoded in a different protocol' back

Here are a few 'closing thoughts' captured during\ this presentation:

He isn't trying to make a new protocol he is making a protocol engine that impersonates *other* protocols. Anything can be circumented, so it is good to be flexible this way.
Brandon likes the idea of chimeric protocols which mix, say, NTP and HTTP. This makes it difficult for mainainers of DPI systems to filter your packets. They have to figure out a differentiator before they can do so.
He suggests reading a paper titled The Parrot is Dead
Governments and others don't tend to upgrade their DPI equipment. Some is 10 years old so it may behave differently than new stuff
He likes to make changes to his tool based on:
1. How often is a DPI filtering scheme used in ACTUAL hardware?
2. Is the capability in the hardware but not used yet?

This is different than other Open Source where edge cases that the author thinks of are fixed first, then what comes across the mailing list (This is the Presenters opinion).

13:00 - RFID Hacking: Live Free or RFID Hard

This talk was meant to be a practical discussion on how to penetrate RFID systems. The concept originated when the presenter needed to break into RFID systems as part of a penetration test and didn't know where to begin
In order to penetrate RFID, you need a clone of a valid RFID card (either that or stealing someone else's card). To clone someone's card you first need to read it. To read it you have traditionally needed to be an inch away from the card (which makes for awkwardness when you try to sneak up on someone to read their badge).
The Presenter took time to introduce a new RFID Long-range stealer from Bishop Fox (Security Consulting Group). Now you can be up to 3 feet away and scan someones card! The limitation is that this focuses on the older 125kHz card style (still in use at 80% of locations, though).

** Biship Fox will make available plans and boards to build something like their long-range stealer at some point **

Once you have the card scanned, you can use some equipment to clone it:
- Proxmark3 to program a programmable card
- proxbrute is a different firmware you can use for the proxmark
- Either T55X7 or Q5 (15555) cards for programming
- RFIDiot python scripts
- RFIDeas tools (USB Sticks for checking and analyzing to see if cards are 125KHz or 13.56Mhz
Apparently there are really only 2 major or common RFID Badge Scanners:
- Indala Long Range Reader 620
- HID MaxiProx 5375AGN00

Indala claims to be more secure as it slightly obfuscates the return signal from the cards, but modern equipment (proxmark3) and appropriate general purpose RFID badges render it a moot point.
The presenter showed research showing that 125Khz cards were insecure in both 2007 and 2013. It doesn't look like there is much movement to fix this problem :/
Better technology exists that we should move to (contactless Smart Cards provide encryption and better authentication)
To defend RFID, there are a few idaes out there:

RFID Proof wallet / badge card holder
Note: RFID Proof Card sleeves for US Greencards DO NOT WORK. Be sure to check your protective measures work before relying on them!
Move to Contactless Smart Cards
Use Tamper Evident SmartCard/badge readers
Use software to track behaviors and note when an 8 -> 5 card is used at night.

14:00 - Defeating SEAndroid

SEAndroid is equivalent to SELinux
The Presenter tested Android 4.3 (SEAndroid supposedly enabled by default) and found that while it is effective at some things, it is vulnerable in other ways.
SEAndroid is effective in the following ways:

Good way to enforce fine grained Mandatory Access Controls (MACs)
Helps prevent Privilege Escalation by isolating execution contexts
Permissions checks are run on Inter-Process Communication (IPC) operations
Permissions are revokable with ease

SEAndroid is ineffective / vulnerable in these ways:

Can't protect against kernel level vulnerabilities
Needs some sort of SecureBoot and Runtime Integrity system to keep the base system in a validated 'ok' state
Commercial implementations lack some rigor in development and testing (Vendors don't know how to write effective SEAndroid policies)

The presenter found a few implementation glitches in the hardware / software he tested:

System boots to enforcing mode, but the recovery image is in Permissive mode
The root user can't disable SEAndroid, but the system user can change it with setenforce
Enabling and Disabling SEAndroid is done from a user-land application (I'm not quite sure what is so wrong about this... Then again I've tried to avoid Android development where possible, so I may not be the best judge of this. :) )
SEAndroid can be disabled during boot if you connect to the USB port and pass in commands to the console
OTA update from Android 4.2.2 -> 4.3 causes an 'unlabeled' file system
The Enforcing mode that comes out of the box in 4.3 doesn't actually enforce

At times I couldn't make out what the presenter was saying. It was his first conference, so maybe he was a little nervous (also, I was at the back left of the room by an open door with noisey people outside).

14:30 - Breaking your expensive crap (aka "Doing bad things to 'good' security appliances)

Introduction to breaking into security devices. Presenters are friendly but talk quietly sometimes
Equipment

Voltmeter
SMT Solder Station / Hot Air Rework Station
Microscope
Magnifying Glass
Debuggin Interfaces appropriate to your hardware
Bus Pirate - connection between microcontroller and a PC for examinatino purposes
IDA Pro - Cross platform multi-processor disassembler and debugger

Process Steps

Figure out your goal. Why am I here? What am I trying to do? Super important as this can get complex fast
Define the device. Isolate the chip(s) you either want or need to examine
Gather Open Source Information. You can social engineer a sales person for the device's parent company into giving you all sorts of technical data
Examine the device for Entry Points. Watch out for equipment that fries itself or disposes of encryption keys when improper entry is detected
Analyze device circuit networks and components. This helps you prepare for an attack

Common Mistakes by Reverse Engineers

Forgetting or ignoring Note Taking - These systems are COMPLEX, need notes/pics!!
Not taking pictures
Getting burned with heating devices
Burning oneself with chemicals
Improper ESD protection against Static Electric Discharge
Not testing on Backup or non-critical equipment before performing a real attack on the real hardware

Common mistakes by Vendors

Put your case sensor wire by the vents (makes it easy to circument case access sensor)
Hide chips under epoxy. This is a joke, as it doesn't actually stop anyone from examining the chips or extracting useful data
Not using built in encryption on embedded chips. Makes the Reverse Engineer's job much easier
Not setting read/write protect bits on Processor Flash memory
Not limiting access to debug or provisioning ports. Opens more attack surface
Desoldering some things from the board. This doesn't stop me from putting it back and pulling data out
Running I2C or 4P buses to user LCD then back into the Ft. Knox Box where it attaches to the boot flash. I have the feeling that the presenters have seen this somewhere

Possible Attack Vectors

Voltage glitches
Timing Manipulation (External clock applied)
Fuse resetting if you can polish the chip in a cleanroom (UV Method)
JTAG / BDM / Provisioning Interfaces
And so much more!

I had to bail early so I didn't see any of their example scenarios. Given the short time they had left I Hope I didn't miss much
d

15:00 - Cracking WPA with HashCat (In the Wireless Village)

You can use Aircrack to crack WPA
HashCat OCL can use the GPU to crack WPA using brute force
Bitcoin miner hardware can be used as an accelerator for HashCat
There is a Reaper/Reaver tool that can also try to connect to WPA
Password lists can be used to cut down on time as well
There are few bullet points and not much data from this session as it started late, the presenter had no slides or any sort of structured presentation and discussion around tools strayed from what was advertised. I was hoping for more.

16:00 - Suicide Risk Assessment and Intervention Tactics

By Amber Baldet (attrition.org)
Artistic, creative people who have anxiety or other problems can be at higher risk of suicide. The Hacker community is comprised of its share of eccentric, radical thinkers so we may have some risk factors
In the USA someone dies every 14 minutes from suicide (every 2 minutes in China)

10th most common form of death for 15 to 24 year olds
2nd most common way to die for 25 to 34 year olds

It can be hard to find a mental health professional who understands what an acceptable level of paranoia is for people that do what we do. Many times peope in our community have had issues with mental health folks which complicates getting effective treatment.

We try to self diagnose
Failing that we try forums and other online resources (which seems to work about as well as the phone call service, while retaining 30% more people who reach out for help)

There is a difference between Intervention and Frientervation

With Intervention they come to you, maintain anonymity, structured time scheduling
With Frientervation it can be more stressful: Relationship issues, burnout, if things don't change there can be hard feelings

Warning signs that someone may be considering suicide

Verbal cues like 'Wish I were dead', or 'If I don't find a boyfriend I'll kill myself' or other phrases coded as jokes
Behavioral cues like seeming depressed, giving stuff away, sudden interest in religion
Situational cues like losing a job, divorce, prosecution by federal government

Volunteer and First Responder Info

Find a safe place to talk
Ask if they are considering suicide (be as direct as you can while being genuine). This question saves lives
Build trust
Listen to what they say while being responsive. Let them braindump
Come up with a plan of action for what happens next
Come up with a crisis plan: What will you do when the thought or tendency returns?
Persuade to get professional help if possible
Commit them to a pact to avoid personal harm
The goal when talking to someone is to give them hope for the future

How to talk to another human being

People considering suicide have 'mental blinders' on, so don't try things like the socratic method with them. The mind is impaired and all the logic in the world can't change that.
Active Listening is not Social Engineering. We're not trying to manipulate, but rather to help
Ask one question at a time
Repeat what the person said back at you and ask if you heard right
Be honest and mention when you don't understand something
Ask open ended questions

Things to avoid when talking

Interrupting their train of thought
Asking lists of questions
Promise to secrecy
Leading the witness (we'd rather hear their organic thought process)
Trying to 'solve' their problem
Rational Arguments
Important: Never say "You're not thinking about doing something stupid, are you?" as this de-legitimizes their issues which are very real

Separate 'Feeling' from 'Being'

If you say, for example, "I'm burnt out" it implies a finality. That you 'are' something.
If you think about it more like "I'm exhausted because of ____" Then you stand a MUCh better chance of isolating what is causing the problem (Exhaustion/burnout) and being able to solve it.

Buffers

Everyone has certain 'buffers' that keeps them from doing something they might regrest. Suicide is no different.
Internal buffers (purpose to life, plan for the future) are better than external ones (Responsibility, community).
Even though some are better than others, they are all good if they can help prevent someone from suicide.

Desire

What sort of Will to action does the person have? Do they have a strong desire for suicide? Are they intent, capable and have a history of attempts?
People with strong desire and low buffers are at a higher risk of suicide

Final Notes

If a suicide is in progress, call 911!
Don't leave without knowing what the next steps are
Make sure they commit to personal sfety
Help them build a crisis plan. What can they do when it come sup again? outsmart your own brain.

17:00 - Noise Floor: Exploring the world of unintentional Radio emissions

Unintentional Radio emissions are everywhere- no device is immune to it. This talk is aout how to cheaply find the RF your devices emit and why you should care about it.
You don't need super expensive equipment for this: A PC and $20 for a USB SDR works fine. Inexpensive SDRs. Here's what you'll need:

SDR# (Software radio for windows)
GNURadio (SDR Solution)
Gqrx (SDR for NIX platforms, QT and GNURadio)
Realtek RTL2832U (GOOD)
Elonics 4000 (GOOD)
FC0013B (Not as good)

- All these Devices have PAL-B connectors, which are kind of weird. Radio shack should carry adapters to regular antennas
- Included antennas are pretty weak

So, why should we care about suprious RF?

The NSA Cares. They can detect a lot from the RF emissions from your devices
Detect display data using wireless receiver with Van Eck Phreaking
Compromising device emissions that leak intelligence (TEMPEST)

What can be detected?

Display data (LCD and CRT)
Typewriters
Wired keyboards
Wireless Keyboards
Mechanical click buttons (mouse clicks)
Touch pads
Color of LEDs
Microphones
RAM memory
Hard Drive access
Usage patterns (When you are active, idle or offline)

Legal stuff

Read up on applicable laws
Some things may not be safe to listen to from a legal standpoint (like tuning into Cell phone bands if you are not a cell phone)

Melissa the presenter did a demo with a $50 chinese netbook running Windows CE (which has no RF shielding at all) and a USB SDR adapter attached to a windows laptop running SDR# to scan the radio data received.

Tuned to a radio station & watched the signal in SDR#
Turned on the Netbook
Notice how SDR# shows a much rougher signal at approximately 32Khz intervals? We're picking up the Real-time clock from the netbook!

Her second demo picked up a checkerboard pattern from the display (through powerpoint)

Started SDR
Turned on a checkerboard pattern on the netbook
Extracted the signal and got a warped checkerboard pattern using the data she picked up from her scan, wow!

So how do I find things?:

Math. Calculate what frequency you'd expect to hear
Harmonics. Integer mutiples or divisions of the frequency can be tuned to, too.
Luck. :)

Privacy advocates, Whistle-blowers, Journalists and Private Citizens should all be aware of this. It stands to reason that the NSA and potentially seedier organizations have better antennas and equipment to work with and may be able to monitor a lot more than we think!

While a Faraday cage can help reduce (or eliminate) some RF, operating within a faraday cage on a regular basis can be annoying. Consider that your Microwave is the closest thing to a faraday cage you have in your house. If you lock your electronics in it, you won't be ble to see them, or use them very well. Not to mention that you block the use of the microwave for actually heating food.
My thoughts: An excellent presentation! Gives me motivation to see what I'm leaking to the world!

Day 3 Thoughts:

I'm having a great time and feel like I'm gaining a new perspective on some things that I already knew about while I'm also learning about new things. DEF CON Has already justified the cost- and I have one more day of presentations to attend!

I will be leaving a bit early tomorrow (around 3:30pm) as I need to drive home before sundown.