Phishing (II) - Data URIs scheme with Base64 encoding

PHISHING (II) - DATA URIs SCHEME WITH Base64 ENCODING

- Layout for this exercise:

- This exercise is based in the previous one:

http://www.whitelist1.com/2018/04/phishing-i-local-redirection-and-remote.html

- The goal of this exercise is to launch a page-less phishing attack, meaning that there is no need of hosting an html file on a server.

- The phishing bait will be embedded in a URI, using the Data URIs scheme.



1 - Redirecting user input to the attacker machine

- At the attacker machine Windows 10 let's open the index.html file inside xampp > htdocs using Notepad:




- Finding action= and replacing the line with the below string, where 192.168.1.6 is the Windows 10's attacker IP:



- In this way, any user input entered in a connection to the fake web page will be redirected to the file mail.php, where the credentials will be harvested.


2 - Encoding index.html with Base64

- Base64 is a group of similar binary-to-text encoding schemes that represent binary data in an ASCII string format by translating it into a radix-64 representation.

- Each Base64 digit represents exactly 6 bits of data, so three bytes (24 bits) can therefore be represented by 4 six-bit Base64 digits:

https://en.wikipedia.org/wiki/Base64

- Now, using  Base64 encoding scheme, let's encode the whole index.html page, for instance with the tool offered by this website:

https://www.base64encode.org/




- These encoded characters must be copied and stored for further use.

- Finally, before launching the attack let's remove index.html from xampp > htdocs, because this will be a page-less phishing attack:

3 - Data URIs scheme

- The data URIs scheme is an Uniform Resource Identifier (URI) scheme that provides a way to include data in-line in web pages as if they were external resources: 

https://en.wikipedia.org/wiki/Data_URI_scheme


- This technique allows normally separate elements such as images and style sheets to be fetched in a single Hypertext Transfer Protocol (HTTP) request, which may be more efficient than multiple HTTP requests.

- In other words, small files can be incorporated online into documents.

- The syntax of data URI schema using base64 is composed of four parts:

data: <mediatype> ; <base64> , <data>


- In our case let's prepend data:text/html;base64, to the encoded index.html:

data:text/html;base64,PCFET0....

1) data: <- prefix for the schema
2) text/html <- MIME data type 
3) ;base64 <- Base64 encoding is in use
4) ,PCFET0.... <- index.html encoded with Base64






4 - Launching the attack

- Now, when the victim enters the data URI schema  into the browser (it could be provided by spam email or social engineering), a Facebook fake home page is presented.

- Entering credentials:




- Immediately a log.txt is created at the attacker side, where email and password are harvested:

Phishing (I) - Local redirection and Remote hosts file manipulation

PHISHING (I) - LOCAL REDIRECTION AND REMOTE HOSTS FILE MANIPULATION

- Layout for this exercise:


     

1 - Introduction

- Phishing is the attempt to obtain sensitive information such as usernames, passwords, or credit card details for malicious reasons by disguising as a trustworthy entity in an electronic communication:

https://en.wikipedia.org/wiki/Phishing

- The word is a neologism created as a homophone of fishing due to the similarity of using a bait in an attempt to catch a victim. 

- Phishing is typically carried out by email spoofing or instant messaging, and it often directs users to enter personal information at a fake website, the look and feel of which are identical to the legitimate one and the only difference is the URL of the website in concern.

- Phishing is an example of social engineering techniques used to deceive users, and exploits weaknesses in current web security.

- Attempts to deal with the growing number of reported phishing incidents include legislation, user training, public awareness, and technical security measures.


2 - Creating a fake web page

- The goal of this exercise is to create a fake web page identical to the Facebook home page www.facebook.com

- The victim will connect to the fake page believing that he is connected to the real Facebook home page, and he will enter his credentials (email/password) innocently.

- The attacker will redirect the credentials to a log file of his interest (log.txt), so that he will appropriate such credentials and could make malicious use of them.

- Of course, this exercise could be extended to any type of website, such as social networks, banking, insurance, business, etc ...

- First of all, let's backup all the XAMPP files (xampp/htdocs from the attacker machine Windows 10) to a safe place, because we are going to replace it with a new web content:




- Now, going to www.facebook.com let's click Save Page from the browser (Firefox in this case) and download the whole web page to the folder xampp/htdocs of the attacker machine Windows 10 :





- Renaming the downloaded content to index.html, this will be the home page of the fake website:





- Now, the attacker Windows 10 holds a copy of the Facebook home page at its xampp/htdocs folder:












3 - Local redirection

- Then, the attacker writes the file mail.php (storing it at xmapp/htdocs), whose purpose is to redirect any user input to the text file log.txt:




- Let's notice the line where log.txt is open and created:




- Opening index.html with Notepad:





- Finding action=, the original action is replaced with action="mail.php", which will send the user's input to the text file log.txt:















- Now, let's try locally the fake web page and the bait, writing localhost at the browser, and entering some test credentials, for instance:

email:johndoe@gmail.com
password: passwordforjohndoe





- A new log.txt is created immediately, where we can find the test credentials successfully harvested:







4 - Remote Hosts file manipulation

- To  test that the fake web page works remotely, let's connect the victim Windows 7 to the attacker's IP (192.168.1.6), entering some credentials, and finally checking that the attacker is able again to harvest a remote user's credentials:







- Now we have achieved a greater degree of effectiveness in the attack, because we have harvested the victim's credentials remotely, not just locally.

- However, this scenario as described before is unlikely to happen in the real world, because a normal connection to www.facebook.com from the victim would direct to the real Facebook home page, not to the fake one.

- How to achieve that the victim connects to the fake web page instead of the real one?

- The answer is Hosts file manipulation.

- The plain text hosts file maps hostnames to IP addresses, containing lines of text consisting of an IP address in the first text field followed by one or more hostnames, being each field separated by white spaces.

- The hosts file assists in addressing network nodes in a computer network, serving the function of translating human-friendly hostnames into numeric IP addresses, that identify and locate a host in anetwork.

- The other method to achieve the same result is the well-known Domain Name System (DNS).

- Unlike remote DNS resolvers, the hosts file is under the direct control of the local computer's administrator, so it can be manipulated remotely for instance as part of a post-exploitation process.

- Some examples of altering files remotely when post-exploitating a system:

http://www.whitelist1.com/2016/06/metasploit-windows-xp-altering-file.html
http://www.whitelist1.com/2016/06/metasploit-windows-xp-creating-files.html


- So taking for granted that the attacker has got access to altering files remotely (once the victim's machine has been exploitated), let's open the hosts file following this path:

C: > Windows > System32 > drivers > etc > hosts




- Adding a new line, what relates in a malicious way the attacker's IP to the website www.facebook.com:







- Now, when the victim Windows 7 connects to www.facebook.com, the attacker is able again to harvest the remote user's credentials.

- The explanation is that the new hosts file at the victim machine redirects the connection www.facebook.com to the IP 192.168.1.6 (where the fake web page is served), instead to the real Facebook home page:

Buffer Overflow on a Web Application

BUFFER OVERFLOWS ON A WEB APPLICATION

- Layout for this exercise:





1 - Buffer Overflows and Web Applications

- Attackers use buffer overflows to corrupt the execution stack of a web application:

https://www.owasp.org/index.php/Buffer_Overflow

- By sending carefully crafted input to a web application, an attacker can cause the web application to execute arbitrary code effectively taking over the machine.

- Buffer overflow flaws can be present in both the web server or application server products that serve the static and dynamic aspects of the site, or the web application itself. 

- When web applications use libraries, such as a graphics library to generate images, they open themselves to potential buffer overflow attacks.

- Buffer overflows can also be found in custom web application code, and may even be more likely given the lack of scrutiny that web applications typically go through. 

- Buffer overflow flaws in custom web applications are less likely to be detected because there will normally be far fewer hackers trying to find and exploit such flaws in a specific application. 


2 - Exercise scenario


- In this exercise the OWASP WebGoat v5.4 version is used, loaded at a Windows 10 machine.

- Going to Buffer Overflows -> Off-by-one Overflows:





- The description of this exercise is a hotel with a web form ready to enter information for the guests registration system:





- Once the web form is filled, a Price Plan is offered to be accepted by the guest:






3 - Launching the Buffer Overflow attack

- The challenge of the exercise is to reveal information and data about VIP guests, by taking advantage of the Buffer Overflow vulnerability suffered by the application.

- The strategy is to test various character strings with different lengths (1025, 2049, 4097, ..) until you find the one that causes the buffer overflow and therefore the disclosure of confidential information stored by the vulnerable application.

- First, let's generate a string of 1025 characters with a Python interactive script:


etc ...


- Entering the string of 1025 characters at the 3 input fields:




- Accepting the Price Plans:




- However, there is no interesting output or revealed information:




- Same result would happen from entering  a string of  2^11 + 1 = 2049 characters:




- However, a different output is achieved when entering a string of 2^12 + 1 = 4097 characters:




- Entering 4097 characters all the hidden fields are revealed, containing the hard coded information related to the VIP guests:




- Restarting the lesson and entering the new data revealed for the user "Lewis", and accepting a Price Plan:







- Finally, the lesson is successfully completed:





- Checking one by one whether all the three input fields are vulnerable to the Buffer Overflow, it is easy to demonstrate that the third is the only vulnerable one.

- Entering the 4097 characters length string separately into the first two input fields (First_Name and Last_Name) nothing out of the ordinary happens:






- However, entering the malicious string into the third field (Room_Number) provokes the Buffer Overflow and the disclosure of hidden information:




4 - Explanation

- General theory about Buffer Overflow vulnerabilities can be found everywhere in the Internet:

https://en.wikipedia.org/wiki/Buffer_overflow

- Also,  several exercises have been presented about this topic in this blog:

http://www.whitelist1.com/search/label/BUFFER%20OVERFLOW


- Inside a microprocessor, where an application is run, the process stack of the memory  is usually divided in three regions: text (program code), data and stack buffer.

- The data region reserves space of memory for the functions of the application, and it is divided into two parts: 

      i) uninitialized data: variables initialized to zero, or just declared variables
      ii) initialized data: variables with assigned values, for instance the hardcoded VIP list 


