defcon 24 - Notes for Friday 2016-8-06

Defcon sure has changed since the last time I was there.

This blog post has my notes from defcon 24 Friday 2016-8-06.

How has defcon changed? Well glad you asked:

• Lot more people.
• Ton of people there for the 1st time. Maybe 20% at one session where they asked the question.
• Things are more spread out. A lot of walking.
• But the crowd crushes still happen.
• And you still sometimes have to line up an hour ahead of time to get into a prez.
• Things are quieter, more laid-back. At least during the times I was there. People actually do what the goons asked them to. Well, most of the time.
• I met a fellow who had actually flew in from Austria just for defcon. Not BH. Amazing.
• And the prez were generally of very high quality. As good as BH for the most part.
• They still give you materials on Dvds. Thankfully you do not have to log on to the defcon network to download stuff.

The times sure are a-changing. This is definitely no longer the old style "Alexis Park" defcon. It is almost a computer conference, not a con. IMHO.

DARPA CGC

From the defcon program:

Darpa’s Cyber Grand Challenge (CGC) is a Capture-the-Flag competition that pits autonomous computers against one another: no humans allowed. … 7 finalists placed highest in a qualification event, then passed a series of trials to earn the right to compete in the CGC Final Event.

Groups forged from academia, industry, and the hacker community have been working tirelessly for more than two years designing and building these reasoning systems to compete autonomously in Capture-the-Flag.

Like any CTF, bug hunting is the core of the competition. Once found, bugs can be fixed, and vulnerabilities in opponent software can be proven. Of course, this process is quite complex, and in CGC, high-performance computers will reverse-engineer unknown binary software, author novel IDS signatures, probe the security of opponent software, and field defended services with machine-generated patches and defenses.

1st prize: $2M, 2cd prize $1M, 3rd prize $750K

For more information: https://www.cybergrandchallenge.com/

Announcement of the winning team: http://www.darpa.mil/news-events/2016-08-04

Their computer will compete in the main defcon CTF competition against human teams.

411 framework for security alerts

https://fouroneone.io

From Etsy. 411 is their internal alert mgmt. system.

Will be open-srcd. ELK stack. Old technology.

(Side note: Etsy also has a Bug bounty pgm.)

History

Moved from splunk to ELK. Why???? Probably not for functional reasons but rather co$t.

Bumpy migration. Performance-impacting bugs on ELK cluster e.g.

• Kernel bug re NFS mnt
• SSD problems

Security implications as well.

Functional challenges

• Alerts: They had used splunk scheduled searches for alerting. No web UI for managing queries to fix malfunctioning alerts.
• Unfamiliar Query language: Moved from SPL to less robust Elk equivalent.

Needed robust query language + mechanism to run queries

Answer

Tools developed (and will be released with 411??)

• ESQuery developed by Etsy internal data ppl.
• SplTASH to do bulk translate from SPL to ESQuery scripts

411 Functions

• Alert mgmt.
• Write + schedule queries
• GUI to manage everything

Alerts → Filters → Targets

Scheduler → Search jobs → Workers

Tab by (painful) tab explanation of each fn in the GUI interface.

411 integrates with Jira for managing tickets generated.

Queries can have lists. (eg TOR exit IPs)

Alert mgmt. workflow

Alert in email. Buttons → View in Kibana, view in 411.

Emails are generated for high-value alerts (Med, High) with low false +ve rate.

Low-sensitivity alerts do not generate emails. Have roll-ups to summarize activity.

Triage → look at alert context – what other alerts generated along with this alert?

Sunset or modify alerts that is too specific and is no longer relevant as it stands.

Other use cases

• Developers generate alerts in their code to signal anomalies.
• If see a high volume of traffic to sensitive host, then put alert just to watch resource.
• Deprecating old code: Place an alert to identify how much an old code branch is being used.

Configuration

Etsy runs 3 production instances of 411:

• Ops / Prod
• Security-related
• Compliance-related.

Integration

Graphite for visualization of data. Store / visualize time series data.

Http searcher tool (released with the open-src version)

Sentient Storage: SSDs Forensics

Tom Kopchak @tomkopchak

This is private research. He is a mgr at Hurricane.

Goal of presentation: Describe differences between hard drive forensics / SSD forensics

Hard drive forensics review

• Quick format does not delete data.
• Generally if whole hard data is overwritten once, data is usually not very recoverable.
• Hard drives do not move or manipulate data to optimize.
• H.D. do not move blocks independently of the OS.

Same consistent behaviour across all commercial hard drives.

➔SSD drives change most of the above assumptions.

SSD basics

SSD flash memory chips. ➔ Flash translation layer ➔ Drive controller to provide hard-drive compatible operation.

SSD Architectures

SSD architectures:

• SLC (single-level cell)
• MLC: 2 bits/cell. Slower but less expensive.

FYI: Blank cell with no data is represented by all 1’s.

Page is smallest addressable unit. Pages cannot be overwritten.

