Web Security

Web based threats

Web connects huge number of

• users; targets and attackers

• services, with valuable data

Web server vulnerabilities past-present

In the past, web servers would return a static http page.

Nowadays, web servers fetch applications and databases which are more vulnerable. Vulnerability levels of client and server have mostly remained the same

SQL injection

Attacker injects SQL code into the user input of a web application

Ex. password field used to fill in partial SQL code

SQL Injection and the Kill Chain

Find a vulnerable web app on a server with access to an interesting DB. Discovers vulnerabilities and related attacker capabilities (login, read DB, write,...), how to get around defenses, etc.

Crafts input that achieves those capabilities by achieving an intended action, or getting the means to perform an action (ex. credentials)

SQL Injection Countermeasures & Mitigations

Input filtering / sanitation, disabling DB features, parameterizing queries by using DB function instead of direct query

Cross Site Scripting (XSS)

Attacker injects code (script) into a trusted webpage (ex. through posted comments / responses to parameterized requests)

Victim runs code on their own machine for attacker’s own gain (credentials, info, privileges, etc.)

XSS using request parameters

Exploit webpage rendering nonexistent parameter in HTML by injecting malicious code in the url itself, creating a malformed url. This malformed link is then distributed to a victim (malicious code can be designed not to show an error)

How can the attacker get a user to accept a malformed link?

Hide from view with long url, or encode it

XSS countermeasures

Client side: Difficult to distinguish, hence user education - do not follow sketchy links even if from trusted site

Server side: Filtering of input data and converting to safe strings (ex. < to &it). Difficult for some service such as email which needs html in url

Decrease value of information that can be stolen; e.g., accept cookies only from correct IP.

XSS Injection and the Kill Chain (Conclusion)

XSRF (Cross-Site Request Forgery)

Exploit user’s logged in session, attacker creates malicious website with a link that activates API request with user’s session cookie (ex. transferring money to a different user).

XSRF Login Variant

Victim is tricked into entering malicious website which logs into the attacker’s account on a service via API request. Victim unknowingly uses this account and enters sensitive data

(D)DoS

Exploit vulnerability of network service implementations

Overload the service with requests

Exploit vulnerability of network service implementations Example

Ping of Death Service flaw (1990s):

Correctly formed ICMP (echo) message typically small (eg 56bytes), but IP message can carry a much bigger payload.

Use an abnormally sized packet to cause buffer overflow resulting in unpredictable behavior (crash)

Overload the service with requests - examples

Use protocol features; e.g. (SYN flood - intentionally do not complete the handshake to make server stay idle for abnormal period of time)

Duplicate messages by involving others (eg broadcast addresses contacting all devices in network, spoof receiver’s IP to another server so they receive amplified responses)

Simply have more (distributed) resources that target (botnet, DDoS), attack through multiple sources

IP spoofing

Source IP Address can be modified with no validation method for receiver

Checksums only check for bit errors, not authentication itself

DDoS Ping Amplification Example

Attacker spoofs IP, sends ping request to broadcast address which distributes ping request to all users on network. Each response is directed to target IP

NTP monlist amplification attack

Use monlist (600 last connected IPs), send ping requests to each of these IPs using spoofed IP of victim

Distributed Attacker Resources

Many attacks use large quantity of IoT devices: subvert large number of machines (bots aka zombies) to form botnet. Botnet bombards target with requests at specific time

DDoS mitigation

CP 38->SAV(I), uRPF, IP traceback

BCP 38

Network device checks if a packet's source IP address actually belongs to the network it came from. If it doesn't, the packet is dropped

SAV(I)

Inspect network signals like DHCP messages or router advertisements to create a very accurate "binding" between a device's IP address and its physical location on the network, preventing

uRPF

Router looks at the source IP address of an incoming packet. It then checks its routing table to see if the router would use the same interface to send a packet back to that source. If not, packet is dropped

IP Traceback

Goal: reconstruct the path of the attack traffic and identify the ingress point—the router closest to the actual attacker

Controlling the bot net

Hierarchy to control the bot net;

• Attacker controls `master bots’

• Which each control `slave bots’

• Reflectors: The uncompromised machines that are used to aid in the attack (can also provide amplification)

Attack prevention and preemption DoS Countermeasures

Prepare to endure attack attempts without denying service to legitimate clients

• enforcing policies for resource consumption (ex. quotas) & providing backup resources available on demand; cloud-hosted services, IP Anycast.

• modify systems/protocols to limit (D)DoS potential; configure only servers to respond to ping, disable (access to) broadcast address, etc.

Cloud hosted services

Large capacity data centers; more resources than single server

Can upscale resources used for busy services.

Anycast

Allows multiple servers to provide the same service (on same IP);

• geographically distribution can lower latency

• offers load balancing, makes DDoS harder and limits its effects

Attack detection and filtering (during the attack) DoS Countermeasures

Attempt to detect the attack as it begins and respond immediately to minimize impact.

• Detection involves looking for suspicious patterns of behavior

• Response involves filtering out packets likely to be part of the attack

• Collaborate with upstream networks where possible

Attack source traceback and identification (during and after the attack)

Attempt to identify source of the attack as first step in preventing future attacks.

Difficult, may not be fast enough to mitigate ongoing attack.

Standard Domain to IP Resolve Process

Client asks local NS if it is cached. If not, asks Root NS, which will recursively redirect request to deeper level NS until NS of the actual web domain is found

DNS Spoofing / Poisoning

Attacker sends DNS request to target name server. It also sends fake authoritative NS responses associating the domain with a spoofed IP linking to attacker’s NS, which the target name server stores as cache (glue record)

DNS Spoofing / poisoning against Client

If attacker successfully spoofs domain, client will use attacker’s NS instead and retrieve a harmful webpage

DNSSEC

When redirects to NS are given, associated public key of that NS signed by the current NS’s private key is also given, ensuring a chain of trust

DNS over TLS(DoT)/HTTPS(DoH)

TLS rather then UDP based, uses authentication and encryption protocols of TLS to secure connection rather than the data itself (DNSSEC has same capabilities but must be setup manually)

TLS is more expensive due to handshakes for simple interactions - vulnerable to DDoS attacks