DEFCON 21- Day 4

August 4th at 12:00am

I didn't have time yesterday to write up my summary (The 5 hour drive home took up my afternoon). Sunday @ DEF CON was a bit more subdued than Saturday with fewer people moving more sedately. Still had some good sessions, though.

  • 10:00 - The Cavalry isn't coming: Starting the revolution to fsck it all!
    • Nick from Spider Labs at Trustwave
    • Josh from Akamai, Director of Security (Sounds like he is a 'philosopher hacker', too)
       
    • When Nick and Josh began their presentation I could tell that this wasn't just another security presentation at DEFCON. They are trying to start a conversation around how to better involve our community in government and with policy makers. Upfront they said that their presentation isn't fully formed and they are trying to involve others in their movement.
       
    • IT and technology are permeating our every day lives, even in places where it possibly should not be like Insulin pumps with insecure bluetooth stacks. Most people implementing the technology are doing so without security in mind. It's all pretty much hackable and insecure. When your life or the lives of those you love are are impacted by the performance of these devices it becomes a matter of great significance

      We should be asking ourselves how we can hack our personal lives and our freedoms
       
    • At this point Nick shared a few Dreams/Nightmares/Potential visions of the future he recently had:
      • Dream #1: He was on a bus with a number of other people on their way to get their Federal Software Developer licenses. One guys had expired, others were going in for the first time.

        The idea that the government can control who has access to Hardware and software tools is a scary one
         
      • Dream #2: He woke up and found a newspaper outside his door. The headline was that a Florida man was arrested for posession of Hacking tools (Nessus, nmap, metasploit).

      • Dream #3: He was in Chicago and went down an alley to the end where he found a door. After ringing the doorbell, he we let inside the apartment complex and went up a few flights of stairs. Entered an apartment where there was a makerbot, some electronics an a number of people hanging out. One of the people told him that the meeting was just about to begin and handed him a beer. At that moment, the lights went out and the 'Authorities' came in and busted up their meeting, zip-tied their hands and led them out.

    • The takeaway from this is that these dreams are potential futures if you extend current policy making. When you think about it something like DEFCON could be outlawed in the future if the decision makers fear security hackers enough.

      What would happen in a world where security research was criminalized? Look at Texas, Brazil Britain and Germany for laws on the books that could lead to these kinds of futures
       
    • When Powerful people are uninformed, they make powerfully uninformed decisions.
       
    • People don't tend to change unless they hit rock bottom. We tend to call it 'burn out'. When we lose what we have always had it causes us to re-evaluate the world around us.

      If we don't see 'good things' in the world then we can put them in. Maybe there isn't evil, only an absense of good. Nature abhores a vacuum- time to fill the leadership vacuum by joining the cause! 
       
    • The EFF is there and it is good, but we need something more. They suggest doing some 'uncomfortable experimentation'
       
    • They made a few big announcements:
      • Forming a 501.3(c) Think Tank for research so the Security Researcher community can have Subject Matter Experts that can talk to congressmen, courts and the public. Right now there is fragmentation in both Amicus Briefs to courts and other venues. It looks like there are varied opinions to the policy makers who look into matters of technology and security
      • In 8 weeks they will be holding a "continental congress" for hackers and security experts to cement processes for the movement
         
    • Here are some of their thoughts on why they want to do this:
      • With an organization like the AMA or American Bar Association, the Security community can gain credibility, respectability and professional reputation.
      • We have some of the best social engineers in the world- why not put those efforts into something constructive that can get the message out. This isn't about manipulation so much as it is about leveraging the talents that each one of us have to move things forward. We need good PR
         
      • What we do, how we dress, what we say, etc... impacts other peoples. We don't exist in a vacuum. When people from our community are placed in front of global governments they see a hacker not an expert. This movement is trying to address that by putting the right people in the right places to get the message in an understandable form to the people who make decisions.
      • This effort helps to coordinate different voices so we don't come across as a divided community on key or important issues of policy
      • Breakers are important, but we need fixers too (Not militants!)
      • We need representatives from various industries who are also into security research (Auto, medical, etc...)
      • Individual researchers can't get through red tape. Together we can.

    • What differentiates you? Finding the 700th piece of android malware? Try branching out and doing security research where it matters.
       
    • Hack the Future
      • If we can Hack 'x', then we can hack anything
      • Every one of us has a role to play to drive change
      • We should not settle for anything less than meaningful change - Proving the value of security community AND ensuring that the technology around us is secure for those we love
      • We should write secure code wherever we work- it will make a difference
      • This needs to be more than a grassroots effort, we need leaders and executives
         
    • Three Planks to the platform
      • (Body) Focus on public good and safety. Life is short, lets improve quality of life for people.
        • Pick a control system, medical device or something else to examine
        • Staves off criminalization of research
      • (Mind) Stave off criminalization of security research
      • (Soul) Preservation of civil liberties
        • Civil liberties seem to be losing out to 'safety'. We can point out that what they are trying to do doesn't gain them safety while eroding liberties
        • Evil / ignorant people are winning
           
    • The goal is an open process, no secrets and sharing results
    • There are probably a lot of problems with this approach, but lets fail fast so we can iterate our way to a good solution!
    • Case law (which we can influence) drives policy and the thought process legislators use when crafting laws. To re-iterate, we need to get into the process so existing laws and frameworks are 'tweaked' to be security friendly instead of muddying the waters with new laws.
       
    • My thoughts: Their speech really resonated with me. I want to meaningfully impact the world and this got me thinking about how to do it. Well done guys!
  • 11:00 - Resting on Your Laurels Will Get You Pwned: Effectively Code Reviewing REST Applications to Avoid Getting Pwned
    • This talk started 15 minutes early and was moved to a different room so I arrived late
      Perhaps because of this, the presentation seemed disjointed and repetetive at times
       
    • Here is what I was able to take away from this presentation:
      • REST was first theorized in the year 2000 by a Ph.D
      • In 2008 at the RSA Conference there was a talk about the insecurit of REST
      • Your JAVA based REST API may be vulnerable to remote code execution attack if it:
        • Uses the built-in JDK XML Decoder
        • Uses the XStream XML Decoder
        • Uses XXE

          XStream (according to the developers) isn't meant for a REST API and the built-in decoder is just insecure.

          You can potentially pass in an arbitrary XML file that describes a 'process builder' object and kicks it off to run arbitrary code. In the demo they showed how a REST service would open calc.exe when a malicious XML was transmitted.

          This was pretty darn interesting!
           
      • Your REST API could be designed to be compromised if it allows for dynamic creation of resources based on URLs created on the fly. For example:
        • Mongo DB can dynamically generate new DBs when arbitrary URLs are entered
        • Even if you have have ACLs setup to protect certain DB URLs, people can still get in if they try to hit a different DB URL then use HTTP Path Traversal to hit your production database
        • Attackers could try to use the '_method' parameter to make GETS seem like POSTS or PUTS and get around restrictions placed on HTTP Verbs. 
        • Once your DB is accessible, there are REST APIs available to copy data out of the system to some arbitrary HTTP endpoints (Data Exfiltration)
           
      • When Implementing a REST protocol, keep in mind how pervasive HTTP REST APIs are both Inside and Outside your network. You probably have REST APIs accessible outside that are on systems hosted inside your network (The presenters consider this to be an Inbred Architecture.
        • Some attack methods that work on Externally facing APIs could be usable internally once attackers break into your network. Moreover, External APis often call Internal APIs to gather data to return to the outside rcaller.
        • Since REST is self-describing and predictable, once an attacker is 'in' they can easily detect REST traffic and servers that have REST services
           
      • Reliance on incorrectly or poorly implemented protocols or helper functions when writing a REST API
         
      • Concatenation issues
        • If a developer uses concatenation to assemble a URI that has user-entered input, you could be in trouble
        • A URIBuilder should be used to prevent malicious users from using the _method parameter to change the HTTP Verb to an unexpected type which generates unexpected or unanticipated behavior
           
      • HTTP Is pervasive, it is hard to block REST Attacks by protocol since HTTP is used by everyone for just about everything. Malicious traffic can hide inside HTTP

      • The Presenters recommend reading a talk titled Are You my Type? Breaking .NET Through Serialization that was presented at Black Hat 
         
    • I can tell that the presenters are very well informed about the topic and are very excited to share what they know. With that said the presentation was a bit hard to follow for someone who came in late and doesn't build web-apps every day. I'm glad I attended, as hearing about a topic from someone excited to share helps me open new mental pathways to process and evaluate security information.
  • 11:00 - The Dark Arts of OSINT (Open Source Intelligence)
    • I caught the last few minutes of this presentation and was intrigued.
    • The presenters were talking about 'Information Entropy' and how seemingly innocuous information that is collected from people in bulk can be personally identifying. They used VEN Diagrams to demonstrate this, illustrating how the areas where the circles overlap indicate which people can be identified by the overall set of information collected
    • Mathematical attacks can de-anonymize information. The bigger your dataset the larger the problem.
    • There is no real way to anonymize information. You will be identified eventually.

    • This was a thought provoking talk- I wish I would have attended it in its entirety! 
  • 12:00 - EMET 4.0 PKI Mitigation
    • EMET stands for The Enhanced Mitigation Experience Toolkit
    • It is a free tool provided by Microsoft to mitigate exploitation techniques that malicious hackers may employ
    • It is divided into 2 parts: A dll and a local agent. The DLL gets loaded and monitors participating applications (This is not a blanket-security solution: It is targeted to those applications that choose to participate)
       
    • Features:
      • Memory Corruption Protection
        • DEP can be selectively enabled on processes
        • HeapSpray protection which reserves memory
        • Mandatory ASLR that prevents things from loading at the same address space by tracking where it normally loads.
        • The Null Page (address 0x00000000) is reserved to prevent null pointer bugs
        • Export Address Table Filtering to prevent Shellcode from exporting address table
        • Structured Exception Handling Overwrite Protection which checks to see if the previous pointer is negative 1 (-1). If this is not seen, then there is corruption
        • ROP (Return Oriented Programming) protection. This is a technique that allows attackers to inject a controlled callstack
           
      • PKI Mitigation (Brand new feature in v4.0 of EMET)
        • Limitations
          • Only works for SSL/TLS connections right now
          • Only checks root certificates and end certificates (No Intermediates)
          • This is a static tool, does not update via windows update. This means that if a company changes their root cert, EMET won't know and will throw messages to the user until the tool is updated
          • Watch out for false positives as 2 Certificates could have the same keypair and name, but a different serial number
             
        • Functionality
          • PKI Certificate Pinning for certs in a CAPI store. This was a new concept for me: Rather than check the cert chain back to the root cert, you say I only trust the cert with *this* public key. I think the presenter said you can pin to public key or Subject(?)

            Right now EMET Only pins to Root Certificates
             
          • Chain of trust analysis for end certificates to ensure they make it back to the correct root signing authority
          • Detection of MD5 certs (Very bad if you have them, insecure)
          • Can selectively choose which countries of origin you trust
          • Can filter based on a bit strength (Can set a minimum bitstrength)
             
    • Architecture / how it works
      • Uses Interprocess communication to processes that are enabled with EMET support
      • Agent runs locally, shows up in the system tray
      • Minimize dependencies, EMET should stand as alone as possible

      • Whenever CAPI is loaded, the PKI mitigation kicks in
      • PKI stuff works by checking the Serial Number and Subject
      • PKI Stuff can work with user set rules, or with applications that participate in EMET. For example, Skype.exe would be expected to communicate using only certain certificaets

      •  
    • Demo
      • He got EMET running on a VM
      • Accessed live.com (no error)
      • Ran a local IIS site that has a live.com cert that is not the same as the official MS one
      • When loading that page, EMET complained to the user even though the fake live.com cert chained back to a cert in the trusted store
         
    • Thoughts:
      • PKI is under attack! Take proper precautions
      • While EMET looks cool, it is limited in scope right now. This limits its effectiveness in terms of percentage of apps that can take advantage of the protections EMET offers. However, if you rely on anything that is EMET compatible it might be worthwhile to try it out. :)
  • 13:00 - Fast Forensics Using Simple Statistics and Cool Tools
    • John Ortiz crucialsecurityblog.harris.com
    • Malware, Demo applications and poorly written applications sometimes leave 'droppings' behind on your system that have unknown contents. How can you determine if a file has compressed content or encrypted content?
    • The Presenter has put together some tools that will eventually be up on the defcon media server (http://dc21-media.defcon.org/). Here are the names of some of the tools he mentioned:
      • File Type Checker - Determine file type based on more than just the extension
      • xvi32 - Hex Editor, special purpose
      • Statistical Analyzer - automates the analysis of files and creates histograms and other stuff
      • footprint - Takes snapshot of file system, registry, running processes and services. Lets you diff environments
      • A tool to write bitmap histograms. This was inspired by a tool to visualize network traffic
         
    • Malware likes to hide, so statistical analysis can be helpful in identifying 'weird things' on your system that you should take a closer look at as a security researcher
       
    • Statistics comes in handy to determine if unexpected data is hiding in a file (Steganalysis)
      • Files of certain types can have characteristic distributions of bytes.
      • You can use the entropy of a file to determine if the data within the file is representative of the type. If Entropy is higher, the file could be compressed or encrypted. Weak encryption often looks like compression when you analyze a file.
      • Higher entropy means more uncertainty which is good for encryption
      • You can hide data in bitmaps, but it will be noticed with good statistical analysis. Bitmaps normally have a 'smoothness' to their histograms. if you notice spikes or plateaus, it means something is probably up with the file...
         
    • When analyzing a file to see if you can decode/decrypt the contents, you can start with a simple XOR system. XORing the data can help you find obfuscated text or other data that has been weakly encrypted. Malware often uses XOR.
  • 13:30 - Utilizing Popular Websites for Malicious Purposes Using RDI (Reflected DOM Injection)
    • My understanding of 'RDI' as presented during this session is that someone can create a malicious site that only 'triggers' under the condition of being accessed through a web cache or some type of web service.
    • They demonstrated this in one of their demos by:
      • Creating a malicious wordpress blog
      • Letting google cache it
      • Removing the malicious code from the blog
      • Accessing the blog via google cache and having the malicious javascript run

        The javascript is a simple loader which decodes a blob of data on the page into javascript (using simple/weak encryption, more like obfuscation) and using eval to process the decoded JS.

        The JS only runs when it detects page elements that Google cache injects when displaying the page from cache 
         
    • They ran a similar experiment using google translate, in that case the JS looked for a page element that was specific to google translate before triggering the JS payload
       
    • There are a few reasons why someone might want to use this technique:
      • Only want malware to trigger in very specific circumstances
      • Only want malware or other code to trigger when a USER is accessing a page through a webservice. (When a webservice loads the page, it doesn't see the stuff it injects when displaying to end users).
      • People trust webservices - if you do something like this you could slip in past someones defenses with a link that they think is 'good' (since google does checks for malicious pages) when in reality it is hazardous to their computers health
      • Obfuscation: This may obfuscate and make an attack more difficult to detect when looking at a complex web page. You'd have to identify the payload and JS loader to do anything about it. There's so much going on in a typical web page these days that this can be very time consuming
         
    • This is an intriguing idea. I'm not sure if it is an 'exploit' necessarily, as it is just a technique to target the execution of code to circumstances when you want it to execute.
  • 14:00 - Blucat: Netcat For Bluetooth
    • Homepage for blucat: blucat.sf.net

    • What is Blucat?
      • Debugging tool for bluetooth applications
        • Useful for fuzzing your bluetooth app
      • Device exploration tool
        • NMAP-like functionality
        • Helps in reverse engineering things
      • Component for building other applications or complex scripts
        • This lets you ignore the transport layer and focus on busines logic

           
    • CLI
      • Syntax is like netcat
      • blucat -url btspp://MACADDRESS:Port will try to connect to a device on a given port
      • blucat devices command will do a scan for devices that your device can see
      • blucat services command will inspect devices and scan for running bluetooth services
      • blucat scan MACADDRESS_HERE will do a brute-force scan of every channel for the device specified
      • blucat -v -l -e /bin/bash will setup a listener that dumps to bash when data is received over a port (-e flag)


    • URI Monikers & Protocols
      • btspp    -  btspp://MACADDRESS:PORT  -  This is a bluetooth serial port
        • It is modeled after RS232
        • Like TCP it has the concept of 'retry' and packet reordering and reassembly
        • There are 30 ports available using this protocol
           
      • btl2cap - Buffers of a fixed size are transmitted between devices
        • It can be made unreliable like UDP. 
        • It has a max 'packet' size of 673 bytes
        • Way more ports than btspp (like 65k ports)
      • btgoep - Generic Object Exchange Protocol (used when transferring files)

         
    • Inspecting & Scanning for Devices
      • Bluetooth has 'profiles' identified by UUIT and Device Class
      • They build on the protocols mentioned above

        Note: Bluetooth doesn't really send back error codes. You're kind of on your own to figure out why something 'isn't working'
         
      • You can try passing Bluetooth AT Commands when connecting to a new or unknown device to see what it does and what it has available (if you can get a serial port)
      • Pretty much have to try scanning and passing commands to see what you can do. Modern equipment is generally more secure (unless it's a medical device, unfortunately :( ).


    • Architecture
  • 15:00 - PowerPwning: Post-Exploiting By Overpowering PowerShell
    • Joe Bialek, Microsoft
    • A few words on Powershell:
      • Powershell is an incredibly powerful CLI based console which is designed to replace the old command.com and cmd.exe prompts available in versions of windows prior to Vista. It is well equipped to assist in managing an environment filled with Windows servers.

        The Presenter hopes that we still use powershell after what he shows us today. :)
        I agree that it is a great tool, and in my mind what he presents here is more of a 'feature' than a bug. The catch is that admins have to understand this tool to know how/when/where to lock it down. If an attacker can get sufficient privileges and run powershell they could do malicious things which don't leave a log record behind.
         
      •  Powershell gives you access to the Win32 API along with .NET. This was news to me as I had used .NET classes in Powershell but never tried any Win32 stuff!
         
      • Powershell has a robust remoting API. While remotely executing, scripts never touch the file system (only touches ram).

      • Processes and threads invoked by powershell run in either the  powershell.exe process (local) or wsmprovhost.exe (remote). You can run existing tools in powershell using reflection!
         
    • The Presenter had a couple of security tools he wanted to run remotely, so he turned to powershell to make it happen. He didn't want to rewrite his tools in poweshell, so he invoked the tools with powershell. It took some doing, hence the worthiness of this presentation :)
       
    • He had to do this to get it to work loaclly:
      • Load dlls
      • Call the exported functions (which contain your payload)
      • He only had to rewrite minimal amounts of code to get this to bootstrap in powershell
      • EXEs loaded reflectively will kill the powershell.exe process unless you rewrite the ExitProcess() function to really execute ExitThread (since everything started by powershell gets executed in the powershell process)
      • If you want to reflectively load an EXE and pass in CLI arguments you need to fix __getcmdln() and getcommandline(). getcommandline() can be overwritten whereas __getcmdln() is harder (multiple dll locations). He had to check the dlls and found __acmdln and __wcmdln variables which hold the args that he can manipulate directly with his own arguments

      •  
    • For REMOTE execution things got more complicated:
      • Remote powershell can't capture stdout
      • He had to make a char* or wchar_t* pointer to pass back (Powershell can marshal a pointer to a managed string and print things out. WHICH IS PRETTY DARN AWESOME!
         
      • To reflectively load DLLs remotely he had to:
        • Allocate memory both in the local powershell.exe process and the remote process
        • Load libraries
        • Stage the libraries in the local powershell's process (dependency check), then load them in the remote process
        • Write the bytes to the remote process
        • Create a thread remotely and begin DLL execution
           
    • For the demo, the presenter ran mimikatz remotely (yay it worked!) against a Windows 2012 host.

    • Detection and Prevention:
      • Powershell remoting requires Admin access and Open ports
      • Powershell pipeline logging *might* help detect this type of thing (new in Powershell v3.0), but an attacker could just turn this off or clear the log if they have admin access
      • Constrained runspaces could limit the attack surface by limiting what commands a user can run (Ban Win32 and .NET for example)
      • Machine wide profile to log actions could catch this, but an attacker could turn it off, too.
         
    • My thoughts:
      • Considering that Powershell is included by default with many versions of windows that ship since 2006 and that it is still 'relatively new' and not well understood, there is a space for this to be used maliciously.
      • Admins will have to deal with this added functionality and complexity like they do every other tool they deal with: Add in appropriate permissions and implement security best practices (lock down, turn off, limit or disable)

Final thoughts for Day 4 (and the conference as a whole):

I really enjoyed myself and will be attending again in the future! Even though some of the talks were poorly formatted, I gained perspective from each one. Now we'll see if I can convince my employer to reimburse me for the trip (We are trying to do more 'security' stuff, so it should be relevant!).