Common TCP/IP Protocols

Logical Address:

• The internetwork address of a machine.
• It is unique universally ( for a local network, universe is the small local network)
• It is implemented in software.
• IP address is the logical address in TCP/IP protocol suite.

Physical Address:

• At physical level, a host or a router is recognized by its Physical address
• Physical address is useful only in local network.
• It has to be unique locally but doesn't need to be unique universally.
• It is usually ( but not always) implemented in HARDWARE.
• MAC address is a physical address.

Static Mapping:

• To create a table containing the IP to MAC address mapping.
• Table is stored on each machine on the network.
• Limitation: Physical address of a machine may change for many reasons.
• Limitation: Static mapped table has to be updated periodically.

Dynamic Mapping:

• Using ARP, RARP to find either the IP or the MAC address of a machine.

ARP (Address Resolution Protocol)

• If sender has the local IP address, and needs to know the Physical address to send a packet in local network, it uses ARP protocol.
• ARP is used for dynamic mapping.
• Maps LOGICAL ADDRESS to PHYSICAL ADDRESS.
• ARP packet contains the (IP, MAC) of sender and (IP) of receiver, and is sent to BROADCAST address FF:FF:FF:FF:FF:FF ( all 1s). 
• All hosts receive the packet but only the intended recipient recognizes the IP address and sends back an ARP Response Packet. The response is UNICAST only to the ENQUIRER. 
• ARP request is Broadcast & ARP response is UNICAST.

RARP ( Reverse Address resolution Protocol)

• Dynamically Maps PHYSICAL address to LOGICAL ADDRESS
• When a DISKLESS machine wants to get its OWN LOGICAL address after a reboot, it sends a RARP to BROADCAST FF:FF:FF:FF:FF:FF ( all 1s) address.
• Response is sent by the RARP SERVER as UNICAST.
• Alternatives to RARP: BOOTP & DHCP ( provides additional info like subnet mask also)
• RARP Server does not provide info like subnet mask, which is required by a diskless host.

WHAT IS ARP Spoofing?

• ARP spoofing or ARP cache poisoning is a technique by which an attacker sends (spoofed) Address Resolution Protocol (ARP) messages onto a local area network. 
• The aim is to associate the attacker's MAC address with the IP address of another host, such as the default gateway, causing any traffic meant for that IP address to be sent to the attacker instead. 
• The attack can only be used on networks that use the Address Resolution Protocol
• ARP Spoofing can be used for DoS & MITM attacks.

Prevention?

IP Protocol

• Connection-less, Unreliable , best effort delivery service.
• Provides addressing and routing capabilities for each data packet.
• Used as transmission mechanism by TCP/IP Protocol. 
• Data is packed in a Datagram
• Datagrams can take different routes and arrive out of order.
• Datagrams might be duplicated.
• Doesn't keep track of route.
• Doesn't order the packets.

ICMP: INTERNET CONTROL MESSAGE PROTOCOL

• IP protocol lacks the ability to report errors & to check if a particular host is alive.
• ICMP compensates for the lack of error control & query facilities in IP protocol.
• ICMP  is a companion of IP protocol.
• ICMP protocol is a Transport layer protocol, but its packets are not directly sent to the Data Link Layer. They are first encapsulated INSIDE an IP datagram.

ICMP Error Reporting

• ICMP always reports errors to the original Source ONLY.
• ICMP error message will NEVER be responsed with an ICMP error message
• ICMP error message is NOT generated for a datagram with MULTICAST Address.
• ICMP error message will NOT be generated for a special IP address ( 127.0.0.1, 0.0.0.0)
• Destination Unreachable: ICMP message is generated in response to destination(host or protocol or port) unreachable. 
• Source Quench : ICMP message is generated if there Congestion at the router or destination, slow down babe! (Sender)
• Time Exceeded
• Parameter Problem ( ambiguity or missing field in datagram)
• Redirection: Host's (non-router) routing table is updated statically. A method of updating the routing table is to send the packet to wrong router. It will be redirected to the correct router and an ICMP message will be sent to the host to update its routing table.

ICMP for Diagnostic purposes

Echo-request & echo-reply ICMP messages: 

• Used to check if the host is able to communicate with the destination host or router.
• Used to check if intermediate routers are working.
• Used to check if IP protocols on source & destination are working properly.
• Echo-request is sent by the Sender.
• Echo-reply is sent by the destination.

Time stamp request & time-stamp reply ICMP messages:

• Used to calculate the round-trip time between source & destination even if their clocks are not synchronized.

Address mask request & Reply ICMP messages:

• Used to find out host's own address mask from a router.
• May be used in combination with RARP(to find IP) in case of diskless hosts.

How does Ping work? PING - Packet internet groper command.

• Ping is a network utility which can generate a series of ICMP echo-request & echo reply messages to test the reachability of a host. 
• It also provides statistical information about RoundTrip time by sending its own time stamp in the optional data section of the ICMP echo-request & echo reply message.
• Ping program has to be stopped using CTRL+C otherwise it goes on.
• Ping prints - TTL, packet loss, number of packets sent, number of packets received etc.
• TTL part of the Ping command = number of maximum hops allowed