SSD data deletioin

When data is deleted, blocks containing that data is marked invalid. The block cannot be reused until all remaining data has been moved away and the block is completely erased. (reset-erase)

SSD are very slow to erase data. So need a stock of empty cells to receive data if data erase occurs.

Flash “wear” on SSD drives

Flash wear: Flash cells have a finite # of write/erase cycles. SSD controller will move data between blocks to ensure even “wear” for all cells. This occurs independently of the OS.

SSD Drive controllers

Many different controllers. Firmware changes can also radically change behaviour on the same physical controller.

Sophisticated data mgmt. function:

• Controllers can de-duplicate data to increase performance.
• Also garbage collection during idle time to free up flash cells, level “wear” of cells, optimize performance.
• OS notifies the controller with TRIM cmd that data can be deleted.

SSDs behave more + more like the enterprise SAN drive.

Forensic implications

Questions arise:

• Can SSDs be treated like normal hard drives?
• When should an SSD drive be treated differently during a forensic investigation?
• Are traditional forensics approaches sufficient in the case of SSD drive investigation?

His research

Previous research: looked into data destruction by flash by filling the flash data with 1’s. Studied data movement.

His research: Looked across a wide range of SSD drives. File is deleted. What happened? Concentrating on deleted file recoverability. Wow!

Test protocol

Two basic tests were made under varying conditions:

1. Deleted file test: Delete file. Image the drive. Try to recover the file.
2. Quick format test: Format the hard drive after

He made small incremental changes in conditions in order to isolate impacts:

• Text vs image (ie picture) files
• Mix other files on disk with target text file
• Generate other activity on the drive.

7 Drives were used: 6 SSDs + 1 control drive (Seagate):

• Crucial
• Intel
• OCZ
• Patriot
• Samsung
• SuperTalent (old SSD with SATA – Parallel bridge)

For each test, he unmounted test SSD drives to ensure that files were truly written to SSD. i.e. data not kept in drive cache.

Lesson learned: Imaging a SSD drive with 100’s GB data over USB with Write blocker → very slow.

The TRIM command

• TRIM command only works on a SATA bus. If drive is connected with USB, no TRIM.
• OS also generally contains function to turn TRIM off.

Forensic lab used for testing

• No OS installed / activity on SSDs. Only test data.
• Dedicated hosts for evidence creation / evidence collection
• Caine Open Source to image drives / collect evidence.

Other research has shown that an SSD drive on a write blocker can modify data (in spite of the write blocker). (!)

Testing Results

Here are the test results summarized:

• TRIM state can significantly affect data recoverability. Turn off TRIIM to improve chances of recovering data.

• If there was more than just 1 small file (e.g. larger files, more files) then Samsung and Intel would delete the file to be recovered. Intel and Samsung not very recoverable. Do not behave like a normal hard drive under the covers.

• If the drive is formatted, then for a lot of drives the quick format will remove all trace of the data. But not always.
• All files on the control drive were (usually) recoverable all the time.
• SSD drives can be grouped in 2 families: those that have good recoverability, those which are not very recoverable.

Comment from audience: If SSD sits on a shelf in power-off state in a forensics lab for some months waiting to be analyzed, then “bit rot” will set in + data starts to decay. Controller not powered up to protect data.

Conclusions

• Deleted file recoverability depends on a lot of variables:
• TRIM state
• # of files
• file I/O volumes
• file sizes
• brand of hard drive.
• As a forensics investigator, really need to be aware of drive differences. Need to modify practices. Especially not waste too much time trying to recover data if SSD drive has been quick formatted.

Maybe need to bypass the flash controller to do more research at SSD flash chip level.

tom *nospam* hurricanelabs.com

Anti-forensics

Not a forensics professional, is a rather a Red Team person.

Has spoken at Recon, etc. 4th AF talk

Goal

Persistence, stealth

Previous: looked at acquisition AF. This talk: analysis AF.

Tactics

Windows PE Hdr

Remove sections from memory.

Rekall / winpem to do acquisition

Finds in memory PE hdr to set write bit on Page. Kills data structure for Portable Executable by writing zeros. RtlZeroMemory

Could:

• write a new PE hdr eg Tiny PE so executable looks really small.
• Modify values in the hdr.

Rekall dumped binary. But IDA could not make sense of the binary.

Linux example

Uses Lime for mem acquisition.

Memory analysis using Volatility. Volatility pslist, procdump couldn’t dump the module from memory.

Finds ELF hdr in memory. Memprotect to set page permissions,. Overwrites memory. Resets permission.

Android AF

Use Encryption. Use TOR, Use Signal.

Acquisition / imaging: painful. He didn’t have commercial tools.

• Lime to acquire mem if kernel supports KLM. However most
• Cross-compile nc for ARM

Power, Decrypted, Unlocked, Rooted, USB, debugging on.

Physical acquisition

