Rise and Hack!: February 2015

Thursday, February 12, 2015

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.

Wednesday, February 11, 2015

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.

Encrypt the Diffie-Hellman Exchange communication with a PRE-SHARED SECRET KEY.
Encrypt the Diffie-Hellman Value, with other side's public key.
Sign the Diffie-Hellman Value, with your side's private key.
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

Checksum
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.

Use two different keys to Authenticate Bob & Alice. This will require additional storage and configuration.
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.

Monday, February 9, 2015

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.

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

Sunday, February 8, 2015

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 (<)
Entity references always begin with an ampersand (&) and end with a semicolon (;)
For < , > the corresponding entities are < >
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>

After Injection (Injected content in RED)

<Amount> 1000 </Amount>

<FundsCleared>True </FundsCleared>

<Amount> 1000 </Amount>

</Transfer>

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

<Amount> 1000 </Amount>

<FundsCleared>True </FundsCleared>

<Amount> 1000 </Amount>

<FundsCleared>False</FundsCleared>

</Transfer>

The Injected content Can include comments to comment out a part of the XML Request


<Amount> 1000 </Amount>

<FundsCleared>True </FundsCleared>

<!--Amount> 1000 </Amount>

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

</Transfer>

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

Saturday, February 7, 2015

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

Perform decoding & canonicalization of user input.
Check if the filename contains backslash (\), forwardslash(/) , null bytes, if yes, then stop processing
Hard code the list of permissible filetypes and reject any request for a different file type.
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.
Java - Java.io.File.getCanonicalPath ,
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)

Use a tool like FileMon (Win), ltrace/strace (Unix) to moniter file system activity
Using Burp Intruder, inject a UNIQUE STRING into every user injectable parameter in the application.
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

foo.txt

/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.

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

Thursday, February 5, 2015

Session Management & Access Control - Notes

Session Management Functionality

Used to uniquely identify a Given User Across multiple requests
Used to handle the "State Data" associated with a given user's session
Helps persist the assurance of a given user's identity beyond the authentication step.

Consequence of Attacks on Session Management

Attacker can assume the identity of another user without knowledge of their credentials
Assume identity of admin & own the application.

Why do we need State?

HTTP is a stateless protocol.
HTTP has No mechanism to link a series of requests to a particular user.
Business Applications need a mechanism to keep track of requests coming from the same user.
State information can Include - client IP address, User-Agent, e-mail, username, user ID, role, privilege level, access rights, language preferences, account ID, current state, last login, session timeouts, and other internal session details.

How do we maintain State?
Three mechanisms exist

Sessions are used to maintain state.
HTTP Authentication can be used to maintain State

The credentials are submitted along with each request in HTTP Headers

Basic, Digest, NTLM mechanism

Sessionless State mechanisms

State data is stored on client

State data is stored in a hidden form field or cookie.

State data stored on the client must be protected, so it is encrypted or signed.

State data should include sufficient context in order to prevent an attacker from replaying it later.

Vulnerabilities in Session Management Mechanism fall in two groups

Weakness in the generation of tokens
Weakness in handling sessions tokens

Token Generation Weaknesses

Concerns related to weak tokens apply to

Password recovery tokens sent to Email
CSRF tokens
One time access tokens
Tokens used for "Remember Me" functionality
Tokens allowing "Unauthenticated Customer" to see the "Order Status"

1. Meaningful Tokens are weak

Tokens generated using transformation of user-related data

Are weak
Exhibit Structure & are often separated by delimiter.
Can be broken down into SubParts & Analyzed
Subparts can be analyzed for meaning & their function

Attack:

Such tokens are commonly encoded using XOR, Base64, Hex, ASCII.

Try decoding various decodings to Unpack the token

Not all components of a structured token may be processed by the application

--Narrow down on useful components of a token to reduce entropy & complexity.

User "Char frobber" payload type in Burp Intruder to modify a token one character at a time.

2. Predictable Tokens can be guessed

Predictable tokens

do not contain meaningful data
but can be guessed ( might involve trial & error)
a sample of tokens can be used to generate other valid tokens

Predictable token are generated using

hidden pattern (hidden using encoding)
time dependency - time is used as input to token generation algorithm
Weak Random number generator. - sample of tokens can be used to find the sequence of tokens that the algorithm will generate next

Securing Session Management

Generate STRONG Tokens

1. To Generate strong tokens

Use an extremely large set of possible values
Use a strong source of pseudo-randomness, to ensure unpredictability.

2. Token should have no Meaning or Structure ( not even hidden or obfuscated structure)

3. Source of randomness should be chosen carefully

Java.util.Random - can be extrapolated both forward & backward given a single output.
Java.util.Random - should not be used

4. Use only those algorithms which are "Explicitly" described as "Cryptographically Secure"

5. Along with chosen source of Randomness, Include the following as a source of entropy

Source IP
User-Agent
Time of request in Milliseconds

6. Above sources of entropy will mitigate any weakness in the PRNG

7. Highly Effective Formula to generate a token

HASH (PseudoRandom Number + User-Specific Data + Secret String ( generated fresh on reboot))

Protect Tokens Throughout Their Life Cycle