- In our example, let's suppose that the web application is composed of 3 main functions:

• function A: checks if the input fields are empty
• function B: selects a price plan
• function C: loads the hardcoded VIP list and stacks the user inputs on the buffer

- Functions A and B would be located at the uninitialized region, and function C would be at the initialized region.

- However, the initialized region where the hardcoded VIP list resides is in contact with the Buffer stack region, so this last region is prone to be rewritten or overflown if there are no clear boundaries for the funcion C.

- There are secure programming methods for checking the functions inputs buffer boundaries, like for instance BufferedInputStream for Java language, and strncpy(), fgets() for C/C++ languages.

https://docs.oracle.com/javase/7/docs/api/java/io/BufferedInputStream.html
http://www.cplusplus.com/reference/cstring/strncpy/
http://www.cplusplus.com/reference/cstdio/fgets/


- These secure programming methods would not admit inputs greater than the established ones by the programmer, and the application would throw error messages if the attacker tried to overflow those values.

- In our case, giving for granted that there aren't any secure programming methods enabled, to perform the Buffer Overflow let's take advantage of the fact that the size of the buffer value is usually assigned in terms of powers of 2^x bytes. For instance x=10,11,12, ...:

• 2^10 = 1024 bytes
• 2^11 = 2048 bytes
• 2^12 = 4096 bytes

- As seen before, both the First_name and Last_name input fields are built with secure programming methods, but not the last one Room_Number.

- Because the attacker does not know in advance the size of the buffer, he launches and trial/error attack by entering strings of characters 1 byte longer than the potential buffer sizes, that is 1025, 2049 and 4097 bytes.

- There is no successful result with the first two trials. However, when entering 4097 bytes there is a success, because the buffer is overflown and the data below the buffer is read, revealing the VIP list.

XPATH Injection

XPATH INJECTION 

- Layout for this exercise:




1 - Introduction

- Similar to SQL Injection, XPATH Injection attacks occur when a web site uses user supplied information to query XML data:

https://www.owasp.org/index.php/XPATH_Injection

- By sending intentionally malformed information into the web site, an attacker can find out how the XML data is structured or access data that they may not normally have access to.

- An attacker may even be able to elevate their privileges on the web site if the xml data is being used for authentication (such as an xml based user file). 

- Querying XML is done with XPath, a type of simple descriptive statement that allows the xml query to locate a piece of information. 

- Like SQL you can specify certain attributes to find and patterns to match. 

- When using XML for a web site it is common to accept some form of input on the query string to identify the content to locate and display on the page. 

- This input must be sanitized to verify that it doesn't mess up the XPath query and return the wrong data.


2 - Launching the XPATH injection

- In this exercise the OWASP WebGoat v5.4 version is used, loaded at a Windows 10 machine.

- Going to Injection Flaws -> XPATH Injection:




- The scenario of this exercise describes how to use a web form to allow employees of a company to see some personal data, like their salary.

- For instance, entering as input fields the right credentials for the user Mike/test123:




- The output displays personal data about the user Mike:




- Now, through the XPATH injection the attacker intends to access personal information of all users of the database.

- For this purpose the attacker introduces the following string in the form, both in the user and password fields: 'or'5'='5





- The attack is successful because the output displays personal data of all users of the database:






3 - Explanation of the XPATH injection

- The file users.xml stores personal data of all the users in the database:





- This XPATH query defines how to navigate the nodes of the file users.xml:

$result=$login->xpath("//users[username=='.$_POST['input'].' AND password== '.$_POST['input'].' ]")


- Both username and password entered by the client must be true because the operator AND gives a true output only if both operands are true (1 AND 1 = 1):

$result=$login->xpath("//users[username==' Mike' AND password== ' test123' ]")


- Crafting a malicious input so that both AND operands are always true, the query bypasses the authentication, grabbing the data of all users in the xml file:

$result=$login->xpath("//users[username==''or'1'='1' AND password== ''or'1'='1' ]")