How does traceroute (UNIX) work

• Traceroute is used to trace the route of a packet from source to destination. 
• Traceroute uses two error messages - TIME EXCEEDED & Destination Unreachable 
• Traceroute program sends an IP packet using UDP (destined to the wrong port). 
• The TTL of the IP packet is incrementally set to 1,2,3,4,5 until the destination is reached. 
• Each router on the path to the destination will decrement the TTL and whenever TTL 0 is reached the router will send back an ICMP "Time Exceeded" error message along with its own IP address. 
• Traceroute also calculates the round trip time for each of these intermediate routers
• In each of these messages the UDP packet is sent to a port that is not supported by UDP. When the packet reaches the destination and TTL=0 it WILL NOT throw a "Time exceeded" error. However, the destination host sends an ICMP "Destination Unreachable" packet, because the port number is wrong. This error message indicates that the destination has been reached.

OSI Model & TCP/IP Model

OSI Model 

Application Layer: 

• This layer includes the Protocols which support an Application.  It does not contain the application itself. 
• When the application needs to send the data across, then it passes the data to the protocols that support it. 
• Eg: A browser generates an HTTP Request on form submission.
• HTTP, SMTP, FTP

Presentation Layer:

• Formats the information into a form that everyone will understand.
• This layer is concerned with the Syntax and format of Data.
• If a browser is used to upload a picture, it will be converted into an HTTP Request and the picture will be represented in a standard format like JPEG, TIFF, GIF, which the receiving side will understand the type of Information contained in the Data.
• This layer is responsible for Translation ( System dependent to System Independent format)
• This layer is responsible for Encryption or Compression of Information 

Session Layer:

• Is responsible for establishing/ maintaining/ terminating a session with an Application.
• Allows communication between applications in Simplex, Half-Duplex and Full-Duplex forms.
• It is also called "port layer"
• It manages Application-to-Application Sessions
• Example: Images, HTML, CSS files are all stored as separate files on a web server. To download each of them a separate download session is started. The session layer keeps track of which packets and data belong to which file and keeps track of each download session.
• The session layer is responsible for session checkpointing and recovery. 
• Session layer allows information of different streams, to be properly combined or synchronized (Eg - different files being downloaded for loading a single webpage)
• In TCP/IP this functionality is handled by application software(browser) addressing a connection to a remote machine and using a different local port number for each connection
• AppleTalk Session Protocol, NetBios are Session Layer Protocols.

Transport Layer

• Transport Layer ensures delivery from one (Source IP, Port) to Another (Destination IP, Port)
• The transport layer ensures that messages/data are delivered without errors, in sequence, and with no data content losses or data content duplications.
• Session Layer acts as a manager and manages the multiple files delivered by Transport Layer to be properly combined or synchronized.
• TCP & UDP are transport layer protocols.

Network Layer

• Responsible for Source IP address to Destination IP address delivery
• IP, ICMP, OSPF, BGP, IGMP protocols work at this layer.
• Ping operates by sending Internet Control Message Protocol (ICMP) echo request packets to the target host and waiting for an ICMP response. In the process it measures the time from transmission to reception (round-trip time) and records any packet loss. Since PING uses ICMP protocol, it is not associated with any PORT number.
• If two systems were connected to the same Link, there would be no need for a Network Layer.
• Network layer is needed when, two devices are connected to two different Networks
• Network layer provides the routing mechanism for packets.

Data Link Layer:

• Responsible for moving a FRAME from one node to the next.
• Physical Addressing - Assigns the sender and receiver of the frame.
• Flow Control - Rate at which data is absorbed by the receiver
• Error Control - Detects and re-transmits damaged or lost frames. Error control is achieved through check-sum added at the end of frame.
• Access Control - Determines which node has control of the link at any given time.
• ARP, RARP, PPP ( Point to Point Protocol)

Physical Layer:

• Moves bits from one hop to the next.
• This layer converts bits into voltage for transmission.
• This layer controls synchronization, data rate, line noise and medium access.

Diffie-Hellman Algorithm - Simple Overview

Diffie-Hellman Algorithm allows two parties to agree on a Shared Secret Key while exchanging messages in Public.

Diffie Hellman is ONLY used for Key-Establishment. 

These keys might be used for any purpose depending on the protocol.

Diffie Hellman does not authenticate, so its possible to establish a Secret-Key with a Bad-Guy.

Technical Details

Diffie-Hellman relies on the difficulty of calculating Discrete Logarithms. 

• p is a Prime Number
• g is a Primitive Root of P
• (Primitive Root means -  p^k mod g  will return ALL values from (1, 2 , 3.....p-1) for the first p-1 values of k)
• p & g are public and can be intercepted during communication.

Protocol

1. Alice chooses private key "a"   

    Bob chooses private key "b"

2. A computes a public value A = p^a mod g

    B computer a public value B = p^b mod g

3. A and B are exchanged publicly 

