Notes from DeepSec 2009, day 1

While attending DeepSec 2009, I was taking notes (see also Notes from DeepSec 2009, day 2 and my other conference notes).

Technology won’t save you, only people will

Talked about the way companies think about security and handle it.
Pointed out the following problems:

• Wrong organization: "Security team" is separate from the rest of the
  organization, doesn't talk to others much, does not have much managerial
  support ("those are the guys who say no all the time"), the team can not
  actually control the network.
  
• Belief technology will solve security: Using "one product per problem"
  (anti-virus, anti-spyware, firewall, IDS, patch management..."). Time is
  spent making the products work, not making them effective or relevant.
  
• Wrong people: "One product per problem" leads to "one person per
  product", employing administrators who don't know anything about the bad
  guys (how they work, what and how they do).
  
• Meaningless rules (which don't improve security, don't match the specifics
  of the business, prevent experimentation, create more silos that don't
  talk to each other):
  
  
  
  • Patch windows (guarantee computers will be vulnerable most of the time)
    
  • Anything can be installed on client workstations, servers are strongly protected
    (but clients are the main attack target).
    
  • Password complexity rules (passwords get written down on paper, or even
    worse in an unencrypted text file)
    
  • IT controls firewalls, preventing security team from reacting quickly
    to attacks.
    
  
  

In summary, security teams are "trying to solve problems with process" and distribute
responsibility throughout the organization ("it's your fault you had a
simple password, we told you not to")

Had the following suggestions for handling security:

• Allow people to experiment - let them fail often, identify the failure
  quickly and recover quickly
  
• Security team should talk to everyone (internal communications - to
  present the rules everyone should follow, IT, finance, ...)
  
• Hire:
  
  
  
  • Analysts to think about avoiding attacks, not just detecting them
    
  • IT/network guys inside the security team
    
  • Code developers - for product customization
    
  • "Bad guy equivalents", who can write exploits
    
  • People who can talk to other departments, and other vendors (many of
    their customers with paid support never call)
    
  
  (Summarized by one participant as "hire people like me".)
  

Unrelated to anything else: A fuzzer can reportedly find a crash in MS Windows Media player in 45 minutes on average—and it found one during the talk.

Top 10 Security Issues Developers Don't Know About

Presented various problems they found during code reviews, vast majority Windows API-specific:

• Socket hijacking: More than one socket can be bound on a single port (one `INADDR_ANY`, one with a specific IP), allowing an attacker to intercept connections.
  

  Countermeasures:
  

  
  
  • SO_EXCLUDEADDRUSE
    
  • Use privileged ports (enforced by >=XP SP2)
    
  
  


• Named pipe hijacking: An attacker that creates a pipe before the legitimate server can intercept connections. Server can seamlessly run with the privileges of the pipe client, allowing an unprivileged attacker to escalate privileges by hijacking a pipe.
  

  Countermeasures:
  

  
  
  • Open pipe only if it doesn't exist in the server
    
  • SeImpersonatePrivilege is granted only to administrators in recent Windows releases
    
  • Client can prohibit impersonation
    
  
  


• Insecure mutex/event creation: Attacker can create a mutex or an event before the legitimate users and can DoS the users.
  

  Countermeasures: open object only if it doesn't exist (is it always possible?)
  



• Insecure cipher mode: ECB leads to information disclosure.
  
• Insecure/missing integrity checking, particularly with automatic updates.
  Checks may exist, but be weak, or not protect the hash/signature
  
• ActiveX controls: scripting-enabled controls can be executed by unexpected sites.
  

  Countermeasure: use Site Lock (tie to a specific web site)
  



• 3rd party components: integrated in application and never updated since.
  
• Thick clients: authentication or data validation may be done only in the client, clients may be running with administrative privileges
  

Ownage 2.0

Various, only loosely connected topics:

• URL shorteners make answering "Is this URL safe to visit?" difficult:
  point unsuspecting users to an URL sortener, which redirects to an proxy
  script, which redirects to an URL containing an exploit / attempting to
  crack a server.
  
• Searching for SQL injections: google inurl:.asp && inurl:?a= , then just
  try each one
  
• Suggestions for changes:
  
  
  
  • Make HTTP stateful.
    
  • Allow web applications to limit itself ("there will be no external
    scripts or images")
    
  
  

A Proof-of-Concept Attack on SmartCard-secured Online-Banking

Demonstrated an attack on an USB smart card reader without an integrated PIN
pad or display, by intercepting the PIN and authenticating a different request.

Some vulnerabilities in the particular implementation:

• Computer used to enter PIN and display authenticated transaction
  
• The smart card reader includes an obsolete, vulnerable Firefox
  
• Firefox configuration contains vulnerable CAs, can accept MD5-signed
  certificates
  
• Debug strings left in the code
  
• Software "hardened" by checking redirection of some API functions, but
  the check does not check functions it uses itself
  

Suggested countermeasures:

• Use a picture instead of text—supposedly makes it more difficult to
  intercept/modify data?
  
• Use better code integrity checks
  
• Use a smart card reader with an integrated PIN pad and transaction display
  

Key Management Death Match: Competing KM Standards Technical Deep Dive

Provided a general overview of key management standard proposals.

• KMIP: in scope "just about everything", except for implementation. A
  binary protocol, there are some plans for an XML variant. KMIP has
  provisions for unique identifiers across more than one management system.
  
• IEEE 1619.3: scope is "protection of stored data". Defines {architectural,
  lifecycle, conceptual, sequence, object, operation} models—only a set of
  "use cases", does not define a protocol (some plans to adopt e.g. KMIP).
  Defines a km:// URI format for all objects.
  
• EKMI: in scope symmetric keys only. Protocol: SKSML, Mobile-SKSML
  (open-sourced an application-specific protocol). Targeted for application
  integration, not much for HW security modules. Defines all components
  necessary to make the exchange secure, depends on a PKI for authentication.
  
• IETF KeyProv: in scope provisioning of symmetric keys, based on RFC 4758
  (crypto token key initialization protocol). Defines 2 protocols, 1 key
  format; not architecture, nor use cases/actors. Only sporadic activity.
  
  
  
  

  Overlap between the standards:
  KMIP, IEEE 1619.3 can be used for storage key management. KMIP, IEEE 1619.3 support hardware security module integration. Financial use cases are largely ignored in all standards. (Very unusual key types (e.g. "triple" DES with only 2 keys), unusual key derivation (for PIN blocks) are not currently defined in the standards. Financial vendors
  are on KMIP committee, but don't talk about products that would handle these
  use cases.)
  
  

  Encryption transfers the business value [that needs to be protected] from data to keys.
  
  

  Windows Secure Kernel Development

  
  

  Presented various examples of vulnerabilities found in Windows (heap overflows, ToCToU mistakes).
  
  

  Tools provided by Microsoft for free:
  

  
  
  • WDK contains an IOCTL fuzzer.
    
  • Driver Verifier: providesa "special heap" for detecting over/underflows, handle
    verification.
    
  • Static driver verifier (compile-time)
    
  
  
  
  

  Results of a security assessment of the TCP and IP protocols and common implementation strategies

  
  
  

  Presented work on their grant to document all known vulnerabilities in
  TCP/IP and common vulnerabilities in implementations; vulnerabilities in
  protocols are reintroduced in copycat protocols (IPv6 provides source
  routing), vulnerabilities in implementations are reintroduced in
  implementations written from scratch. (Nothing particularly new.)
  
  

  
  

  • "Naphta" - open many TCP connections to exhaust memory for TCP states;
    there is no clear difference from legitimate heavy load
    

    Countermeasures:
    

    
    
    • Per-user, per-process connection limit.
      
    • Limits on number of connectsion from single prefix/IP (application
      level or firewall, e.g. BSD pf).
      
    
    
  • FIN-WAIT-2 flooding: After one-sided close (e.g. POP3: connect, send QUIT, keep socket
    open - server will shut down the sending side) there's no limit on the
    time the connection can be kept open. If a process closes()s its
    socket, the state is kept in kernel only and can't be controlled from
    user-space any more.
    

    Countermeasures:
    

    
    
    • Limit FIN-WAIT-2 state time (Linux 2.4)
      
    • Limit number of TCP states with no user-space process attached
      
    • Keep the socket open in user-space (shutdown(), not close()), and
      manage it in the application
      
    
    
  • Socket send buffer DoS: waste peer's memory on retransmit buffers. Send a request, and either never ACK the response, or close the receive window.
    

    Countermeasures:
    

    
    
    • Measure sending progress in application
      
    • Limit send buffer size
      
    • Per-user, per-process limits, per-source limits
      
    • Use the above criteria (and others, e.g. "small amount of data was
      exchanged in total") to select which sockets to drop on OOM
      
    • Limit time with window set to 0 (easy to bypass)
      
    
    
  • Reassembly buffer DoS: intentionally skip a segment when sending, the
    receiver will keep the following segments in memory; can also exploit
    wasteful implementation (e.g. allocating a page even for a 1B segment)
    

    Countermeasures: simply discard the received, unACKed segments
    

  
  
  Also proposed using standardized TCP behavior and options to avoid OS fingerprinting.
  
  

  Stoned déjà vu—again

  
  

  Presented a rootkit that activates via an infected MBR, runtime-patching
  programs throughout the boot process (searching for code signatures that
  mostly don't change across Windows versions).
  
  

  Mentioned defeating the TPM by using HW breakpoints to intercept code in
  BIOS (when clearing memory, don't clear the malware; when reading the boot
  for measurement, read the moved original), and rebooting to clean TPM state
  (I didn't catch any discussion of keeping the HW breakpoints across the
  reboot.)
  
  

  Night Talk: The Threat Landscape: The Reality vs. The Hype

  
  
  

  Various notes from an AV vendor perspective:
  

  
  
  • Counting unique pieces of malware doesn't make sense; roughly 95% is not
    replicating, and more than 90% is just obfuscated to avoid detection.
    
  • Rootkits are "so common that McAfee has stopped looking for them".
    
  • VirusTotal is used to guarantee malware won't be detected on release.
    
  • About 6000 new "main variants" of malware per day
    
  • New trend: "in the cloud detection": cloud database of file hashes of
    "suspicious" files:
    
    
    
    • Suspiciousness based on statistical tests (compiled recently, packed,
      autorun...).
      
    • Handles only static malware, user must be on-line.
      
    • It isn't necessary to distribute signatures, vendor can observe threat spreading.
      
    • Most supsicious files queried are manually copied via USB or the net.
      
    
    
  • Underground economy:
    
    
    
    • Main participants:
      
      
      
      • Large organized groups
        
      • Small, specialized groups (e.g. malware creators, sellers of captured
        credit card data) - "crimeware as a service"
        
      • Forums etc.
        
      
      
    • Information about bank accounts is sold for about 10% of balance
      
    
    
  • Threat vectors:
    
    
    
    • Most malware is distributed by mail (attachment or URL)
      
    • Social engineering: "download new Flash plugin for viewing video on
      'Facebook'"
      
    • Autorun: completely ignored until Conficker, only Windows 7 allows easily
      disabling it for USB.
      
    • Hacking websites only to add trojans is still done, but not that common any
      more.
      
    • SEO to get users to a trojan website is more common now
      
    • Fake antivirii
      
    
    
  • Cybercriminals are quite clueless about security: Their SharePoint, Asterisk
    servers are openly accessible on the internet
    
  • Notable attacks on banking:
    
    
    
    • URLZone: trojan, enters additioinal transactions on a banking site and
      hides them in on-line statements
      
    • ZeuS: delays user's login (by adding various security verification
      questions) to give a human time to enter a transaction using
      human-provided TAN