• adb devices
• adb push ./nc /sdcard/nc
• to get image
• NAND exposed by different interfaces. Check /proc/partitions

Logical acquisition

• adb pull
• adb shell dumpstate
• aflogical –ose
• adb bugreport

AF

• Long kill chain to disrupt forensics
• Easy to disrupt
• Turn off device, encrypted device
• Leverage sensors too power down if tampering detected.

SD card tricks

Use sdtool to lock / unlock device by modifying firmware.

• CLANG instead of gcc for make.

Usb hub could interfere. Direct MMC device probably OK.

Portal of PI: Raspberry PI running off SD card.

Video console hacking robot

TASBot

@MrTASBot

Twitch.tv/dwangoAC

Allan Cecil

North ? Linux Users Group

Ciena

Speedrunning

Speed demos archive to track fastest completion times.

Strict rules.

Games Done Quick → charity streaming

Abusing Games

Tool-assisted Speedruns (aka TAS)

• Savestates, slow motion, recording tools Eg doom 19 min
• 2003 Super Mario Bros. video. Inhuman skills on display.
• 2011 NESBot: 1st replay of SMB1 SGDQ 2011 on SMB2 and W&W3.
• Tasbot: 2013 SNES + Genesis Arduino bot
• 2014 Nintendo ROB + board + legos: TASBot
• 2015 Game Boy player. Faster games rates: play SMB1 /2/3 parallel (“SMB” == “super Mario bros”)

NESVideos, now TASBot.org (?)  to track tool-assisted speedruns

Console emulators for Super Nintendo. Super Mario World / Super Mario Bros.

Rewrote opcodes in memory to get the game to do what it wanted. Robot could control the console + game.

Special hardware: 23 Mhz FPGA (max poll rate of serial port 2 Mbps)

Arbitrary Code Execution

1. Input exploit
2. Take over Super GameBoy
3. Gain full access to Super Nintendo
4. Break the game.

Combination of hardware hacking + software coding.

Saved exploited game with valid game hdr with more Pokemon. Use object manipulation to write into memory.

POC on GTFO for demo.

Chris Eagle (Mr Ida) Emulation with Ida Pro

Goal of new IDA plugin

“Next gen” emulation of processors using an IDA Pro plugin

Not a full-blown emulator a la EMU. A lightweight emulator for quick execution to understand code better.

Use cases:

• Improve notation of disassembled code by executing a small piece of it
• Simplify code, unwrap obfuscated code.
• Static RE context (not full-blown dynamic execution).

Why use an emulator?

• Hardware not available
• Obsolete platforms
• Quick code study without doing a full hardware setup.

All emulators are not created equal: processor family support

Ida supports many processor families.

Bochs emulator: Native Ida plugin. IA 3x86 PC emulator only

QEMU: full-blown emulator capable of booting Windows, Linux

Unicorn

What is Unicorn?

• A scriptable emulator based on QEMU.
• The Unicorn team ripped out the HAL (Hardware Abstraction Layer) from QEMU
• Then layered on top of the processor function
• Essentially is a scriptable API to execute instructions or a set of instructions.
• Related projects http://www.unicorn-engine.org/showcase
• Supports several processor families (since based on QEMU). But not as many as IDA.

Unicorn is a scriptable emulator. The same developers produced:

• Capstone: scriptable disassembler
• Keystone: scriptable assembler framework.

Ida emulators

Two basic Approaches

There two basic approaches for an Ida emulator plugin:

1. Emulate over the Ida dbase directly
• Use the db as the backing memory.
• This approach is destructive since there is no “Undo” function in Ida.
2. Leverage the Ida plugin interface to build a debugger module.
• The debugger is totally separate from the static analysis function.
• The debugger does not touch the Ida db.
• IPC or other communication between Ida and the debugger. (e.g. IPC)
• This approach isolates the dbase and Ida from impact by the debugger.
• However the results of debugger execution must be imported manually back into the static analysis.

Ida emulators

There are 3 different emulator plugins for Ida:

• IDA Bochs
• Supported by the Ida people
• User interface not easy to use
• Uses approach #2 above.
• Sk3wlDbg
• Ida plugin for emulation based on Unicorn
• Uses approach #2 above.
• User interface is similar to Bochs.
• Early Chris Eagle emulator plugin
• x86 support only
• Used approach #1 above.

Sk3wlDbg: Description, Current status

Sub-classes Ida debugger_t for all supported Unicorn CPU types.

Has simple PE, ELF loaders to map binary file into Unicorn

“Fallback” loader simply copies the Ida sections into Unicorn.

Code is “Alpha” currently (2016-08-05)

Future work: Hook system calls

Integration challenges

Chris E faced the following integration challenges:

• Ida remains a 32-bit executable which interfaces with 32-bit librairies only. Unicorn does not support 32-bit very well.
• QEMU doesn’t build well on Windows since depends on glib. (e.g. requires Cygwin or equivalent) Consequently Unicorn does not do continuous integration for Windows.