Security

TODO Nemesis: Preventing Authentication & Access Control Vulnerabilities in Web Applications -zeldovich

resources

  • magic string from skipfish: -->">'>'"<sfi000142v524891>
  • http://www.cs.berkeley.edu/~daw/teaching/cs261-f08/
  • 20 Critical Security Controls: A very good list of control areas that are considered most “important”. If you don’t already have an existing security program, this would be a good starting point. http://www.sans.org/critical-security-controls/
  • US Government Configuration Baseline: Provides baseline configuration standards for different platforms. It’s used by most government agencies.. http://usgcb.nist.gov/usgcb_faq.html#usgcbfaq_usgcbfdcc
  • Center for Internet Security: Provides baseline configuration standards for many different devices / platforms. They even have a cloud infrastructure benchmark. http://benchmarks.cisecurity.org/
  • OWASP ASVS

everything you need to know about cryptography in 1 hour (talk by collin percival)

  • hashing
    • ideal hash function: collision-resistant & one-way; nothing else
      • collision-resistant: hard to find 2 inputs w same hash
      • one-way: hard to find input given hash
      • nothing else: in particular, knowing H(x) may let attacker compute H(y) for some y, so simple hashing in itself is unsuitable for authentication/signing
      • don’t use for symmetric signing
      • use SHA-256 (SHA-2); consider SHA-3; avoid MD2, MD4, MD5, SHA-1, RIPEMD
    • symmetric authentication aka symmetric signing: uses MACs
      • ideal MAC f_k(x) uses key k to map any-len input to n-bit output such that even if you know a (x, f_k(x)) pair, it’s hard to generate another (y, f_k(y)), unlike in hashing
      • avoid having 2 msgs result in same data being input to MAC; ie take care w delimiters, don’t simply concatenate things
      • use HMAC-SHA256; avoid CBC-MAC, Poly1305
      • don’t leak timing side channels when verifying signatures (no early returns)
    • side channels: timing, EM emissions (TEMPEST), power consumption, microarch features (caches, HyperThreading)
    • block ciphers: TODO
    • TODO finish
  • http://www.bsdcan.org/2010/schedule/attachments/135_crypto1hr.pdf
  • http://blip.tv/file/3627639

conferences

  • cansecwest: very respected
  • derbycon
  • ccc
  • defcon: culture
  • blackhat: popular

people

  • michal zalewski: google security person, wrote browsersec book among tons of other literature/tools
  • jeremiah grossman: prominent web security blogger; leader of whitehat security, purveyor of web application firewalls
  • theo de raadt: openssl, openbsd
  • mark dowd: amazing; ibm x-force team; taossa book; nacl exploits; flash null ptr exploit
  • mark miller: exploits, reveng, rootkits; joined windows 8/2008
  • james whittaker: testing; joined windows 5/2006; joined google 6/2009
  • crispin cowan: stackguard, immunix, subdomain, apparmor; joined windows from novell 1/2008
  • michael howard: windows security team lead
  • niels provos: principal engr at google; libevent, libio, openssh privsep; malware work

industry

pen-testing firms

  • iSEC
    • research shared with isec, ngs, intrepidus, matasano
    • lend people to each other if short of specialization
    • 40-50 consultants
    • hit rate? >90%
    • reference customers? MS (most large products), google (early android), salesforce
    • start with interviews, then maybe email every couple days
    • better bang for the buck
  • Matasano
    • very well known, probably one of best
    • known expensive: $10k for a week ($2k/day)
    • code auditing: interviews with developers, etc.
    • can also do architectural/infrastructure review, or network pen test
    • 20-something consultants
    • no social engineering unless there’s a signed contract, but usu just assume infrastructure, OS, etc. are safe
  • stach & liu aka bishop fox
    • 30-40 emps
    • pen testing and/or network architecture review
    • code auditing either fully thorough or done with “candidate point analysis”: review guided by scanning; find potential issues with regexps and patterns
    • hit rate: near 100%
    • also do compliance prep
  • IO Active
    • vuln scan: mostly Nessus
    • pen test: more hands on (75% manual)
    • suite at RSA conference at St Regis Tue/Wed 10-8p (happy hour Wed)
    • compliance: PCI DSS, ISO 27001
    • very large, do lots of outsourcing
    • $9-18.5k for 1-2 weeks/small pen test
  • Mandiant
    • $14k/week ($350/h)
    • interview devs, figure out work, see code, pen test
    • mostly incident response/forensics
  • other recommended options
    • gotham digital science
    • core security
    • include security: small firm, intentionally no employees and all on-demand contractors
    • immunitysec.com: Dave Aitel and his team are good at security reviews/tests. They’ve done a lot of different things though they are most famous for their Windows expertise
    • offensive security: specialize in pen testing
    • accuvant: has a bunch of good sec guys; do review/pentests
  • book well in advance for reasonable discounts

certifications

  • SOC
    • Numbers
      • SOC 1 aka SSAE 16
      • SOC 2: full detailed report - most enterprise customers demand this
      • SOC 3: same as SOC 2 but only a summary
    • Principles
      • Available: security, confidentiality (deeper), privacy (deepest), availability, process integrity (correctness)
      • Recommended for us: security and confidentiality
    • Type 1 vs Type 2 reports
      • Type 1: point-in-time; much weaker
      • Type 2: over a period of time
        • Most enterprise companies demand this
        • Min 3 months but most companies want 6+
        • Can look back historically or start from this point in time out
        • Companies want annual reports; not just a one time thing
  • ISO 27001: much deeper/harder
    • firms can do ISO-like assurance instead
    • ISO is a superset of SOC 2
  • firms: Brightline, Linford Co, Big 4
  • PCI

vulnerability databases

  • MITRE Common Vulnerabilities and Exposures (CVE)

misc terms

  • side-channel attack: exploits physical implementation (vs. brute force or theoretical weakness); in crypto
  • covert channel: channel that draws BW from another channel; in info theory
    • eg timing attacks: latency tells you whether logged in, whether query succeeds/fails (document contains term), how much of password you match (page-aligning password), etc
  • drive-by download: browser (or extension) exploit triggered on simply displaying a page
  • security assurance techniques: pentesting, code review, platform defenses, training, architectural/design analysis
  • advanced persistent threat (APT): eg chinese gov attacking google

security models

  • clark-wilson integrity model: semi-formal model
    • 2 categories of data, known-good (trusted) and unknown (untrusted)
    • mandatory checks to filter data before moving it from unknown to known-good
    • mandatory checks that data must be in the known-good state before it can participate in sensitive ops
    • eg: virus scanner than forces checking of all files as they’re opened
  • bell-lapuda (BPL) privacy model: formal model and policy
    • “data diode”: info only flows in not out; useful for eg CIA
    • label-based access control; formal models of security allow for proofs
    • hugely influential in academic security research
  • biba integrity model: dual of BPL model, for integrity instead

high level exploit classification

  • confused deputy: fool a privileged process to do things for you
  • arbitrary code execution: take over and do things yourself

access control

  • discretionary access control (DAC): subjects can xfer perms to others; decentralized
    • commonly in practice: objs have owners who controls perms
    • capability systems: subjects can xfer perms to others
  • mandatory access control (MAC): policy controlled by admin only; centralized
  • role-based (RBAC): restrict system access to authorized users
    • newer alt to MAC/DAC; can sim MAC/DAC
    • users are assigned particular roles; roles are assigned permissions
    • basically, roles are a level of indirection
    • qualitatively/typically, more fine-grained than ACLs, enumerating specific high-level operations

integrity control TODO

security

  • confidentiality: aka privacy, secrecy
  • integrity: eg phishing, MITM, hijacking, forgery
  • availability: eg DOS

incorrect/missing MIME type exploits

  • from http://code.google.com/p/skipfish/wiki/KnownIssues

    Missing or mismatched MIME types on any files with user-controlled contents may easily lead to cross-site scripting flaws. This is because of browser content sniffing logic, a problem is particularly pronounced in Microsoft Internet Explorer - where even something as subtle as returning image/jpeg on a GIF file may cause HTML detection to be attempted, possibly interpreting any HTML stuffed in the EXIF fields of an otherwise valid image.

  • example from http://osvdb.org/show/osvdb/54773

    Simple Machines Forum contains a flaw that allows a remote cross site scripting attack. This flaw exists because the application uses the incorrect MIME type ‘image/bmp’. The unknown header triggers MIME sniffing in Internet Explorer, allowing an image to be falsely identified as text/html. This could allow a user to create a specially crafted image that would execute arbitrary code in a user’s browser within the trust relationship between the browser and the server, leading to a loss of integrity.

S/MIME: TODO

  • http://en.wikipedia.org/wiki/S/MIME
  • http://weblog.infoworld.com/udell/2004/03/23.html

C++

  • new/delete[]: if eg you have an array created with new[] and then accidentally delete[] a pointer not pointing to the head, then you can overwrite in the previous element the mem that delete[] treats as the length field
    • gcc: delete[] consults vtable of each object indepdently
    • msvc: delete[] consults vtable of first object only
    • harder on msvc, but can still do interesting things if eg dtor itself does anything interesting with the object data, eg free a pointer or set a value
  • new[]/delete: you can cause coalescing by setting the prev bit in the malloc header, among other things