4.  Alice calculates    K = B^a mod g  = p^ab mod g

     Bob calculates      K = A^b mod g  =p^ab mod g

5. K is the shared secret between Alice & Bob

Alice and Bob can now use K for whatever purpose they want.

Vulnerabilities

An attacker could be doing a man in the middle attack, by establishing two separate keys with Bob & Alice and then being the middleman in their conversation.

Solution: Authenticated Diffie Hellman Exchange.

1. Encrypt the Diffie-Hellman Exchange communication with a PRE-SHARED SECRET KEY.
2. Encrypt the Diffie-Hellman Value, with other side's public key.
3. Sign the Diffie-Hellman Value, with your side's private key.
4. Transmit a HASH(DiffieHellmanValue, Name, Pre-Shared-Secret) to the other side.

Authentication Protocol Design Concepts

What is Challenge Response mechanism?

Sometimes we need to prove the knowledge of a secret without actually revealing the secret. This is particularly useful when the channel is insecure . Challenge response is a method used to prove the knowledge of a secret key without revealing it.

Protocol Decription: In the scenario where two parties share a secret key.

• The two parties exchange random numbers, Ra & Rb. 
• Each receiving party encrypts the Random number with its Secret key and transmits it back to the sender. 
• On receiving the encrypted random number, the sender tries to decrypt it with the secret key it knows. If the decryption is successful then sender knows that the other party has knowledge of the secret.

Security Pitfalls: Minor variant of a secure protocol can have security holes.

How would you do an Integrity Check?

There are two methods

1. Checksum
2. MAC or HMAC - requires a key

How to design a protocol?

• Start with a design, which will most certainly have flaws.
• Check for all possible weaknesses and fix them.
• So the more we know about types of possible flaws the better it is.

Below is a description of some simple protocols, their weaknesses and possible fixes.

Protocol Flaws associated with Secret Key Based Protocols

1. Protocol: Sending the password in clear text.

    Problems: Eavesdropper can intercept to the password during transmission.

    Enhancement: Instead send a challenge to the client, the client applies a function on the Shared         Secret key and the challenge and sends the value to the server. 

Function (Shared Secret, Challenge)

    

2. Protocol: Only the client side authenticates itself using Function (Shared Secret, Challenge)

Problems: 

• If an attacker can intercept the communication between client & server, then the attacker can send responses to the client by spoofing the server IP address as it doesn't need to know the secret key shared between the server & client. Attacker can simply retransmit an old challenge to the client.
• Attacker can mount an offline password guessing attack, to guess the key assuming he knows the Challenge, Function used, and value of Function (Shared Secret, Challenge)

3. Protocol: After one side authentication, the conversation is sent over clear text

Problems:

• Attacker simply hijacks the conversation (after the initial authentication), if he is able to send packets using the server's IP address.

4. Protocol: 

• Client claims, (I am Alice) to the Sever. 
• Then server sends an encrypted Random Number, with the Key shared with Alice. 
• Client decrypts the Random Number and sends it to Server there by proving knowledge of Key.

Problems:

• This protocol will require reversible cryptography algorithm to decrypt the Random Number. Hashes cannot be used in this case. Hashes provide performance advantage. Sometimes export issues arise when Encryption is used. Hashing is less likely to have export problems.
• If shared key is derived from a Dictionary word, it is vulnerable to dictionary attack.
• If the Random Number is recognizable, the attacker can simply claim to be Alice ( I am Alice) and receive an Encrypted challenge, try to decrypt it using dictionary attack. Once a recognizable number ( say 32bit number padded with 32 bit zeros) is generated, the attacker will know the Secret.
• If the attacker is eavesdropping (more difficult than claiming to be Alice), then he can read both the Random Number & the encrypted value. He can then try to mount a dictionary attack.

Enhancement: Random Number R is made to have a limited lifetime by concatenating it with a timestamp. This will foil replaying of an old  Encrypted Random Number, as the decrypting party will realize that this random number was generated at an earlier time.

5. Protocol: A single handshake is sent to the server, containing the identify claim and an encrypted time-stamp.

                  I am Alice, Key[timestamp]

Problems:

• Requires that client & server have reasonably synchronized clocks (within acceptable clock skew)
• An eavesdropper can retransmit I am Alice, Key[timestamp] within acceptable clock skew and impersonate Alice.                                                                                                            Enchancement: Server keeps a history of all timestamps sent by Alice, until the acceptable clock skew expires, thus detecting a re-transmission
• If Alice, uses the same key for multiple servers, then I am Alice, Key[timestamp] can be re-transmitted to other servers if done within acceptable clock skew.                                           Enchancement: Concatenate the server-name with the timestamp to foil this.                                                          I am Alice, Key[ServerBob + timestamp]
• If the server is vulnerable to clock resetting attack, then the Attacker may be able to reuse old encrypted time-stamps by resetting the clock on the server.                                                           Enchancement:  Authenticate based on challenge/response to allow server clock management.

