Web Security Firewalls, Buffer overflows and proxy servers

system vulnerabilities Almost all vulnerabilities come from bugs in the implementation of, or misconfigurations of, the OS and/or apps Rarely, a problem with a protocol itself Vulnerabilities can lead to: Unauthorized access: attacker gains control of the victim’s machine (attacker can log in, read files, and/or make changes to the system) Denial of Service against host (attacker can crash the computer, disable services, etc.) Denial of Service against network (attack can disrupt routing, flood the network, etc.)

CSI/FBI Computer Crime and Security Survey

Statistics

buffer overflows on the stack func_1() { int a, b; func_2(); } a, b c, d func_2() { int c, d; func_3(); } func 1’s address buf func_3() { char buf[100]; read_user_input(buf); } func 2’s address

buffer overflows on the stack func_1() { int a, b; func_2(); } a, b c, d func_2() { int c, d; func_3(); } func 1’s address buf func_3() { char buf[100]; read_user_input(buf); } func 2’s address evil_assembly_code() buf’s address Attacker is supplying input to buf… so buf gets a very carefully constructed string containing assembly code, and overwriting func 2’s address with buf’s address. When func3 returns, it will branch to buf instead of func2.

Exploitations Stack Based Exploitations Overwrite local variable near buffer to change behavior of the program Overwrite return address in the stack frame Heap Based Exploitations Overwrite Heap arrays to change behavior of the application Overwrite malloc pointers who then overwrite a function pointer (Microsoft JPEG GDI+ vulnerability)

Protection against overflows Choice of programming language C and C++ provide no built-in protection, but STL has safe libraries Java,.NET bytecode environments do runtime checking (Safety vs perfdormance) Stack-smashing protection checks to make sure the stack hasn’t changed after a procedure call NX (no execute) permission setting on stack and heap (OpenBSD, Mac OSX) Address space layout randomization keeps hackers from designing overflow kits

firewalls Routers: easy to say “allow everything but…” Firewalls: easy to say “allow nothing but…” This helps because we turn off access to everything, then evaluate which services are mission-critical and have well-understood risks Note: the only difference between a router and a firewall is the design philosophy; do we prioritize security, or connectivity/performance? (configurability, logging)

Rest of the InternetLocal siteFirewall

Company netFirewall Web server Random external user Remote company user Internet Firewall

typical firewall setup DMZ evil Internet internal network

the firewall setup Firewall ensures that the internal network and the Internet can both talk to the DMZ, but usually not to each other The DMZ relays services at the application level, e.g. mail forwarding, web proxying The DMZ machines and firewall are centrally administered by people focused on security full-time (installing patches, etc.); it’s easier to secure 20 machines than 20,000 Now the internal network is “safe” (but not from internal attacks, modems, etc.)

Firewall Details Rules based on IP Source Address IP Destination Address Encapsulated Protocol TCP/UDP destination port TCP/UDP source port Eth Dest Eth Src Eth Hdr IP Dest IP Src IP Hdr TCP DPort TCP SPort TCP Hdr Data

External client External HTTP/TCP connection Proxy Firewall Internal HTTP/TCP connection Local server Proxy Firewall

Application Proxy Changes source address so that responses come to proxy from web server Proxy is more secure than internal nodes Performance degradation

Firewalls Compared to Proxies Pros Good Performance Easy to support new protocols Cons IP TCP/UDP headers cant be trusted Most attacks spoof IP TCP/UCP ports Must look at other application signatures