high-level code injection, encoding/parsing vulns

  • unescaped input
  • unicode: bad multibyte chars can bypass poor standard-library escapers/filters and validators/scanners unscathed
    • dynamic langs like sql and html/js
    • specific case of parser errors
    • eg: UTF-7
      • can encode ascii, eg +ADw- for <
      • IE interprets html/javascript using UTF-7 by default, and others use UTF-7 if a UTF-7 encoding appears anywhere early on (hence, title, meta, etc are targets)
      • need to check that all places handling this interpret it/escape it correctly, eg need to specify UTF-7 to php escaper htmlentities()
      • http://shiflett.org/blog/2005/dec/google-xss-example
    • eg: multi-byte encoding
  • parser errors: unhandled cases leading to unesacped input

sandboxing pitfalls

  • ptrace: race conditions
    • ptrace behavior: suspends thread; mon reads args (regs, mem) separately
      • monitor can rewrite syscalls
    • multi-threaded arg race (TOCTTOU)
      • A syscalls; monitor checks; B changes args
      • works only on args that are not in regs, eg ptrs to other mem (file paths)
      • heavy-handed soln: prohibit multithreading
      • soln: suspend all threads
        • only for syscalls that use such ptrs (“volatile” syscalls)
        • if block all syscalls, then deadlock
          • devs use syscalls for sync (eg read and write)
          • authors don’t know of any such pair of syscalls where one is volatile
    • another process could modify args via shared mem
      • heavy-handed soln: prohibit forking, shared mem
      • soln: or suspend all processes
    • fork-attach race
      • sandbox doesn’t immediately attach to a forked child (!)
      • forked child can secretly fork another child monitor won’t know about
      • soln: change call from fork to clone; has option to start in ptraced mode
    • FS race: trickiest; use symlinks to break security
      • prisoner does syscall involving path
      • monitor looks up path, following symlinks, to verify
      • another process/thread replaces a component in path with symlink to secure region in FS (eg user’s $HOME)
      • soln: suspend threads
    • signals TODO
      • avoid by denying signals
    • alts to syscalls
      • lcall7 and lcall27 call gates; removed from most modern linuxes
    • MITRE CVE has over 40 ptrace-related items
    • refs
  • chroot
    • TODO
    • (obv) can still make arbitrary syscalls; FS is only one part of sandboxing

web

  • flash: <embed...allowScriptAccess="always"> instead of "sameDomain"
  • HTTP parameter pollution (HPP) variants: multi-value, OOO value, malformed value, malformed request methods
  • clickjacking: tricking the user into clicking something on a target site
    • eg by loading target in transparent iframe overlaid atop an enticing button, with a form submission button positioned exactly at the right place
    • mitigations: framekiller or framebuster: check top==self

low-level exploits

  • buffer overflow
    • defenses
      • stack canaries: choose random int at process start and insert before return addr
        • random xor canaries: xor with the return addr to make sure it’s not tampered with
        • propolice: gcc’s impl; enhanced version of stackguard (never officially impl’d in gcc)
        • visual studio: /gs
      • nonexecutable stack: in windows, called Data Execution Prevention
        • NX bit: in page table entries; XD bit in intel, enhanced virus protection in amd
        • segments can be readable/writeable/executable, but modern OS’s use flat memory model (pages instead of segments)
      • address space layout randomization (ASLR): randomize codes, heap, stacks
        • against return-to-libc (arbitrary code can still detect things)
  • null pointer exploits: TODO
  • heap overflow: overwrite eg a struct’s function pointer or malloc block header
  • heap spray: give you a place to place executable code, eg if stack is NX or your overriding return addr is constrained somehow
    • spray it everywhere to increase chances of landing in it
    • common in web browser js engines
    • nozzle: msr project that uses sled detection then reduces false positive rate with “global heap health metric”
  • parser errors: unhandled cases
  • format string attacks: eg printf(untrusted_input())
    • eg use %s and %x to print data from stack or other memory locations
    • defenses: statically check format strings
  • integer overflow: unexpected number, either negative or large
    • eg size header in messages
    • controls things like strncpy/memcpy for overwrites
    • controls allocations (malloc) for large, unrealizeable mallocs that return null
    • also, arithm overflow
  • null pointers
    • as write vector: use bad alloc to get ptr = null, where app later does *(ptr + offset) = value (where offset and value are user-controlled) to write a function ptr (flash exploit)
    • if the ptr is dereferenced and fields are accessed, first prep by writing to those fields
  • return-to-libc: execute existing code via return ptr, circumventing NX
    • eg system("bash")
    • ASLR defends against this
    • techniques to make multiple function calls:
      • %esp lifting: for -fomit-frame-pointer
        • functions end in addl $LOCAL_VARS_SIZE, %esp; ret
        • after args to function, pad enough so that next function ptr is where %esp would point and thus the system would return to
      • frame faking: for programs w frame pointer
        • functions end in leave; ret
        • put in fake ebps (frame ptrs) that point to function, followed by a ptr to a leave;ret
        • the very first return should point to a leave;ret return oriented programming
  • continuation of execution: resume app normally after exploit payload

same-origin policy (SOP)

  • policies
    • for DOM access: scripts can access another page’s functions/data iff from same site (in another frame/window)
      • scripts run in context of includer, not source; can’t xhr or DOM-manip google
    • for XHR: only time when SOP restrict doc retrieval; html elements can source any domain
    • for cookies
    • for flash
      • crossdomain.xml: primarily protects access to the host containing the crossdomain.xml, specified with allow-access-from
        • careless wildcard usage opens up holes; eg flickr’s api (since isolated to a separate domain)
      • can make same-origin HTTP reqs
      • can make same-host TCP conns on any high port
    • for java: applets can only see site it’s downloaded from
      • can interact with the embedding page via JSObject API iff mayscript set in applet tag
      • DOMService API allows cross-site embedding pages to be accessed freely! with no mayscript opt-in, directly contradicting JSObject API
      • ability to send same-origin HTTP reqs using browser stack via URLConnection API; can even set Host headers or conflicting caching directives
      • unconstrained TCP connections back to originating host
    • for silverlight: mimicks flash
  • attacks against SOP: XSRF, XSS, DNS rebinding
  • rules
    • match: (domain name, app layer protocol (http/ftp), tcp port)
    • opt to communicate by setting document.domain to same right-hand fragment of current host name (eg en.example.com and fr.example.com set to example.com)
    • corollary: all subdomains are implicitly granted accessed to parent domain
  • workarounds
    • google analytics works by issuing a single-pixel image request containing all collected information
    • google maps api works by dynamically creating script tags that load on-demand javascript (data can be in JSON)
    • flash: permits cross-domain requests if allowed by crossdomain.xml on target webserver
  • threat model: defend against impersonation of user and impersonation of site
  • some operations still allowed
    • include scripts across domains
    • submit POST forms across domains
  • mitigation practices
    • escaping/filtering
    • input validation
    • http responses are variations
    • http request smuggling

ways to do cross-site communication in web apps

  • dynamically create script tags to get data
    • unsafe: response can do arbitrary code execution
  • Mozilla cross-window messaging via window.postMessage
    • receiver gets message DOM event; msg contains data, domain, uri, source
    • allows cross-site communication
    • requires explicit msg handling on target page, so less susceptible to problems than unchecked shared DOM access (pre-SOP)
  • JSONRequest: obsoleted by CS-XHR
    • like form.submit, but no auth data or cookies
  • IE XDomainRequest (XDR) and W3C Cross-Origin Resource Sharing (CORS)
    • modern alt to JSONP (but works with reqs besides GET)
    • send Origin in req (like Referer but no path)
    • require Access-Control-Allow-Origin in response; must be * or the exact page URL
    • CORS is for XmlHttpRequest Level 2, namely the Cross Site-XHR (CS-XHR) part (XHR2 bundles many features)
    • IE team criticizes CS-XHR in favor of XDR
    • spec says JSONRequest doesn’t address their requirements
  • Flash, Silverlight: similar server-side sandboxing as XDR/CORS using crossdomain.xml
  • http://blogs.msdn.com/ie/archive/2008/06/23/securing-cross-site-xmlhttprequest.aspx

web application security

  • mozilla content security policy (CSP)
    • no inline scripts, only included script files from whitelisted sites
    • no code from strings: eval, setTimeout-with-string, etc.
    • specify where content allowed from/where requests can be sent
    • see examples on https://wiki.mozilla.org/Security/CSP/Spec
  • html5 sandboxing
    • sandbox tag treats its contents as different-origin
  • session attacks to obtain session ids
    • prediction
    • capture
    • fixation: get user to use an attacker-chosen sid
  • web application firewalls (WAFs)
    • a type of IDS/IPS
    • modsecurity: for apache; supports negative & positive rule models; has core rule set; non-learning
      • very simple rules that give rise to false positives
      • users expected to tweak rules and initially use as IDS only
      • CRS
        • http compliance
        • automation detection
        • owasp top 10 attacks (sql, xss, os cmds, filenames, cf/asp/php, email, response splitting, pdf)
        • comm w trojans/backdoors that have already broken in
        • app error hiding
        • external patching