6. Protocol: A single handshake is sent to the server, containing the identify claim and a hash of Secret key & time-stamp.

                          I am Alice, HASH[SecretKey ,timestamp]

Problems:

• If the timestamp is in minutes and the allowed clock skew is 10 minutes, the Server will need to Hash 10 different timestamps to verify the secret key. This might be acceptable.
• If timestamp is in milliseconds, trying all timestamps would be unacceptably inefficient.

Enchancement: Send the timestamp along with the identity claim

                I am Alice, TimeStamp, HASH[SecretKey,timestamp]

 

Common Problem with Secret Key Based Protocols

If the attacker gets access to the Database of one of the communicating parties. The attacker may be able to get access to shared secret keys as well as any encrypted timestamps received.

Protocols Flaws Associated with Public Key Based Protocols

1. Protocol: 

• Client claims, (I am Alice) to the Sever. 
• Then server sends a Random Number, to the Client (Alice.)
• Client SIGNS the Random Number with his Private Key,and sends it to the Server.
• Server verifies the Random Number based on Client's Public Key, thereby ensuring that Client knows his Private Key.

Problem: 

• Attacker, can trick the Client (Alice) into signing something, and use that Signed Value later to forge the Client's Signature. ( If he impersonates the Server's address, waits for Client to connect and then send the quantity as a challenge to the Client)

2. Protocol: 

• Client claims, (I am Alice) to the Sever. 
• Then server sends a Random Number, encrypted with the Client's Public Key, to the Client (Alice.)
• Client DECRYPTS the Random Number with his Private Key,and sends it to the Server.
• Server verifies the Random Number, thereby ensuring that Client knows his Private Key.

Problem:

• If the attacker is able to impersonate Server's address, then the Attacker can trick the Client (Alice) into decrypting something that was earlier sent to the Client encrypted with his Public key. 

Solutions to Protocol 1 & Protocol 2 Problems:

Issue: Each independently secure protocol scheme, can compromise the security of another if you use same keys for both.

• Do not use the same key for two different purposes ( Encryption, Signature). This will prevent an attacker from using one protocol to break another.
• Ensure that different uses of the same key are coordinated. Example: If the key is used to encrypt a Challenge and a Message, then add structure to the Quantity by Concatenating a Field before the quantity to identify the type of Field.

What is the reflection Attack?

When mutual authentication is part of a protocol, then each party needs to solve the challenge sent by the other party. 

The attacker posing as Alice and attempting to connect to Bob, is able to trick one of the parties to provide an answer to the challenge posed by Bob.

1. Bob provides the solution to Bob's challenge.

Connection 1

• Attacker poses as Alice and sends his challenge R1 while trying to connect to Bob.
• Bob replies with solution to Attacker's Challenge S1, and sends his own challenge R2 to Attacker.
• (Attacker now needs to provide Solution S2 to prove the knowledge of the shared secret)

Connection 2

• Attacker poses as Alice and send another challenge R2 while trying to connect to Bob again.
• Bob replies with S2 and sends his own challenge R3 to the Attacker.

Now Attacker, goes back to the Connection 1 and uses the solution S2 provided by Bob in Connection 2 and proves knowledge of Bob's shared secret key with Alice. Thus Bob himself got tricked into providing the solution to his own challenge.

2. Alice Provides the solution to Bob's challenge

Connection 1

• Attacker poses as Alice and sends his challenge R1 while trying to connect to Bob.
• Bob replies with solution to Attacker's Challenge S1, and sends his own challenge R2 to Attacker.
• (Attacker now needs to provide Solution S2 to prove the knowledge of the shared secret)

Connection 2

• Attacker poses as BOB and send a challenge R2 while trying to connect to Alice.
• Alice replies with S2 and sends his own challenge R3 to the Attacker.

Now Attacker, goes back to the Connection 1 and uses the solution S2 provided by ALICE in Connection 2 and proves knowledge of Bob's shared secret key with Alice. Thus Alice got tricked into providing the solution to BOB's challenge.

Solution to Reflection Attack

• Have both Bob & Alice do the same thing differently.
• Also Initiator should be the first one to prove its Identity.

1. Use two different keys to Authenticate Bob & Alice. This will require additional storage and configuration.
2. Challenge from Initiator should be different from the challenge from the responder. Eg : Initiator of the connection can use Even numbers while Responder can use Odd Numbers.

Authentication Protocol Design Flaws CheckList

Consider the following as a list of things when you have to design a new Authentication Protocol.

Lets Assume, Alice is the Client and Initiates the conversation and Bob is the Server.

If an attacker 

• Shouldn't be able to understand the conversation between Client & Server
• Shouldn't be able to do a reflection attack to impersonate either Client or Server
• Shouldn't be able to Impersonate by replaying the authentication information to other servers & get authenticated
• Shouldn't be able to do an offline password guessing attack to find the Secret Key.
• Shouldn't be able to convince the Server that he is Alice.
• Shouldn't be able to convince the Client that he is Server.
• Shouldn't be able to trick either party into signing or decrypting something. 
• Shouldn't be able to decrypt old recorded conversations between Client & Server.
• Shouldn't be able to Hijack a conversation that was started by either Client or Server, without having one of the parties notice the change. 
• Modify the messages or replay, rearrange, or reverse the direction of messages.

