Transcript Network Security

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
Statistics
buffer overflows
on the stack
func 2’s address
buf
func_3()
{
char buf[100];
}
read_user_input(buf);
func 1’s address
a, b
c, d
func_2()
{
int c, d;
}
func_3();
func_1()
{
int a, b;
}
func_2();
buffer overflows
on the stack
func
buf’s
2’saddress
address
evil_assembly_code()
buf
func_3()
{
char buf[100];
}
read_user_input(buf);
func 1’s address
a, b
c, d
func_2()
{
int c, d;
}
func_3();
func_1()
{
int a, b;
}
func_2();
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)
Firewall
Rest of the Internet
Firewall
Local site
Firewall
Remote
company
user
Internet
Random
external
user
Firewall
Company net
Web
server
typical firewall setup
evil Internet
DMZ
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
Data
Proxy Firewall
Firewall
External
client
Proxy
External HTTP/TCP connection
Local
server
Internal HTTP/TCP connection
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