secure javascript

javascript

  • ESAPI: an encoding lib that uses declarative rules and whitelists of allowed chars

XSS (cross-site scripting)

  • exploits the trust that a user has for a particular site
  • name origins: malicious site loads another site in a frame/window, then use js to read/write data; blocked by SOP
  • now: code (html/js) injection into pages (eg forum) viewed by others (to read/write data)
    • frequently: hijack session key; send by embedding in (eg) img url
  • types
    • non-persistent aka reflected: request is instantly and transiently used (not stored) to return result, eg search engine box
      • only affects the requester, but social engineering (eg send link)
      • most common, but importance is arguable (due to soc eng requirement)
    • persistent aka stored aka second-order: request is stored & later displayed (to others)
    • DOM-based aka local: TODO
      • orthogonal to persistence
  • 80% of all sec vulns in 2007 -symantec

XSRF (cross-site request forgery)

  • exploits the trust that a site has for a particular user
  • before SOP, easy for evil.com to use XHRs to send requests to bank.com that carry cookies and auth data
  • make user’s browser send request to a site that user has active credentials on
  • examples
    • malicious site contains form that entices user to submit
      • POSTs to bank site withdrawing money
      • requires user to be authenticated
    • post img to bank site forum whose src is a GET that (eg) withdraws money
  • fixes
    • referer checking: subject to SOP implementation vulnerabilities, but more importantly referer-filtering (many enable this for privacy)
    • use nonces to make each http response-http request a challenge-response
      • as long as you use something secret to the outside world, you’re fine
      • so you can either generate random numbers
      • or you can use the session ID (or a hash of it to reduce the chances that it gets leaked)
      • GET requests are tricky because you can read the URL out of the location bar

pluggable authentication module (PAM)

  • first in linux (linux-pam from RH), but on other systems now

PKI

  • TLS/SSL certificates
    • standard: cheaper, faster; just shows padlock
    • extended: more rigorous issuing policy; also shows company name
    • CAs sell packages: single domain, n domains, wildcard (subdomains)
    • only one https virtual host per IP, since SSL is before the Host: header
  • SNI: extension to TLS that enables virtual hosting
    • client requests name of virtual domain during TLS nego
  • certificate revocation list (CRL)
    • published by the issuing CA on some periodic schedule
    • clients download, cache, check against it
  • online certificate status protocol (OCSP): check online if cert still good
    • less BW (don’t DL all), real-time
    • impl’d in major browsers
  • X509 certificate formats
    • pem: base64, with “BEGIN/END CERTIFICATE”; for DEM certs; originally for privacy enhanced mail
    • cer, crt, der: usually in binary DER format
    • p12: PKCS12, may contain both public and private keys; published by RSA
      • protected with password-based symmetric key
      • successor to PFX from MS, criticized for complexity

SSL/TLS

  • use 2kbit keys; 1kbit weak, 4kbit waste cpu
  • SSL2 insecure, SSL3/TLS1 mostly OK with care, TLS1.1/1.2 no known issues
  • use cipher suites providing auth & enc of 128+ bits
    • don’t use ADH (no auth), NULL (no enc), export key exchange suites (weak auth), suites with weak ciphers, usu of 40 and 56 bits (weak enc)
  • disable renego, prioritize RC4 to mitigate BEAST
  • performance: enable session resumption
  • use secure cookies, use HSTS
  • renego vulnerabilities: when upgrading an insecure connection to a secure one (e.g. STARTTLS) already-buffered plaintext data can slip through
    • attacker can inject prefixes into the data stream
    • eg for HTTP, everything starting from the second GET is from the client (and encrypted):

      GET /path/to/resource.jsp HTTP/1.0
      Dummy-Header: GET /index.jsp HTTP/1.0
      Cookie: sessionCookie=Token
  • BEAST, CRIME: TODO
  • advanced: pubkey pinning, fwd secrecy
  • https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.0.pdf

MAC and Hashes

  • MAC: integrity and authenticity; protect against chosen-plaintext attacks
  • message authentication code (MAC): keyed hash; TODO
  • message integrity code (MIC): TODO
  • hash-based MAC (HMAC)
    • uses 1-way hash (eg SHA), but incorporates shared secret key (for authenticity) and re-hashing the hash of the key + message (to prevent append attacks)
    • masks key with consts ipad (0x3636..) and opad (0x5c5c..)
    • hmac(key, msg) = hash((key xor opad) + hash((key xor ipad) + msg))
    • http://dev.ionous.net/2009/03/hmac-vs-raw-sha-1.html
  • cryptographic hash functions: TODO
  • diffie-hellman key exchange
    • allow 2 parties w no prior knowledge of ea other to establish shared secret key over insecure channel
    • uses discrete logarithm problem: compute discrete logs module an appropriate prime (a bit harder/slower than factoring “hard” ints of same size)
    • followed shortly by RSA
  • secure remote password (SRP)
    • structurally similar to D-H

authentication encryption

  • middle option is the only secure one:
    • Encrypt and MAC: encrypt the plaintext, compute the MAC of the plaintext, and append the MAC of the pltaintext to the ciphertext
    • Encrypt then MAC: encrypt the plaintext, compute the MAC of the ciphertext, and append the MAC of the ciphertext to the ciphertext
    • MAC then Encrypt: MAC the plaintext, append the MAC to the plaintext, then encrypt the plaintext and the MAC
  • http://tonyarcieri.com/all-the-crypto-code-youve-ever-written-is-probably-broken
  • http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html

  • salting: decorating a password (eg prefix/suffix) and hashing that as the “password” (for storage/comparison); similar to nonce
    • defends against rainbow table attacks (since each user)
    • variations
      • site-wide, static hash (hardcoded)
      • hash of user info; lacks entropy, still can be predicted (only so many usernames)
      • generate and store random salt
      • combo of above: static + user info hash + stored hash

network attacks

  • sockstress: syn-synack-ack flood (local iptables configured to not be affected)
  • ping of death: icmp packet that’s >64KB in length
  • teardrop: mangled IP fragments with overlapping, over-sized payloads

network reconnaissance

  • idle scan aka zombie scan: port scan that doesn’t reveal scanner’s IP to target by using intermediate node (“zombie”)
    • attacker sends SYNACK to zombie to get its IP ID (eg 31337)
    • attacker sends SYN to target spoofed from zombie; if port is open, target sends SYNACK to zombie
    • zombie sends RST to target since that’s what TCP does on unsolicited SYNACK; this has IP ID 31338
    • attacker sends SYNACK to zombie again to get its new IP ID 31339
    • if port wasn’t open, attacker’s subsequent SYNACK would get 31338

anti-IDS HTTP scanning

  • libwhisker: Perl scanner with anti-IDS techniques
    • IDSs look for certain things; avoid them
    • GET -> HEAD, URL encoding, double slashes, .. traversal, . traversal,  on Windows, \0, case sensitivity on Windows
    • premature request ending: to fool smart IDS systems that try to decode too aggressively; GET / HTTP/1.0\r\n... -> GET /%20HTTP/1.0%0D%0A
    • param hiding: foo.cgi?... -> foo.cgi%3F...
    • misformatting: eg Apache tolerates tabs in the GET line instead of spaces
    • long URLs to bump off what the IDS scans
    • splice session across multiple packets
    • http://www.wiretrip.net/rfp/txt/whiskerids.html

network security tools

  • nessus: vuln scanner
  • wireshark: packet analyzer
  • netcat: swiss army knife
  • metasploit: dev framework for exploits
  • hping, nmap: network probing
  • kismet: wifi sniffer
  • tcpdump: packet capture
  • cain & abel: windows password recovery
  • john the ripper: unix password recovery
  • http://sectools.org/

IDS/IPS

  • snort: network-based; has GUIs (BASE, ACID) built on LAMP
    • requires promiscuous sniffing off ethernet hubs or configure to SPAN (Switched Port Analyzer) a switch port via port mirroring
  • ossec: host-based
    • file integrity checking, log monitoring, rootkit detection, active response