Server Side HTTP Redirection, SMTP Injection, HTTP Parameter Injection, HTTP Parameter Pollution - Notes

==============================================================================

Server Side HTTP Redirection

==============================================================================

Vulnerability exists when the APPLICATION SERVER uses an Attacker controllable input and incorporates it into a URL and retrieves it using a back-end HTTP Request.

• Attacker may use the Application Server as Proxy to connect to a Internal Network resource which are not accessible directly
• Attacker may use this to attack 3rd party systems
• Attack may connect to other services on the Application Server itself, circumventing Firewall restrictions & exploiting trust relationships.
• Attacker can use it to include external Attack Scripts

Attack : If you are able to identify a vulnerable parameter

• Try to port scan the internal network using Burp Intruder.
• Try to connect to other services on Application Server using 127.0.0.1

==============================================================================

HTTP Parameter Injection

==============================================================================

Vulnerability exists when user supplied "Parameters" are used as "Parameters" to a BackEnd HTTP Request.

• Attacker may Inject additional Parameters ( URL encoded ), which are then submitted to the backend service. This might interfere with the application logic.
• These additional parameters may not cause any error ( Unlike SOAP Injection)
• Attack Requires knowledge of backend parameters or access to Code (Whitebox Testing / 3rd party component)

Example :      from=1234&to=54321&amount=1000%26FundsCleared%3DTrue&Submit=submit

==============================================================================

HTTP Parameter POLLUTION ( too many parameters)

==============================================================================

Vulnerability exists because, different web servers behave differently when they receive multiple parameters with the same name. Below are the common behaviors

1. First instance of the parameter is used
2. Last instance of the parameter is used
3. Parameter values are concatenated
4. Parameter values are inserted into an array

Success of Attack depends on how the target server handles multiple parameters

Example

Attacker Submits the following

from=1234&to=54321&amount=1000%26FundsCleared%3DTrue&Submit=submit

After Processing the following is submitted to the back end Service

from=1234&to=54321&amount=1000&FundsCleared=True&FundsCleared=False&Submit=submit

==============================================================================

Attack against RESTstyle URL Rewriting 

==============================================================================

When REST Style parameters are used ( where parameters are placed in filepath instead of the query string), the translation processing might be vulnerable to HTTP Parameter Injection & HTTP Parameter Pollution

Example:

/app/user/adam         (RESTStyle URL)  gets translated to the below URL
app/profile.php?mode=view&user=adam   

If the Attacker sets his name as    /adam%26mode=edit, then it gets translated to the following

app/profile.php?mode=view&user=adam&mode=edit

The success of attack depends on how multiple parameters are handled by the server.

==============================================================================

Email Header Manipulation

==============================================================================

• Some applications offer a facility to email the support staff.
• The application sends a SMTP message to the email server.
• Vulnerability exists when the message submitted by the user is not filtered or sanitized by the application.
• Email functionality allows the sender to submit his emailID, Subject, Message

PHP mail() command

• constructs the email and performs the SMTP conversation with mail server
• additional_headers parameter specifies the "TO, CC, BCC" by separating each header with a new line.
• Sender ID:      abc@gmail.com%0ABcc:all@website.com

==============================================================================

SMTP Command Injection

==============================================================================
When the application itself performs the SMTP Conversation, it is possible to Inject SMTP Commands.

• SMTP client issues "DATA" command and then sends the Message Headers & Body.
• To finish the message, a single DOT (.) is sent after a new line (CRLF)

SMTP INJECTION

• Text in Red is the Injected content.
• Injected content is URL-Encoded and Injected in the Subject Header.
• This constructs two email messages
• Email message ends with a DOT after a NEW LINE.

MAIL FROM: abc@gmail.com

RCPT TO: support@gmail.com

DATA

From: abc@gmail.com

To:   support@site.com

Subject: Feedback

Site is not working

.

MAIL FROM: abc@attacker.com

RCPT TO: all@site.com

DATA

From: abc@attacker.com

To:   all@site.com

Subject: ATTACK

This is an Attack

.

Preventing an SMTP Injection

1. Email message should be checked against, regular expressions

2. Subject should not contain new Line

3. Length of Subject should be Limited

4. Alternatively, provide hardcoded subject messages

5. Lines containing a single dot should be disallowed.

==============================================================================

XML Injection, SOAP Injection - Notes

==============================================================================

XML Injection

==============================================================================
XML is used extensively in web applications

• In Request & Responses to submit data & receive data from server.
• In Messages between back-end components
• AJAX mostly uses XML for communication with server.
• Browser extension components also use XML to communicate with server.
• Content type: text/xml

XML EXTERNAL ENTITY ATTACK ( XXE Injection )

Entity Reference:  

