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

infrastructure (network/host) vs (web) application security
- infrastructure: $9.1B to secure $98.5B assets (9.23%)
- application: $750M to secure $64.4B assets (1.2%)
- http://jeremiahgrossman.blogspot.com/2010/02/infrastructure-vs-application-security.html

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
  - eg, adding slashes (php addslashes()) is insufficient
  - addslashes("\xbf27") is '\xbf5c27', and '\xbf5c' is a valid char in GBK, swallowing the slash/letting the quote work
  - http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string
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
  - http://iacoma.cs.uiuc.edu/~greskamp/pdfs/598cz.pdf
  - NaCl
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

caja
secure ecmascript: http://ses.json.org/

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
- http://www.imperialviolet.org/2010/08/16/dnssectls.html

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
- can decrypt GSM phone calls in real time
- http://www.schneier.com/blog/archives/2008/02/cryptanalysis_o_1.html
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

WEP: can be sniffed by any user
WPA/WPA2: diff link key per user, unless they can capture initial handshake
- pre-shared key (PSK) means this link key can be recovered trivially from initial handshake
http://serverfault.com/questions/149888/wep-wpa-wpa2-and-wifi-sniffing

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
- BarsWF: CUDA-based MD5 cracker; 4B hashes/s with quad SLI; http://3.14.by/en/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

auto-elevating executables: to reduce annoyance
- but anyone can run them; at one pt rundll32 was auto-elevating
auto-elevating components
- work only when caller is ms-signed exe, eg explorer
- but procs can inject code into ea other as long as same user
http://arstechnica.com/microsoft/news/2009/03/opinion-ms-should-kill-win7-uac.ars

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 ﬁles, new sockets, etc., by setting the current and maximum RLIMIT_NOFILE limits to 0.
    - Prohibit ﬁlesystem 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
- can escape as root, or else re-chroot, inject modules, ptrace non-chrooted procs, etc
- sensitive to TOCTTOU
  - disallow clone() with CLONE_VM, prevent creating writeable MAP_SHARED mem maps (or at least track them)
  - alternatively SIGSTOP/SIGCONT all processes in traced group
  - http://stackoverflow.com/questions/4414605/how-can-linux-ptrace-be-unsafe-or-contain-a-race-condition
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)

dyntaint: nifty; only does basic taint
decorators: @untrusted, @ssink(TYPE), @cleaner(SQLI) where TYPE denotes channel type with relevant attacks (SQLI, OSI)
http://www.juanjoconti.com.ar/2010/07/06/talk-taint-mode-for-python-via-a-library-slides/

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

Internal Access Controls: Trust But Verify (Google, 2014)

https://queue.acm.org/detail.cfm?id=2697395
core:
- regular automated monitoring/verifying of access configs
- auditing user access to data
granularity: users too fine/tedious, RBAC can be too coarse (union of diff roles = too much access); must accept imperfection
monitoring: specify invariants, tests auto-verify
- catch diffs btwn static and live configs
- verify config is behaving as expected
- tripwire: notify people of changes
- catch drifts e.g. gradual increases in # authorized people
- verify that separation of perms holds (eg 1 user having both code change and push perms)
auditing: do routinely
- catch inappropriate access
- can find/prune unused perms
- good tools should only flag unusual patterns for manual review
- no substitute for good access controls

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Security.page

Security.page

SFI

engineering

web

DOS

fun exploits

IFC

DIFC

malware

systems security

seminal

Sandboxing

web

low-level

Auth systems

SSO protocols

Files

Security.page

Latest commit

History

Security.page

File metadata and controls

SFI

engineering

web

DOS

fun exploits

IFC

DIFC

malware

systems security

seminal

Sandboxing

web

low-level

Auth systems

SSO protocols