network hijacking

  • TCP hijacking
    • if on same segment: easy to just observe seqno and spoof it
    • if on diff segment: need to guess initial seqno
  • IP/BGP/prefix hijacking: take over groups of IPs by corrupting Internet routing tables
    • announce a prefix that it you don’t actually own
    • announce a more specific prefix than the true owner’s prefix
    • announce that you have a shorter route to the target AS
    • “black holing”: ??
    • must hijack BGP TCP session
  • DNS cache poisoning: tricking NS into thinking it got authentic info
    • specify attacker’s choosing of authority NS for either requested domain or unrelated domains
    • bugs in eg BIND allowed the above to slip by; now fixed
    • still, no signing means easy to do MITM
    • DNSSEC signs responses with PKI-like infrastructure
  • DNS rebinding: trick browser into combining diff hosts into 1 origin
    • circumvent firewalls; access internal sites
    • steps
      • register domain
      • use own DNS server; set short TTL (1s)
      • attract traffic (run ads)
      • serve page w JS that issues another request to domain after TTL (2s), triggering DNS query
      • rebind hostname to internal IP (10.10.10.10)
      • send response to attacker
    • DNS pinning: some browsers (IE) cache for add’l min time (30m)
      • still re-queries if can’t connect to host
      • hence, after initial page load, firewall off the client; rebind works
  • wifi
    • karma: listen for wifi client probes so that you can eg pretend to be a familiar AP
    • airdrop-ng: deauthorization tool to disassociate APs and clients
  • dhcp exhaustion: silence the orig dhcp server, then become mitm dhcp server that dishes out your own gateway, dns, etc; there’s a metasploit module
  • DNSSEC: includes hashes (‘fingerprints’) of cert or full cert chain

brute-force DOS

  • flooding
  • DDOS
  • easy to detect (? TODO)

sophisticated DOS

  • app bugs: eg buffer overflows
  • fragmentation of data structures: eg hash tables
  • algorithm worst cases, eg regexes

public key crypto

  • rsa
  • dsa
  • elliptic curve
    • attractive for mobile/wireless env’s
    • vs RSA: equiv security with smaller key sizes (faster, less resources)
      • use ECDSA

secure ciphers

  • rely on bit manip “networks”
    • AES uses substitution-permutation network (SPN)
      • SPN is simplest way to achieve confusion & diffusion; easily implemented in HW
    • DES uses feistel network
  • Shannon properties
    • confusion: relationship btwn key & ciphertext as complex/involved as possible
    • diffusion: redundancy in the plaintext statistics is “dissipated” in ciphertext
      • non-uniformity dist in plaintext should be redistributed (somehow)
      • ciphertext bits should depend on input bits in very complex way
      • changing 1 plaintext bit should completely change ciphertext in pseudorandom way

block ciphers vs. stream ciphers

  • distinction not always clear cut; block ciphers sometimes act effectively as stream ciphers
  • stream ciphers usu. faster, but serious sec problems if used incorrectly (esp: same starting state must never be reused)

stream ciphers

  • stream cipher: symmetric key cypher where plaintext is combined with pseudorandom cipher bit stream called keystream, typically xor
    • plaintext bits encrypted one at a time
    • xform varies during encryption
  • rc4: by ron rivest; in (eg) WEP, WPA (default), TLS/SSL (opt), BT, ssh (opt), RDP, KRB (opt), PDF
  • a5/1: in GSM; in US, EU; leaked, rev-eng’d; numerous weaknesses
  • a5/2: a5/1 with deliberate weakening for certain export regions

block ciphers

  • block cipher: operate on large blocks of digits with a fixed, unvarying xformation
    • eg 128-bit blocks of plaintext -> 128-bit blocks of ciphertext
  • des: early highly influential; ibm; 1997; insecure to brute force
    • EFF DES cracker aka “deep crack”: cracking machine
    • with distributed.net, decryted challenge 3 after just 22h
    • controversy over NSA’s opaque involvement in design
  • 3des: 1998; applies des 3x per block; used by electronic payments industry
    • simply increases key size 3x to defend against brute force
    • pseudocde: des_enc(k1) -> des_dec(k2) -> des_enc(k3)
  • blowfish: bruce schneier; 1993; fast; no known cryptanalysis; widely used, but aes overshadows it
  • rc5: rivest cipher
  • AES finalists: RC6, twofish, rijndael, serpent, MARS
  • aes aka rijndael: successor to des; 2001
    • 128, 192, 256 bit key sizes; all 128 bit block sizes
  • KASUMI aka a5/3 in GSM aka GEA3 in GPRS: no known weaknesses, but GSM is vuln (can avoid a5/3)

security status of cryptographic tools

  • insecure: MD5, SHA1
  • secure: AES, RSA, SHA-2 (SHA-256, SHA-512), SHA-3
  • note eg HMAC-MD5 not vuln to MD5 vulns
    • HMAC strength depends on secret key len
    • brute force is most common attack; less affected by collisions than underlying hash fns alone

cryptographic hash fns

  • SHA: NIST-approved
    • SHA-3: SHA-3-512
  • blowfish: bruce shneier
    • expensive key setup phase

crypt

  • uses hash fn, encodes salt, records which hash fn used
    • by default, uses DES on data=0, key=truncated pass
    • other versions exist that use md5, blowfish, sha
  • eksblowfish (provos, mazieres, 1999)
    • take adv of expensive key setup phase of blowfish
    • introduce configurable # rounds to make validation arbitrary expensive

block cipher modes

  • insecure: electronic codebook (ECB)
  • output feedback (OFB), cipher feedback (CFB), counter (CTR)
    • don’t repeat initialization vector (IV) for same encryption key
    • turns block ciphers into self-synchronizing stream cipher
    • CFB: identical to CBC encryption done in reverse
    • OFB: gen keystream blocks that are XORed w plaintext blocks
  • cipher block chaining (CBC), propagating CBC (PCBC)
    • each plaintext block XORed w prev ciphertext block before encryption
    • encryption sequential, but decryption can parallelize
    • PCBC: also XOR the prev plaintext block
    • use this if msg authenticity is not an issue
  • authenticated encryption (AE): simultaneously protect confidentiality and integrity
    • AE with associated data (AEAD): block cipher modes
    • CCM, CWC, OCB, EAX, GCM

programming

  • don’t use expert interfaces: OpenSSL, Crypto++, CommonCrypto, CryptoAPI, etc
  • use NACL, keyczar if you really need crypto
  • otherwise try using PGP/GPG for data-at-rest or TLS for data-in-motion

VPNs

  • point-to-point tunneling protocol (PPTP): microsoft’s default VPN protocol
    • remains popular
    • protoco-independent, but main usage: TCP control stream, GRE data stream (many firewalls don’t support GRE)
    • there are alts eg RADIUS but PPTP is default for client back-compat
    • doesn’t require PKI, unlike L2TP/IPsec
    • provides confidentiality, not integrity or authentication
    • encapsulates PPP
  • layer 2 tunneling protocol (L2TP)
    • derived from PPTP
    • combines control & data channels
    • protocol-indep, but mainly used over UDP 500
    • standards bodies attn shifting toward L2TP from PPTP
    • uses IPsec ESP by default
    • also provides user auth
    • encapsulates PPP
  • IPsec
    • provides confidentiality, integrity, authentication
    • uses PKI and machine-level certs
    • doesn’t provide user auth
    • TODO
  • secure sockets tunneling protocol (SSTP): tunnels over HTTPS (TCP 443)
    • provides confidentiality, integrity, authentication
    • encapsulates PPP
  • IKEv2: uses IPsec
    • provides confidentiality, integrity, authentication
    • supports the latest ipsec encryption algos
    • supports mobility (MOBIKE); resilient to changing network connectivity; can switch APs or even wired/wireless
  • OpenVPN ALS: web-based SSL VPN server written in Java; derived from Adito, SSL-Explorer
    • provides in-browser HTTPS client access with java applets for tunneling
  • misc
    • PPTP, L2TP, SSTP depend heavily on features orig for PPP
    • built in to windows: PPTP2, L2TP/IPsec, SSTP, IKEv2
    • SSTP, IKEv2, maybe others: don’t require client-side PKI deployment or pre-shared key
    • SSTP, IKEv2, maybe others: integrate well w EAP
  • refs

authentication protocols

  • EAP
    • authentication framework, not specific mechanism; over 40 methods
    • used in wireless networks and point-to-point conns
    • adopted by WPA, WPA2
  • challenge handshake authentication protocol (MS-CHAPv2)
    • the only authentication protocol for windows PPTP
    • uses DES
    • weaknesses known by 1999; bruce schneier and l0pht wrote a cryptanalysis
    • username is in plaintext
  • lightweight extensible authentication protocol (LEAP): cisco-proprietary extension of EAP; in cisco ap’s
    • uses modified version of MS-CHAP
  • newer: EAP-FAST, PEAP, EAP-TLS
  • EAP-TLS: TODO
  • u-prove: maintain privacy while proving that i can pay
    • TODO can’t tell if same person made txns?

wifi

windows security

  • 2 ways windows stores acct credentials: LAN Manager and NTLM
    • LAN Manager: weak; brute force, rainbow tables
    • NTLM: time-memory tradeoff attacks

cracking techniques

  • brute force
  • rainbow tables: sets of precomputed hashes as a time-memory tradeoff