• Characters with special meaning in XML like "<" will generate an error as it is interpreted as the start of a new element. 
• To avoid errors, replace the "<" character with an entity reference (&lt;)
• Entity references always begin with an ampersand (&) and end with a semicolon (;)
• For < , >  the corresponding entities are     &lt;    &gt;
• XML allows CUSTOM ENTITIES to be defined at the start of XML document itself using DOCTYPE element.
• <!DOCTYPE note [ <!ENTITY testreference "referencevalue"> ]>
• &testreference; will be replaced by referencevalue

Vulnerability exists because 

• XML parsing libraries support the use of ENTITY REFERENCES.
• XML allows the use of EXTERNAL REFERENCES, whose values are fetched dynamically
• EXTERNAL ENTITY definitions use the URL Format & can refer to web URLs or local file.
• If the XML response contains an "External defined ENTITY", THEN the contents of specified URL or FILE are RETRIEVED & INCLUDED in the response.

ATTACKER simply specifies an external entity in his XML Request by adding or modifying DOCTYPE element.

•  SYSTEM keyword is used to specify an EXTERNAL ENTITY
•  URL may use also the    file:     protocol
• <!DOCTYPE note [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
• <!DOCTYPE note [ <!ENTITY xxe SYSTEM "http://www.foo.com/hack.txt"> ]>
• <foo>  &xxe;  </foo> 
• The contents of the file will replace      &xxe;

Consequences of XXE

• Attacker can use application as proxy to access external server as well as Internal resources and services
• Attacker can test for open ports on backend systems.
• Attacker can cause a DoS attack, by reading a file stream indefinitely.

==============================================================================

SOAP ( Simple Object Access Protocol) INJECTION

==============================================================================

SOAP INTRODUCTION

Web Service uses two methods to exchange data

1. SOAP (Simple Object Access Protocol)
2. REST (Representational State Transfer)

• SOAP uses HTTP protocol to transmit messages
• SOAP uses XML to represent the data  (Content-Type: application / soap+xml)
• Using user-supplied-data in SOAP messages can lead to vulnerabilities.
• Directly exposed web-services are worthy of vulnerability examination
• WSDL (Web Services Description Language) file describes the following

-How to call the web service
-What parameters it expects
-What data structure it returns

• Tools for testing WEB Service Testing - SoapUI

Web Service ( on the Left )

SOAP Request (on the Right)

SOAP INJECTION VULNERABILITY

• Vulnerability occurs because SOAP uses XML, and XML is an Interpreted Language.
• If the ATTACKER is able to inject METACHARACTERS like < > and / in a SOAP messages, then it can interfere with application's logic.

Injecting an additional <FundsCleared> True </FundsCleared>, in a bank application

• It may allow funds to be transferred even if there are no funds
• This Attack depends on how the application processes multiple elements with same TAG
• Inject has to be done in a way that preserves the XML Syntax

Preventing SOAP Injection

Implement BOUNDARY VALIDATION filters

• Filter at Application Boundary- when data is received from the USER
• Filter at SOAP service Boundary -, after the input data has been generated, or extracted from DB or processed from user supplied Input.

HTML Encode XML Metacharacters like < > / etc.

Attacking SOAP Service

To test if vulnerability exists >>>> Try inserting      </foo>   in each parameter, if you get an error, then input is being used in a SOAP service.

• SOAP Injection Vulnerability is difficult to detect
• SOAP Injection Vulnerability is harder to exploit as it needs knowledge of XML Structure, a verbose error message might help in this case. Else its pure guesswork.

Example ATTACK

Expected Request Format

<Transfer>

    <From>        1235 </From>

    <Amount>      1000 </Amount>

    <To>          54321</To>

</Transfer>

After Injection (Injected content in RED)

<Transfer>

    <From>        1235 </From>

    <Amount>      1000 </Amount>

    <FundsCleared>True </FundsCleared>

    <Amount>      1000 </Amount>

    <To>          54321</To>

</Transfer>

Request After getting processed by the application
(works if the application process the FIRST <FundsCleared> Tag it encounters)

<Transfer>

    <From>        1235 </From>

    <Amount>      1000 </Amount>

    <FundsCleared>True </FundsCleared>

    <Amount>      1000 </Amount>

    <FundsCleared>False</FundsCleared>

    <To>          54321</To>

</Transfer>

The Injected content Can include comments to comment out a part of the XML Request
<!-- Comment   -->

<Transfer>

    <From>        1235 </From>

    <Amount>      1000 </Amount>

    <FundsCleared>True </FundsCleared>

    <!--Amount>   1000 </Amount>

    <To>   --><To>54321</To>

</Transfer>

==============================================================================

OS Command Injection, Path Traversal & Local File Inclusion Vulnerability - Notes

When data is passed from one component to another

Data considered "Safe" by one component may NOT be Safe for an Onward component

• Attacker may pass crafted input which may be interpreted as commands in an Onward component

Onward component may have much more functionality, than what the application component uses.

• Attacker can exploit this additional functionality

==============================================================================

OS Command Injection

==============================================================================

• Vulnerability exists when >>> User supplied input is passed to system shell.
• Attacker supplies crafted input, which is passed as parameter to shell functions like system() or exec() 
• Commands are executed with the Privilege of the vulnerable "Application"
• Commonly found in ADMIN interface of an - Application Server, firewall, router, printer

Crafted Input usually contains Shell Meta-characters

• Pipe Character "|" redirects output from one process to input of another.
• Pipe Character "|" can be used for chaining multiple commands
• Semicolon ";" is a command separator.
• Ampersand "&" is used as command separator to batch multiple commands
• Command1 & Command 2 , second commands runs regardless of success of first
• Commands1 && Command2 , second command runs only when first is successful
• Command1 || Command 2, second commands runs only when second fails
• Placing a command between BackTicks  Eg. `command` causes the Shell to execute it and replace the `command`  with the results of this command. 
• Command1 (`command2`) will evaluate to  Command1 (resultofcommand2)

Checking for OS Command Injection Vulnerability
Most reliable way is to execute a function which causes a time delay.

• ||   ping - i   30  127.0.0.1  ||
• ||   ping - n   30  127.0.0.1  ||
• Try all the MetaCharacters     |   `  &   ;    %0A    ||    &&

If time delay occurs then application may be vulnerable to command Injection

If you are not able to retrieve the results of your command, you have two options

• Output the results into  \wwwroot\output.txt file and use browser to view it
• Use TFTP to copy tools up to the server, then use telnet to create a reverse shell and Use mail command to send output to yourself via SMTP

Prevention of OS Command Injection Vulnerability

1. Avoid calling OS commands directly

• For a web application, Built-in APIs are a very good alternative to OS Commands. 
• Built-in API cannot be manipulated to perform tasks other than those it is intended to do.

2. If use of OS commands is unavoidable,

• WhiteList approach should be used. Allow only alphabets and numbers.
• Meta-characters and white-spaces should be rejected. 
• Additionally, use Command API like "Runtime.exec" in Java & "Process.Start" in ASP.NET which launch a specific process via (name, command line parameters) instead of directly passing the input to a shell interpreter. 

Note: Command APIs like - Runtime.exec tokenizes the input into an array of words, then executes the first word in the array as command with the rest of the words as parameters. The risk in using "Runtime.exec" depends on the command being used in source code. If "cmd" is used as command, then there this poses risk of OS Command Injection. Another risk associated with Runtime.exec is that of the user entering an unintended parameter.

3. Applications should use minimum privilege accounts or use multiple low privilege accounts.

Following functions are exploited to carryout OS command Injection

PHP    - exec,  eval,   passthru,    proc_open,   shell_exec,   system,    backtick operator (`)
C/C++ - system,    execlp,   execvp,    ShellExecute,    _wsystem
JAVA  - Runtime.exec
==============================================================================