Tokens should only be transmitted over HTTPS
Prevent Brute force - Length of token should be at least 128 BITS ( 16 BYTES)
Entropy - Avoid Birthday attack - Session ID must provide 64 bits of entropy. Entropy is estimated to be Half of the length of the session ID. So 128 BITS is a good length.
We can generate Cryptographically strong session ID using HASH Functions.
Cookies should use the "Secure" cookie attribute
Application must not accept any cookies submitted through "URL".
Use HTTPS throughout the application, including static pages (help & Images)
Do not offer public unencrypted contents and private encrypted contents from the same host, instead use two different hosts, such as www.example.com over HTTP and secure.example.com over HTTPS for sensitive contents (where sessions exist). The former host only has port TCP/80 open, while the latter only has port TCP/443 open.
Avoid HTTP to HTTPS redirection on the home page (using a 30x HTTP response), as it can be used by an attacker to gather (or fix) a valid session ID.
The session ID must be renewed after any privilege level change within the associated user session. Ex- from anonymous user state to the authenticated state, password changes, permission change, regular user role to an administrator
If multiple cookies are set for a given session, we must verify all cookies (and enforce relationships between them) before allowing access to the user session.
Use client side JavaScript code to capture web browser tab or window close event and close the current session before closing the web browser, emulating a logout.
Bind the session ID to client IP address, User-Agent, or client-based digital certificate. If a change or anomaly is detected change or anomaly in the middle of an established session, this indicates session manipulation and hijacking attempts.
Limit Cookies using cookie scope, and avoid submitting tokens for accessing static resources
Never transmit token in URL as it gets logged
Cookies disabled ? - Use post request for navigation & store token in hidden form field
Logout should be implemented
Logout should invalidate the session token & dispose all session related data
Session Expiration should be implemented ( keep it small 10-30 mins)
Session Expiration should invalidate the token & dispose all session related data
Concurrent logins should be prevented
A new token should be issued at login, everytime.
HelpDesk should not get to see the User-Session-Tokens
Domain & Path of "Session Cookies" should be set as Restrictively as possible
Arbitrary & Unrecognized tokens submitted by users should not be accepted.
Fresh session should be created after "successful authentication" to mitigate session fixation

Session Fixation AttackVulnerability exists when - application does not assign a new session ID after Successful Login
Attack : 1. Attack obtains a valid session by connecting to the application2. Making a user authenticate with that session ID

Set the sessionID in the URL

Set the sessionID in hidden form field

Set the sessionID in cookie, using XSS vulnerability (:P)

3. Then hijacking the validated session

18. In case where an application handles sensitive credit card data, without authentication
Ex: Shopping without logging in

Keep the checkout page sequence really small & generate a new session at first page of this small checkout process.
Use per page tokens, to be safe from an attacker who knows the token used on first page of the checkout process, from accessing user data.
Personal data should be masked & not completely shown back to the user.

Cookie Domain Restrictions

Some sub-domains of a given domain may have a lower level or trust, so sensitive cookies should be restricted from being submitted to these sub-domains.

Cookie "domain" ignores both the "Protocol" & "Port", so an application with same domain, but a different Protocol or Port will have access to the cookies.

Cookie is set by "foo.bar.com" & "domain" attribute is NOT set.

Cookie is submitted to "foo.bar.com"
Cookie is submitted to all sub-domains like "admin.foo.bar.com"
Cookie is NOT submitted to the parent domain - "bar.com"
Make sure any subdomain is not unsafe

Cookie is set by "foo.bar.com" & "domain = foo.bar.com"

Cookie is submitted to "foo.bar.com"
Cookie is submitted to all sub-domains like "admin.foo.bar.com"
Cookie is NOT submitted to the parent domain - "bar.com"
Make sure the sub-domains are not unsafe.

Cookie is set by "nuclear.facility.com" & "domain=facility.com"

Cookie is submitted to "nuclear.facility.com"
Cookie is submitted to all sub-domains like "admin.nuclear.facility.com"
Cookie is submitted to the parent domain - "facility.com"
Cookie is ALSO submitted to all sub-domains of parent domain "unsafeapp.facility.com"

Cookie Path Restrictions

Application at path /app/secure/a/b/index.jsp sets a cookie

Browser will by default submit the cookie to /app/secure/a/b/ & its sub-directories
Browser will NOT submit the cookie to the parent directory

When path is set to "/app/" by the application at /app/secure/a/b/index.jsp

Then cookie is submitted to all sub-directories of /app/

However,

Path based security mechanism are ineffective, because it is stricter than same-origin-policy
Its easy to obtain a cookie scoped to a different path
A malicious path may open a window targeting a different path of same domain & can read & write to that window without restrictions, because same-origin-policy allows this

Per Page Tokens

A new token is created along with each user request (is stored in cookie or Hidden form)
Fine-grain control over sessions is achieved
Both main session token & per-page token are validated with each request
Online banks uses-per page tokens for increased security

Benefits of per page tokens

Prevents session fixation attacks
will block a hijacked session after a single request is made by both attacker & user
Can be used to track the user's movement through the application.
Can block attempts to access a functionality out of a defined sequence.

Reactive Session Termination

Used by online banks
terminate session every time user submits anomalous request
can slow down the probing of application by many orders of magnitude.