cracking tools

  • MS-CHAPv2, LEAP, PPTP
    • ASLEAP: cracks LEAP and PPTP; updated to crack MS-CHAPv2
      • given MS-CHAPv2 challenge and response, return last 2 bytes of password hash (username already in plaintext)
    • CUPP: common user password profiler; wizard-like dictionary generator that asks for info about user
    • genkeys: generates hashes of a wordlist using DES
    • cowpatty: cracks pre-shared key (PSK) WPA networks based on the TKIP protocol
  • MD5
  • windows: LAN Manager, NTLM
    • pwdump: outputs LM and NTLM account password hashes from the Security Account Manager (SAM)
    • CUDA-based NTLM brute forcer for linux: http://3.14.by/forum/viewtopic.php?f=8&t=60&
    • ophcrack: crack windows passwords using rainbow tables
    • usbophcrack: downloads some rainbow tables and creates boot usb
      • advise using ophcrack’s rainbow tables instead
  • http://revision3.com/hak5/asleap

windows system security

  • ASLR
  • DEP: uses NX if avail or software emulation with limited, almost-unrelated protection with SafeSEH (simply checks that an exception is registered in a function table for the app)
  • common exploit techniques TODO http://www.hick.org/~mmiller/shellcode/win32/generic.c
    • PEB
    • SEH
  • steadystate/pc safeguard
    • applied only to std accounts; rolls back all reg, fs changes

windows 7 UAC design flaws

selinux (nsa 2000; merged mainline 2003)

  • supplements unix DAC with MAC
  • selinux is an implementation of FLASK for linux
  • hybrid of concepts and capabilities from MAC, MIC, RBAC
  • hard to config
  • applies labels to files
  • identifies files by inodes
  • perms
    • specify specific ops (creat, rename, unlink, etc)
    • allow, deny, auditallow, auditdeny

linux apparmor (novell 2005)

  • supplements unix DAC with MAC
  • manually specify profiles for apps
  • “learning mode” logs holes that are opened and creates profiles from that
  • alternative to selinux
    • identifies files by paths instead of inodes
    • can make use of FSs with no support for extended file attributes, eg NFS

SFI

TODO

efficient software-based fault isolation (wahbe, sosp93)

  • [aka “classical SFI”]
  • isolate software modules without relying on MMU
  • naive custom compiler approach: on a write or indirect branch/jump, check that addr is in current module’s range
    • slow
    • circumventable; eg, indirect branch to own write that skips the checks before it
  • use a dedicated reg to hold an addr
    • all writes must be performed to the addr in the reg
    • reg must always point to valid addr in current module
      • if any instr invalidates this, program must fail or fix by the next write/indir jump
  • to jump outside, use local jump table; system allows only this table to point outside
    • allows indir jumps to be very simple: only check for local
    • switch stacks
    • callee-save regs: call stub saves regs in case callee does not preserve regs
  • opts
    • checks can be made into a simple bitmask as long as ranges can be identified by bit prefixes
    • stack writes use esp + small static offsets; hence just validate esp when it’s changed, and pad module space with guard regions that are bigger than biggest offsets
  • overhead: 0-12% (avg 4.3%); if also checking reads, avg 21.8%
  • [depends on large trusted compiler for correctness; later works like pittsfield use smaller verifier on machine code]
  • [not used in practice, maybe bc depends on RISC features like reserving certain regs, maybe bc no robust product]
  • [pittsfield, vx32 apply to x86 and have more robust prototypes]
  • [vx32 creatively exploits legacy hardware being phased out]
  • [SFI has a useful fault iso model that deserves HW support]
  • http://papersincomputerscience.org/2009/12/19/efficient-software-based-fault-isolation/

pittsfield (stephen mccamant, greg morrisett, TR/usenix 2005)

  • SF vs pittsfield: write/jump sandboxing vs full read/write/jump isolation

vx32 (bryan ford, russ cox, TR 2008)

  • x86, linux/freebsd

linux containers (lxc)

  • can evade lxc as root in lxc by eg sysfs http://blog.bofh.it/debian/id_413
    • will be fixed upon support for labeling files with user namespaces
  • user namespaces: allow normal user to unshare namespaces
  • The most glaring reason is that user namespaces are not yet being enforced at most user id comparisons, including at file system. That means that user id X in one user namespace will be deemed owner of a file created by user id X in another user namespace. Toss in root and virtual filesystems like /proc and /sys, and root in a container can do what he likes with the host. MAC can help mitigate this, but user namespaces are still being developed to provide the real solution.
  • Another reason, fwiw, is simply that it shares the same kernel as the host. So any exploits in any system calls can likely be exploited by the container to gain privilege and escape the host. The worst offenses are usually in newer system calls, so some hope is being placed in seccomp2 to mitigate this concern.
  • http://s3hh.wordpress.com/2011/05/31/escaping-chroots/

engineering

http://www.matasano.com/log/989/thoughts-on-ten-years-of-qmail-security/ (DJB 2007)

  • directions of progress
    • eliminating bugs
    • eliminating code
    • eliminating trusted code
    • distractions
      • chasing attackers
      • minimizing privilege: vs minimizing TCB
        • [“privileges” here are superficial OS level privileges]
      • speed
  • eliminating bugs
    • enforcing explicit data flow: process isolation, PL support
    • simplifying integer semantics: used big num lib, PL support
    • avoid parsing: anything with strings; quoting; printf bugs
    • generalizing from errors to inputs: insert testable abstractions
  • eliminating code
    • identifying common functions
    • automatically handling temporary errors [exceptions better than error checking]
    • reusing network tools [like inetd]
    • reusing access controls: eg assuming a user’s uid
    • reusing the file system: as an associative array (instead of parsing a single config file)
  • eliminating trusted code
    • accurately measuring the TCB: hard
    • isolating single-source xforms
      • eg jpegtopnm: after jailing, attacker can only produce any img he wants, but he could’ve done this in the first place
      • sandbox recipe
        • Prohibit new files, new sockets, etc., by setting the current and maximum RLIMIT_NOFILE limits to 0.
        • Prohibit filesystem access: chdir and chroot to an empty directory.
        • Choose a uid dedicated to this process ID. This can be as simple as adding the process ID to a base uid, as long as other system-administration tools stay away from the same uid range.
        • Ensure that nothing is running under the uid: fork a child to run setuid(targetuid), kill(-1,SIGKILL), and _exit(0), and then check that the child exited normally.
        • Prohibit kill(), ptrace(), etc., by setting gid and uid to the target uid.
        • Prohibit fork(), by setting the current and maximum RLIMIT_NPROC limits to 0.
        • Set the desired limits on memory allocation and other resource allocation.
        • Run the rest of the program
    • delaying multi-source merges (like XSS)

practical sandboxing

  • chroot etc
  • ptrace (systrace, sydbox, pinktrace, libsandbox, etc)
  • lxc: a better/more general chroot
    • (until user namespaces implemented) can escape as root
    • new namespaces: pid, network, …
  • resource limits
  • seccomp: too restrictive (can’t even alloc mem)
  • seccomp-bpf: can’t deref ptrs, only raw syscall args
  • lsm: don’t stack
    • selinux/apparmor: administrative, heavyweight
    • smack: simpler, uses hybrid inode/path identification
  • privsep: use diff processes, UIDs, w min privs
  • openvz: not avail in stock ubuntu 12.04
  • https://www.cr0.org/paper/jt-ce-sid_linux.pdf

web

robust defenses for CSRF (adam barth, collin jackson, john c mitchell, CCS 2008)

  • login CSRF
  • TODO

sound and precise analysis of web applications for injection vulnerabilities (ucdavis, pldi07)

  • prev static approaches use tainted information flow tracking
    • don’t model precise semantics: even ‘sanitizers’ like escape_quotes could fail to sanitize inputs
    • require manual specifications bc systems don’ track string value sources
    • not fully automated and may require user intervention at various points in analysis
  • consider as attacks those queries for which user input changes the intended syntactic structure of the generated query
  • implemented for PHP; analyzed large (100KLOC) progs; few false positives

DOS

http://www.checkmarx.com/NewsDetails.aspx?id=23 regex (“redos”)

  • worst-case exponential
  • eg: /^(a+)+$/ on “aaaaX” produces 16 paths
  • more: /([a-zA-Z]+)/, /(a|aa)+/, /(a|a?)+/, /(.a){x}/ for x>10
  • many legit bad regexes even in OWASP validation regex repo
  • many pts of attack; regexes are ubiq
    • submit a bad regex or leverage regex injection
    • submit a string for an already-there bad regex
  • meta-regex for finding bad regexes; use codesearch to find
  • browsers protect against infinite loops but not bad regexes
  • should be not-too-bad to statically analyze regexes

fun exploits

morris worm

mark dowd flash exploit 2007

  • http://chargen.matasano.com/chargen/2007/7/3/this-new-vulnerability-dowds-inhuman-flash-exploit.html;jsessionid=8DDE25A54184976447838948127BE85C.web18
  • bounds-checker treats field as signed, permitting (small?) negative numbers
  • interpreter treats as unsigned, so neg -> large
  • controls alloc, so bad alloc -> null ptr
  • flash uses that ptr + attacker-controlled offset
  • to that addr, flash writes attacker-controlled value
  • idea: use this writing vector to target a function ptr, changing it to a user-supplied buffer of shellcode
  • tough constraints: offset > 0x80000000, offset + 4 divisible by 12, used value = (value cast from 16- to 32-bit) - some other var
  • so instead, manipulate actionscript bytecode state
  • interpretation differs btwn verifier TOC & executive TOU
    • verifier ignores undefined bytecodes
    • verifier keeps table defining bytecode instruction lengths
    • bytecode length table is valid target of null ptr overwrite
    • executive has totally diff machinery for interpreting bytecode
  • use null ptr write vector to clobber the right value in length table, and you can make unused instr that the verifier ignores seem much longer than it is
  • executive doesn’t ignore what comes after the initial unused instr, so put valid bytecode there for execution