Path Traversal Vulnerability

==============================================================================

Vulnerability exists when user-controllable data is used to access files & directories in an unsafe manner.
Attacker supplies crafted input which may allow him unintended read or write access to files.

Consequences/Risk : May allow an attacker to read or overwrite sensitive files

• Password files for OS and Application
• Server and Application Configuration files
• Include files containing database credentials
• MySQL database files or XML files
• Source code files
• Log files containing usernames or session tokens

If you get write access then, it can ultimately be used for arbitrary command execution.

• Create scripts in startup folder
• Write script in web directory & execute by calling in browser

Preventing Path Traversal Vulnerability

Most effective Technique 

• Avoid passing user submitted data to filesystem API.
• Files which do not need to be access controlled can be placed in webroot & accessed via URL.

If it is unavoidable to take filename as a parameter then

• Maintain a mapping of fileName to fileID
• Allow files to be accessed using FileID only. There is no attack surface in technique.

In case where file upload & download functionality is required & user needs to specify the filename. Take all the following steps

1. Perform decoding & canonicalization of user input.
2. Check if the filename contains backslash (\), forwardslash(/) , null bytes, if yes, then stop processing
3. Hard code the list of permissible filetypes and reject any request for a different file type.
4. Now, use file system API (Eg. getCanonicalPath) to verify that, the file PATH specified is actually the same as the PATH allowed by the application, and only then allow access to the file. 
5. Java - Java.io.File.getCanonicalPath ,                                                                         
6. ASP.NET - System.io.Path.GetFullPath

Use a chrooted environment to mitigate the impact of path traversal vulnerabilites

• Chrooted directory - is treated as filesystem root
• Any attempt to access a directory above it using /../  sequence is ignored.
• On Windows - mount a directory as new logical drive & access it using the associated drive letter. It will not allow access to higher directories using /../ sequence.

Identifying Path Traversal attack targets in an application

1. Initial mapping of the application helps in identifying Path traversal attack targets

2. Thoroughly test the functionality where User can 

• upload or download files
• share documents
• upload images
• download ebooks, documents, manuals

3. Test any GET or POST request PARAMETER which contains a filename or directory name

4. Test application functions which may retrieve data from a server filesystem ( instead of DB)

• displaying documents
• displaying images