kernel null pointer exploits

  • tun driver uses null ptr; can write to 0x0 with mmap, iff selinux is on, ironically
  • ptr is used in an exploitable way
  • “In well-designed systems, catastrophic failures are rarely the result of a single failure. That is certainly the case here.”
  • http://lwn.net/Articles/342330/

IFC

general

  • [autoescape makes taint mode obsolete for web apps?]

taint mode for python via a library (2010)

RESIN: Improving Application Security with Data Flow Assertions (alex yip sosp09)

  • python-taint: alexyip; requires new interpreter
  • filter objects define data flow boundaries on functions, IO channels
    • eg file objects, escape()
    • default set on all standard libs
    • eg filter on http output channel could check for attacks like crlfcrlf
  • annotate sensitive data w policy objects
    • export_check(ctx) method checks that ctx is suitable to output data to
    • eg for passwd
      • policy object has an email field
      • export_check(ctx) = ctx is email to matching recip, or ctx is http to admin
    • eg user supplied inputs
    • merge(policy_set) method is overridable; defaults to union
  • runtime tracks ints, strings (possibly down to individual chars)
    • wraps sql db interfaces to persist policies (rewrites schemas)

DIFC

flume

  • IFC goals
    • secrecy: prevent leaking private data
    • integrity: prevent accepting untrusted data
  • DIFC: decentralized means no central deputy needed for declassification
  • flume: DIFC at process granularity, controlling IO; user-level monitor
  • related work
    • jif: finer-grained control at function granularity; requires app rewrite
    • asbestos/histar: kernels designed to support DIFC; message granularity
    • flume
      • rules inspired by jif
      • labels influenced by asbestos
      • adopted histar’s requirement that threads must explicitly request label changes
  • concepts
    • a tag t is associated with some category of secrecy or integrity
    • labels are sets of tags
    • a process p has 2 labels, S_p for secrecy and I_p for integrity
      • if t \in S_p then (conservatively) p saw private data tagged with t
      • if t \in I_p then every input to p has been endorsed as having integrity for t
    • two capabilities per tag
      • t+: ability to add t to one of its label
      • t-: ability to remove t from one of its label
      • note: you might not want to use the same t for both secrecy and integrity; see examples below
    • each p owns a set of capabilities O_p
    • D_p = { t \vert t+ \in O_p, t- \in O_p } (the set of tags for which p has dual privileges)
    • any p can create tags; added to D_p
    • global capability set O \subseteq O_p \forall p
  • export protection example
    • if b \in S_p then p can write to q iff b \in S_q also
    • but any process can add b and read secret b since b+ \in O
      • means all their output will be tagged with b
      • note that this means b should not be used for integrity, or anyone can add it to their integrity label
    • but a process p can’t leak it out of system unless b- \in O_p
      • transition: from secret to non-secret
  • integrity protection example
    • if b \in I_p then p can read from q iff b \in I_q also
    • processes cannot willy nilly add b and be trusted to provide b-tagged data
      • transition: from non-trusted to trusted
      • this is called endorsement
    • can, however, remove b to remove trust (not sure why they want to do that); so b- \in O

IE

  • Protected Mode for isolation and sandboxing
  • type 1 (reflected) xss filter

malware

the ghost in the browser: analysis of web-based malware (provos, google, 2008)

  • 10% of URLs engaged in drive-by downloads
    • map-reduce looks for known malicious URLs in corpus
    • instrumented IE in VM; watch for add’l processes, changes in FS/reg
  • malware comes from lack of content control on pages
    • web app exploits
    • user content
    • ads: partner with dedicated ad companies, not individual advertisers; trust is not transitive
    • third-party widgets: eg stats counter, iframemoney.org
  • exploits
    • popular: MS DAC
      • js instantiates activex object; normally not safe for scripting
      • js retrieves exe via XHR
      • adodb.stream used to write exe to disk
      • shell.application launches new exe
    • popular: MS WebViewFolderIcon heap spray
    • many gather info (eg browser, jvm version, OS patches) then fetches applicable exploits
    • can also trick user, eg video activex codec
  • trends
    • js escaping: effective against signature/anomaly-based IDSs; also used by legit sites
    • classification: use majority voting by major AV software
      • trojan: contains/installs malicious app with harmful impact on user’s computer
        • most common: downloaders (get other trojans), banking (bank acct numbers, passwds)
      • adware
      • unknown/obfuscated
    • http reqs not from browser: mostly for popup ads, some for updates/instrs
    • most exploits not hosted on compromised sites; distributed across many sites
    • hosted binaries mostly change infrequently; some do, to evade sig scans
  • most malware are user-mode apps
  • [curiously, saw nothing on spam]

a crawler-based study of spyware on the web (uw, 2007)

  • downloaded exe’s, ran/install in VM, ID with lavasoft ad-aware
  • twice: 5/2005, 10/2005
  • high risk sites: games, celebs
  • types
    • adware
    • keylogging spyware
    • trojan downloaders
    • browser hijackers: search engine, default home page, URL redirection
    • dialers: uses modem to call expensive toll numbers
    • mostly adware, hijackers (relatively benign) but many downloaders
    • drive-by’s have same distribution as spyware
  • time comparisons: older AV DB misses 1/3 of spyware; URL blacklisting ineffective [numbers don’t seem to support, though]
  • many tweak registry
  • collection via disposable webmail
  • [notes]
    • curiously, saw nothing on spam, game passwd harvesting
    • no need for exploits

systems security

return-oriented programming (Hovav Shacham, ucsd, 2009)

  • generalization of return-to-libc; chain rets together
  • [not much here]

“Countering Kernel Rootkits with Lightweight Hook Protection”

  • gist: copy all hooks to read-only mem and make all callsites (found by profiling) use that
  • premise: preserving kernel code integrity (eg disallowing changing kernel code and disallowing introduction of new code) is not enough
    • exploits leverage existing code and subvert control flow, eg return addresses and function pointers
    • protecting return addresses is well studied
    • this paper: protecting function pointers (hooks)
  • profile system offline to find out the calling sites of all hooks, or hook access points (HAPs)
    • given the list of kernel hook locations for protection (globals)
    • dynamically allocated hooks: discovered at runtime by monitoring call stack at alloc sites to see what object is being created
  • online system protection: run OS in hypervisor (Xen)
    • after OS init, copy all hooks into a memory region; these copies are the shadow hooks
      • region is read-only
      • read/write requests distinguished by HAP
      • hypervisor validates write request (requires new hook value to be recognized from offline profiling phase, but other validations possible)
    • dynamically allocated hooks: alloc/update/free results in hypercall
    • memory protection is guaranteed by hypervisor shadow page table
    • trampoline the HAPs to call into shadow hook area
      • (as typical) the instructions are in read-only executable text pages
    • syscall table can be uniquely optimized

seminal

Why Isn’t Trust Transitive? (bruce christianson, william s harbison)

  • straightforward but classic

Sandboxing

privsep (niels provos, usenix 03)

  • privileged parent monitor and unprivileged child process
  • no syscall tracing; only using OS UID-based privilege separation
  • child runs with unused user and chroot’d to /var/empty
  • comm over pipes, shared mem

Efficient Software-Based Fault Isolation (Wahbe, sosp93)

  • can isolate via separate addr spaces, but switches not good for tightly coupled modules
    • RPC: trap, copy, ctx save/restore, switch HW addr space (flush TLB), trap
      • repeat on return; 3 OOM > normal proc call
    • eg postgres extensible type system can define ctors, dtors, preds
    • eg OS exts: packet filters, app-specific virt mem mgmt, Active Messages
  • propose a portable, PL-indep approach:
    • load code/data into own fault domain (portion of host’s addr space)
    • rewrite code to prevent writes/jumps outside fault domain
  • poses tradeoff rel. to hardware fault isolation: substantially faster comm btwn fault domains, but slightly increased execution time for distrusted modules
    • evaluated on postgres; 3x faster than sep addr spaces