5. If you have local access to the application server (Whitebox test)

1. Use a tool like FileMon (Win), ltrace/strace (Unix) to moniter file system activity
2. Using Burp Intruder, inject a UNIQUE STRING into every user injectable parameter in the application.
3. Detect the UNIQUE string injected above using a filesystem moniter tool & Identify the parameter and test it for Path Traversal Vulnerability

Detecting the existence of Path Traversal vulnerability

1. Test whether user supplied crafted input is being blocked by the application

Try the following two as filenames

1. foo.txt
2. /bar/../foo.txt 

If Application behave in the same way for both inputs, then, it MAY BE VULNERABLE

Point to be Noted: Most file systems attempt canonicalization of a filepath before they try to retrieve it, In the above case    /bar/../  cancels out ( folder /bar/ doesn't need to exist

2. To TEST If the application is vulnerable & allows READ ACCESS try the following

• ../../../../../../../../../../../etc/passwd
• ../../../../../../../../../../../windows/win.ini

3. To TEST CONCLUSIVELY, that the application is vulnerable & allows WRITE ACCESS 

Write into a file that any user can write into & then write into a file in which even root cannot write The difference in application response can be USED TO CONCLUDE THAT writing is successful

Try the following in WINDOWS

• ../../../../../../../../../../../test.txt
• ../../../../../../../../../../../windows/system32/config/test ( will fail)

Try the following in UNIX

• ../../../../../../../../../../../tmp/test.txt
• ../../../../../../../../../../../tmp  (will fail)

 Point to be Noted: Overwriting a directory with a file will always fail in UNIX
 Point to be Noted: All file systems ignore redundant /../ sequences, so try submitting a large number of traversal sequences,
Point to be Noted: Windows tolerates both forward and backward slashes as directory separators.
Point to be Noted: Unix only accepts forward slashes as directory separators.
Point to be Noted: Don't rely on the knowledge of OS of the app server, a backend service may be using a different OS, so try both back and forward slashes.

4. Alternative method, to TEST if WRITE ACCESS is working is to try and write a new file in webroot & open it with browser.

Circumventing Flawed Defense mechanisms 

If the mechanism used to prevent Path Traversal is flawed ==> it can be bypassed

1. If the filter attempts to sanitize the input to remove the sequences, it can be defeated with Encoding

2. Try both back & forward slashes, some filters only remove forward slash while file system may         support both. Try the following encodings for   /../

• URL encoding
• 16 bit Unicode encoding
• Double URL Encoding
• Overlong UTF-8 Unicode Encoding
• Use Burp Intruder to generate "Illegal Unicode" within Burp, these may be accepted by the Unicode decoders, particularly on windows.

3. If application removes ../ but doesn't remove it RECURSIVELY from ( ....//), then the following          will work because ../ will get removed and ../ will be left behind.

• ....//
• ....\/
• ....\\
• ..../\

4. If filetype (suffix) is being verified by the application, Sometimes, it can be subverted by placing a      null byte as follows

• ../../../../boot.ini.jpg

Point to be Noted: This works because, this check is done in a Managed Environment (Java) which allows Strings to have a NULL character, but the API actually retrieves the file in an UNMANGED environment, in which Strings are NULL Terminated.

 5. If application appends the filetype suffix on its own, then also NULL byte attack can work

 6. If an application tries to verify that that the filename starts with a particular directory name              (downloads), then it can be subverted as follows

• downloads/../../../../../../../etc/passwd

==============================================================================

File Inclusion Vulnerability ( Local & Remote)

==============================================================================

File Inclusion: Some scripting languages ( like PHP) support the use of Include functions ( include() in PHP). The content of included file is interpreted as if the code was actually copied and pasted.

Remote File Inclusion Vulnerability

PHP's include function accepts REMOTE file path, and thus is a basis of numerous vulnerabilities.
Vulnerability exists when >> User controllable input is used to specify the INCLUDE file name.
Attacker can specify an external URL pointing to a malicious script as the location of the include file.

• www.example.com/index.php?Country=US

The corresponding backend PHP code is

$country =$_GET['Country']include ( $country. '.php' );

The contents of  US.php are effectively copied in index.php and then are executed.

Local File Inclusion Vulnerability

When the include function of any language allows local (or only local -Eg. Server.Execute() in ASP) files to be included, and the application accepts User controllable data as input to the Include function then the attacker may be able to specify a local file ( Eg. /Admin.aspx) and have it included in the page.

Attacking File Inclusion Vulnerabilities

• Commonly found in request parameters which specify Language or Location
• Found in parameters which specify a server file name.

To Detect a remote file inclusion vulnerability

• Find the Parameter to be tested & Specify the URL to a server you control and see if your server gets any requests from the vulnerable application

To Detect a local file inclusion vulnerability

• Wider range of scripting environments allow Local File inclusion compared to remote file inclusion
• Submit the name of a known executable or static resource and check if it is included in the response

Mitigation: A safe solution is to use a Switch/Case statement to determine which file to include.

==============================================================================