App-V (john sheehan, MS ECS 2009)

  • sequencing: process of packaging apps
    • monitor installation from kernel; capture FS/reg changes
    • now know all the resources needed by app; can optimize the layout for streaming
    • extract metadata; eg recognize COM objs, NT services; store in manifest
    • heuristics
      • program files: don’t need to roam with user
      • hkey_current_user keys: should roam with users
      • UI for tweaking these settings
  • SystemGuard: “namespace mgr”
    • system namespace: fall-through for everything else
    • elseapp namespace: produced by sequencing
      • eg C:\windows\system32\foo.dll could’ve been installed by app
      • enables streaming (Click2Run), user roaming
    • modification namespace: where writes go (either roaming or non-roaming)
    • handles: files, reg, COM, fonts, services, object mgr, mailslots, etc.
      • eg virtualize CLSIDs for COMs; virtualize service names
      • don’t deal with drivers; typically installed as part of platform
    • dynamic, not static: watch processes, not programs
      • eg cmd is already there, but if run via a VS shortcut, run it in the VS bubble
    • for cross-app, dynamic suite composition (DSC) feature: run in same bubble
  • office doesn’t user the generic app-v UIs

native client

  • inner sandbox
    • software fault isolation
      • in general disassembly is unreliable: same instruction stream may be entirely different if you jump to somewhere in the middle of it
      • goal: get reliable disassembly; then, can prohibit certain instructions
      • static validation of most calls/jumps
      • once loaded, binary is not writable; also uses x86 segments to constrain the executable instruction range
      • locates instructions at address 0 so that indirect jumps need only be prefixed by an and and not an and;or
      • omit certain instructions: ret, int, syscall; use indirect jumps
      • all indirect branch targets must be aligned; bitmask every target address
      • no code gen, mixed text/data, overlapping instrs
    • x86 segments: hardware support -> faster
      • original SFI: bitmask every load/store address
      • caveat: need LDT; privileged instruction, vista 64 doesn’t provide this; confuses os an hardware exceptions
  • outer sandbox
    • redundant; defense in depth
    • system call filter for untrusted modules
    • OS-dependent: ptrace on linux, syscall ACLs on Windows
      • to avoid ptrace overhead, nacl provides own shared mem and sync objects
  • compile for native client with modified gcc (1000 lines patched)

Sprockets: Safe extensions for distributed file systems (umich usenix 07)

  • for distributed FS “tweak” extensions; DFSs mostly impl’d in user space
    • run procedure in same addr space, then always roll back except for the buffer expecting results (this is validated/acted on by host)
    • programmability like proc call: lightweight usage, can access any data/code
    • cost: not up front per sprocket, but per line of code executed, since sprockets are small
  • alt designs and their problems
    • direct procedure call: same addr space
    • separate addr spaces, eg fastcgi
      • no access to (reuse of) data/code; need to define (read) interface
      • requires OS fine-grained sandboxing (only read file1 and write file2)
    • chkpt/rollback (fork): closest to sprockets
      • heavy; still requires OS sandboxing
      • idea for multithreading: wait for all locks to release before fork
  • binary instrumentation/SFI with PIN
    • first save caller ctx (regs, PC, heap size, etc)
    • for each mem write, save orig loc/val in undo log
    • dynamically enable/disable instrumentation: core FS functions called via sprockets are instrumented; outside, orig is used
    • OOM slower, but faster than fork
    • optims: no need to restore unused memory, eg space below stack or malloc’d by sprocket; avoid dup backups
  • handling buggy sprockets
    • register sig handlers for segfaults, timeouts
    • instrument syscalls with check against whitelist + optional specific syscall handling (eg closing an fd that it didn’t open)
  • multithreading: sprocket time (.14-.62ms) << scheduling quantum
  • implemented: transducers (id3), app-specific resolution (id3), devices (PTP)
  • related work
    • wahbe: limits access to addr space outside sandbox
    • vino: SFI for OS exts; not full access (whitelist of kernel fn’s)
    • nooks: used this technique for device drivers
    • exokernel: allows user-level code to impl many services
    • sprockets target functionality already avail. at user-level; min changes; user-level tools/libs
    • type-safe langs: eg SPIN OS uses modula-3; limits FS code reuse (mostly not in type-safe langs)
    • watchdogs, stackable FSs: more coarse-grained ext interface allowing exts only at certain pre-defined VFS ops like open, close, write
    • may leverage STM/HTM techniques

Saltzer & Schroeder, “The Protection of Information in Computer Systems”

  • seminal paper on OS security
  • no mention of pub key crypto; still 5 yrs away

chrome/chromium

  • chroot: requires suid but is ironically more secure
  • exec()ing from empty jail is hard
    • can copy all dep files, but maintenance/packaging nightmare
    • use clone() flag CLONE_FS and share FS struct btwn a trusted/privileged thread and the exec()ed renderer
    • trusted thread can call chroot and have it affect the unprivileged, untrusted renderer post-exec
  • CLONE_NEWPID and CLONE_NEWNET: prevent sending signals, network access
  • http://scarybeastsecurity.blogspot.com/2009/10/chromium-and-linux-sandboxing.html

Security In-Depth for Linux Software: Preventing and Mitigating Security Bugs (Julien Tinnes, Chris Evans, Google, Hack in the Box 10/2009)

  • examples: chromium, vsftpd
  • security in depth
    • reduce bugs
    • app-level mitigation (SSP, relro)
    • sys-level mitigation (ASLR, NX)
    • privilege dropping (sandboxing)
    • mandatory access control (MAC)
    • update strategy
  • privileges in linux: processes and privileges
    • kernel is a mandatory interface to system; process is privilege boundary
    • A > B if A’s privileges are superset of B’s
    • procs have uid + gid
    • threads generally don’t have privilege separation (but: clone, seccomp)
    • if A can ptrace B, then A > B
    • uids/gids
      • types
        • real: owner; who you really are; only root (usu. login) can change; id -ru
        • effective: for access ctl; id -un
        • saved:
        • FS: file system; in linux
      • operations
        • fork inherits UIDs
        • suid + seteuid let you temporarily drop root and restore later
        • not sure if correct (prolly not):
          • setuid(x) = if (euid == 0) { ruid = euid = suid = x } else { euid = x }
          • seteuid(x) = if (euid == 0) { ruid = euid = suid = x } else { euid = x }
      • summary
        • (r)uid, euid, suid, fsuid
        • (r)gid, egid, sgid, fsgid, supplementary groups
    • POSIX.1e capabilities: for splitting root privileges; in linux 2.2
    • partial uid switching
      • mostly useful to avoid confused deputy problems
      • useless given arbitrary code execution
      • only root can use
    • linux capabilities
      • CAP_NET_RAW: permit use of RAW and PACKET sockets
      • CAP_SYS_ADMIN: administrative ops (mount, sethostname, etc)
      • CAP_NET_BIND_SERVICE: binding to reserved ports (<1024)
    • common mistakes
      • forgetting to switch from uid 0
    • chroot: popular way to drop FS access; root only
      • requires dropping privileges afterward, or easy to escape
      • re-chroot technique (popular), inject modules, ptrace non-chroot-ed proc, etc
      • look at capabilities for inspirations of other things you can do as root to escape
    • recent kernels add clone/unshare flags for dropping privileges; root only
      • CLONE_NEWPID: new pid namespace
      • CLONE_NEWNET: new network namespace
      • CLONE_NEWIPC, CLONE_NEWUTS, CLONE_NEWNS
    • resource limits
      • RLIMIT_NOFILE: can’t get new fd’s, but can still rename and unlink
      • RLIMIT_NPROC: can’t create new procs
      • if used for security, both soft and hard limit need to be set to 0
      • or attacker could replace existing fd to create new fd’s
    • linux supports per process dumpable (debuggable) flag
      • can be set through
        • prctl with PR_SET_DUMPABLE
        • when executing a file you don’t own and can’t read
        • when switching uid
      • CAP_SYS_PTRACE: can’t ptrace a non dumpable proc; thus, elevation of privileges
      • allows to lower another process’ privileges
  • writing good code
    • preventing common security flaws
    • privilege separation
    • trust relationships
    • update strategy
  • sandbox designs
    • ptrace
      • slow
      • nacl paper reports many CVEs; very buggy area
      • many pitfalls (TOCTTOU)
      • highly sensitive to exact kernel/glibc version/arch
    • setuid helper: use root to chroot, set resources, preven ptrace/signals
      • require administratively defined pool of UIDs/GIDs (no /etc/passwd entries)
      • on invoke, switch to unused UID/GID (atomically; use RLIMIT_NPROC to make setuid fail if uid alraedy used)
        • partition the pool among UIDs to prevent user from exhausting pool
        • UID switching alone not enough: /tmp, setuid binaries
      • to execve after chroot
        • naive: mustn’t give CAP_SYS_CHROOT
        • realistic: don’t use execve, mmap the code; inconvenient/dangerous but realistic
        • optimistic: give another proc the priv to chroot us to empty dir
          • routine
            • sandbox proc A spawns B
            • use clone w CLONE_FS so A & B share a root dir, cwd, etc
            • A drop privs, B waits for msg from A
            • when A wants to chroot, send msg
            • B chroot to empty dir, which also affects A
          • a root proc B shares FS w untrusted proc A; scary, drugged deputy?
          • mitigations: B can drop caps too, all but CAP_SYS_CHROOT, set RLIMIT_NOFILE to 0,0
      • drop UID/GID pool range?
        • not changing UID & switching to a single common GID
          • prevent ptrace from a sandboxed proc to another proc
          • PR_SET_DUMPABLE prevent ptrace among sandboxed proc
          • signals?
        • using a new PID namespace (CLONE_NEWPID)
          • solves many problems
          • how secure?
      • drop net access
        • use RLIMIT_NOFILE, but what if need new FDs? share (using CLONE_FILES) w a broker proc
        • CLONE_NEWNET: cut access completely
      • conclusion: chromium renderer runs in this sandbox (first-level sandbox)
    • SECCOMP
      • read, write, exit, sigreturn
      • too limited: no mem alloc (mmap, brk), no new FDs (recvmsg)
      • trusted thread: each seccomp’d thread has trusted helper thread for syscalls
      • trusted code in RX only mem
      • prevent trusted code from accessing volatile mem by…
        • use pure asm, can’t use stack
        • but some syscalls pass ptrs to volatile mem (open)
      • for access to volatile mem, use sep trusted proc that shares pages (TT can only read)
      • high potential to isolate kernel but still WIP, perf issues, disabled
    • other
      • rely on a MAC
      • lack of discretionary priv dropping facilities
      • recent efforts: LSMSB, selinux type boundaries, ftrace
      • virtualization
    • attack surface eval

Xax (MSR)

  • mechanisms
    • picoprocess: native-code execution abstraction that is secured via hardware memory isolation and a narrow syscall interface, akin to streamlined hardware VM
    • PAL: provides an OS-indep ABI to xax picoprocesses
    • hooks to existing browser mechanisms to provide aps with system services (network, UI, storage) that respect browser security policies
    • lightweight modifications to existing tool chains and code bases for retargeting legacy code to the xax picoprocess env
  • goals and alternatives
    • goals: security, OS indep, perf, and legacy support
      • [they compare SF LOC of C/C++ vs. others; this disregards verbosity, the projects themselves, etc.; may have been better to count number of projects]
    • alternatives
      • existing web-app mechanisms
        • js: slow; no legacy code
        • activex: no sandboxing; only a way to package app for invoking via web; windows only
        • IL (flash/java/MSIL): no legacy code
      • OS processes: not OS indep, insufficient sec
        • can write interposing confinement layers, but that’s hard
        • xax goes opposite: start with no interface and add
      • hardware vm’s: big/complex, so slow dl, insecure, hard to write
        • xax = extreme paravirt where guest os is removed
        • reduces vmm also: no emulation of devices, mmu, cpu kernel mode
  • mechanisms
    • picoprocess: VM without devices, MMU, CPU kernel mode
      • alternatively, a highly restricted proc prevented from making kernel calls
      • hardware-memory-isolated address space; strictly user-mode CPU
      • xax monitor: browser plugin; picoprocess makes xaxcalls to this
      • xaxcalls vary slightly among platforms to keep xax monitor simple
    • platform abstraction layer (PAL) for OS indep
      • PAL translates OS-indep ABI to OS-specific xaxcalls
      • PAL runs inside picoprocess; untrusted; everything above ABI is remote
      • only 9 calls in xax abi
      • simple shim libxax that converts app dev toolchain’s calling convention into xax ABI calls into PAL
    • services via browser mechanisms: same security policies
      • picoprocess is web server; serves http requests
    • lightweight code modification: 5 steps to addressing all porting issues
      • TODO
      • obliviously failing
      • emulate syscall functionality internally
        • eg fs: read from tar, write to ramdisk; also read from other files, eg downloaded from server
      • provide real syscall functionality via xaxcalls
        • real backing functionality for remaining 137 syscalls (11 unique)
  • implementation
    • monitor, boot block, PAL
      • monitor is its own process; xaxcalls via shared mem
      • boot block sets up shared mem, makes kernel call to revoke ability to make subsequent kernel calls, and continues into PAL (which loads/executes app)
      • most xaxcalls implemented straightforwardly in similar way on both platforms
    • linux: uses ptrace to intercept entry/exit of every syscall and xfer control to monitor
      • monitor replaces syscall with effectless getpid
      • syscalls also used by pal to signal a xaxcall; monitor checks if shared memory contains legit xaxcall id/args
      • for alloc/free, replace syscall with mmap; this is because monitor can’t alloc mem on behalf of child
      • 3 syscalls (slow); also if monitor crashes then child can make syscalls
        • fix by using kernel module
    • windows: custom kernel module xaxdrv
      • each windows thread has pointer to table of syscall handlers; xaxdrv replaces this
        • in replacement table, if caller is kernel mode, then pass through preserving dispatcher’s stack frame; else, xaxcall
      • monitor can alloc/free on behalf of child
      • easy to port to many windows; just change some pointer values
      • could also have patched every entry in std syscall table, but discouraged since it affects every process i the system
    • loaders: have elf and pe-coff loaders
    • browser integration: local server appears as same origin; most URL requests go through to host but /_xax/ refers to existing/new picoprocess
  • examples
    • headline reader (audio) and 3D demo (10 fps) shows we can deliver rich content
    • social network visualizer shows utility of leveraging existing graphviz legacy code
    • ghostscript (pdf) and kaffe (jvm) shows this can replace browser plugins
  • evaluation
    • performance: high xaxcall overhead; fast(er) as java; much faster than v8
    • legacy: apps use 15 libs totaling 3.3M loc in 4 langs with minimal changes
    • os-indep: linux & many windows
    • security: trusted code base (TCB) less tha jvm/flash
  • related work
    • TODO
  • limitations
    • threading: need a new xaxcall for spawing & asynchronous signaling
    • porting more mainstream C libs like glibc/MS is harder since they rely on x86 segment registers to manage thread-local storage, which can’t be assigned in user mode, so must emulate or obviate this functionality
    • port more interactive code: GUI libs with few deps (qt/embeded); blit frame buffers; keyboard/mouse events catpure in js

umview

  • linux sandboxing tool; uses ptrace
  • tried contributing some kernel patches for ptrace perf (pmulti)

web

forcehttps

  • stricter https error processing; treat errors not as possible misconfigs but as attacks
  • prohibit mixed http/https
  • simple url rewriting rules: //foo.com/blah gets the current http/https prepended

low-level

MODERN EXPLOITATION AND MEMORY PROTECTION (alexander sotirov)

  • memory corruption vulns: stack cookies/canaries, NX mem, ASLR
  • windows mitigations: GS, SafeSEH, DEP, ASLR, SEHOP
  • vuln classes: stack overflows, heap overflows, fmt strings, int overflows
  • assumptions
    • fixed addrs of stack & exes
    • fn ptrs at well-known locs
    • heap allocator that trusts heap metadata
    • executable data on stack and heap
  • mitigations
    • GS: stack cookies, var reordering, strict_gs_check
    • safeseh: handler chain, validation
    • heap protection: safe unlinking, safe lookaside lists, heap metadata cookies, heap metadata encryption
    • DEP: NX support, permanent DEP, optout mode by default
    • ASLR: PEB/TEB, heap, stack, images
  • detect mem corruption: GS stack cookies, SEH chain validation (SEHOP), heap corruption detection
  • stop common exploitation patterns: GS var reordering, safeseh, DEP, ASLR
    • rand cookie is generated every run; xor fn ptrs w rand cookie; code that uses the fn ptr xor’s
  • cookies
    • perf impact to cookies
    • ways to bypass; addressed by reordering; still a few special case vulns (eg overriding EHs, fmt strings)
  • safeseh is a list of valid exception handlers which is checked before jumping to an exception handler
    • however, requires all DLLs to be compiled using SEH; single non-compat DLL is enough to bypass protection
    • control flow modification still possible
  • SEH chain validation (SEH override protection aka SEHOP)
    • each stack frame is chained by a linked list
    • put random cookie at end of linked list
    • on exception, walk entire list and validate that the end of list has cookie
    • if SEH record is overwritten, SEH chain will break and cookie won’t be found
    • no known bypasses
    • exception handling is already pretty slow by design
  • DEP: off by default for compat reasons (eg JVM)
    • IE8 finally turned on DEP for plugins
    • return oriented shellcode (ret2libc): DEP w/o ASLR is completely useless

Auth systems

  • Atlassian on-premise suite: accepts LDAP dirs; no SAML; serves OpenID
    • uses own Seraph lib
    • reports of success with CAS, JOSSO, KRB
  • Google Apps: OAuth, OpenID, SAML2 client
  • SFDC: SAML1.1, custom SOAP API (“delegated auth”), auth providers
  • JASIG CAS: SAML2 server as plugin
  • Shibboleth, ZXID, JOSSO: SAML servers

SSO protocols

  • SAML: flexible choice of binding mechanism
    • redir to ident provider then back, supplying auth token
  • SAML2 vs OpenID (TODO)
    • SAML2 supports signout
    • OpenID has dynamic discovery protocol; user usu supplies OpenID provider
  • CAS: underlying model is compat w SAML (https://wiki.jasig.org/display/CAS/Shawn+CAS+and+SAML)
    • unlike CAS, confirmation of association btwn ticket & svc is responsibility of web app, not of CAS
  • KRB