Category: Networks

Cool Tools Series: Nuclei
Hopefully you enjoyed Adam Fernandez’s recent Cool Tools post, Nmap For Penetration Tests. In this next post in the series, I’d like to introduce another great penetration testing tool: Nuclei.

Nuclei is an outstanding enumeration tool that performs a myriad of checks against the systems and services it discovers. It does particularly well against web applications. It also tests for known vulnerabilities, can pull versioning information from systems, and can try default credentials.

Installing Nuclei

You can use apt to easily install it on Kali Linux:
```
apt install nuclei
```
Templates

Nuclei uses saved templates to perform tests against systems. This lets users create new templates as new discoveries are made. You can also generate custom templates for tasks you often use or things you discover yourself.

More information about these templates can be found here: https://docs.projectdiscovery.io/templates/introduction

You can explore the templates Nuclei uses by default here.

https://github.com/projectdiscovery/nuclei-templates/tree/main

Options

There are a lot of different options when using the tool, but generally, when I’m using it for external network and web application tests, I just pass a target or a list of targets to the program.

To get a full list of options, all you need to do is this command:
```
nuclei –help
```
To scan a single device, simply use:
```
nuclei -u {Target}
```
Here is an example from a recent penetration test. There was only one target, so I simply passed that target to Nuclei:

You can see that Nuclei examined the responses from the web server and found that security-related headers were missing.

Here is an example using Nuclei against a list of targets. I put the targets for the engagement into a file called targets & ran the following command:
```
nuclei -list {File}
```
Real-World Nuclei Discoveries

Here are some examples of useful things Nuclei has found for me during various penetration tests.

Here Nuclei found a Solr panel, revealed the version running, and shared it in a human-readable format easy for me to use as a pentester:

Here Nuclei did some testing against a host on an internal network and successfully performed a Log4j exploit. It then reported the success with a critical flag as this could lead to remote code execution (RCE):

I’ve also found Nuclei’s ability to try default passwords to come in handy when testing.

As an example, I use a self-hosted Git instance and changed the root account’s password to one that Nuclei uses. You can see how Nuclei successfully logged into the GitLab and notified me:

Thanks for Reading

There’s a lot more to Nuclei, but this is a good start. Thanks for taking a look at this post, and I hope you’ll be back for future Cool Tools posts in the series.
September 19, 2024
Cool Tools Series: NMAP for Penetration Tests
In Scottie’s recent Cool Tools blog about discovery tools, he, like many network penetration testers, starts with Nmap. Nmap is a great discovery tool with many flags and scripts. In this post, I will expand upon Scottie’s ideas and delve more deeply into what Nmap has to offer, specifically for network penetration testing.

Hosts Marked as Down When They Are Up

If you find you have problems with Nmap flagging hosts as down, even though they should be up, I would recommend adding these flags to your command:
- -PS – SYN ping scan. You can optionally add a port number after this.
- –PA – ACK ping scan. You can optionally add a port number after this.
- -PE – Typical ICMP ping echo request, typically blocked by firewalls.
- -PP – ICMP timestamp ping query, which can sometimes get around misconfigured firewalls.
- -PM – ICMP subnet mask ping query, also good for evading misconfigured firewalls.
- -PO -This issues an IP protocol ping, which seems to work a lot of times when other probes don’t.
Putting that all together, my typical scans are now starting to look like this:
```
sudo nmap -oA [output] -sSUV --unique --resolve-all -PS -PA -PE -PP -PM -PO -T4 -O -p T:-,U:53,161 -vv -iL [targets]
```
Some other options present here:
- -oA [output] – Output in all file formats simultaneously.
- -sSUV – Combo of -sS (TCP SYN scan), -sU (UDP scan), and -sV (service version scanning).
- –unique – Scan each IP only once (e.g. if raxis.com resolves to 1.1.1.1, and both are targets, only scan 1.1.1.1 once).
- –resolve-all – If an DNS name resolves to multiple IPs, scan each IP.
- -T4 – Go a bit faster than default, recommended for modern networks (unless you’re trying to be quiet).
- -O – Try to determine operating system.
- -p T:-,U:53,161 – Scan all TCP ports as well as UDP ports 53 (DNS) and 161 (SNMP).
- -vv – Be very verbose in output.
- -iL [targets] – Use the targets in the specified file.
Additionally, when using -oA, if your scan gets interrupted, you can use this to resume the scan where it left off:
```
nmap --resume
```
The Nmap Scripting Engine

The Nmap Scripting Engine (NSE) provides 604 scripts and 139 libraries at the time I’m writing this. That number grows each year, so, needless to say, this is a very useful tool for penetration testers or for blue teams checking out possible vulnerabilities in their systems. I’ll discuss some Useful NSE scripts here, and I encourage you to take a look to see if there are others that would be helpful for your needs.

Shodan
- Queries the Shodan API for the targets. Follow the instructions on the NSE site to setup a Shodan API key.
```
nmap --script shodan-api [IP Range] -sn -Pn -n --script-args 'shodan-api.outfile=potato.csv,shodan-api.apikey=SHODANAPIKEY'
nmap --script shodan-api --script-args 'shodan-api.target=[IP],shodan-api.apikey=SHODANAPIKEY'
```
Server Message Block (SMB)
- Check if SMB signing is disabled:
```
nmap --script smb-security-mode -p445 [IP]
```
File Shares
- Attempt to enumerate SMB shares:
```
nmap --script smb-enum-shares -p445 [IP]
```
- Show NFS Shares (Exports):
```
nmap -sV --script=nfs-showmount [IP List or Range]
```
- Attempt to get useful information from NFS shares (mimics an -ls command):
```
nmap -p 111 --script=nfs-ls [IP List or Range]
nmap -sV --script=nfs-ls [IP List or Range]
```
Databases
- Attempts to find configuration and version info for a Microsoft SQL Server instance:
```
nmap -p 445 --script ms-sql-info [IP]
nmap -p 1433 --script ms-sql-info --script-args mssql.instance-port=1433 [IP]
```
- Looks for MySQL servers with an empty password for root or anonymous:
```
nmap -sV --script=mysql-empty-password [IP]
```
Domain Name Server (DNS)
- Perform DNS Cache Snooping:
```
nmap -sU -p 53 --script dns-cache-snoop --script-args 'dns-cache-snoop.mode=timed,dns-cache-snoop.domains={host1,host2,host3}' [IP]
```
- Checks DNS anti-spam and open proxy blacklists to see if an IP has been flagged:
```
nmap --script dns-blacklist --script-args='dns-blacklist.ip=[IP]'
nmap -sn [IP] --script dns-blacklist
```
Virtual Private Network (VPN)
- Checks if the host is vulnerable to the Cisco ASA SSL VPN Authentication Bypass Vulnerability:
```
nmap -p 443 --script http-vuln-cve2014-2128 [IP]
```
Network Time Protocol (NTP)
- Shows an NTP server’s monitor data:
```
sudo nmap -sU -pU:123 -Pn -n --script=ntp-monlist [IP]
```
Remote Access
- Attempts to brute-force a VNC server:
```
nmap --script vnc-brute -p 5900 [IP]
```
- Discovers the security layer and encryption level that is supported by a RDP service:
```
nmap -p 3389 --script rdp-enum-encryption <ip>
```
Network Protocols
- Attempts to brute-force a POP3 account:
```
nmap -sV --script=pop3-brute [IP]
```
- Attempts to brute-force a telnet server:
```
nmap -p 23 --script telnet-brute --script-args userdb=myusers.lst,passdb=mypwds.lst,telnet-brute.timeout=8s [IP]
```
Java
- Attempts to dump all objects from a remote RMI registry:
```
nmap --script rmi-dumpregistry -p 1098 [IP]
nmap --script rmi-dumpregistry -sV --version-all -p 443 [IP]
```
Weak Ciphers & Algorithms
- Enumerates all web ciphers that a server accepts:
```
nmap -sV --script ssl-enum-ciphers -p 443 <host>
```
- Finds the number of algorithms the SSH2 server offers (or lists them with verbosity set):
```
nmap --script ssh2-enum-algos [IP]
```
Certificates
- Displays the server’s SSL certificate. Set verbosity to add more details:
```
nmap --script=ssl-cert -p 443 [IP]
```
Http
- Checks if HTTP TRACE is enabled:
```
nmap --script http-trace -d [IP]
```
July 30, 2024
Cool Tools Series: Host Discovery
Before starting any penetration test, you must know the scope of the work. Depending on the type of assessment, this could be specific hosts or full ranges of IP addresses with live hosts scattered throughout. If the scope is the latter, then it is a good idea to initially identify which hosts are live and then discover common, known vulnerabilities on the hosts. This will narrow down the attack surface and potential attack vectors to help establish a list of priority targets during the assessment.

There are several tools that I like to use when I start a new assessment. Some are free open-source tools, while others are commercial.

Open-Source Tools

Nmap

The first tool I always use in Nmap. Nmap is an open-source tool that can identify live hosts and services by conducting protocol enumeration across systems. It can also be used for specific configuration checks or even as a vulnerability scanner by using the Nmap Scripting Engine (NSE).

Even when I use Nmap with vulnerability scanners, I still regularly utilize Nmap scripts. Nmap come pre-installed with Kali Linux but can easily be installed on any Linux or Windows system. Using Nmap for the first time can be intimidating, but after using it for a bit, users often find it very easy and reliable. I usually run the initial scans by ignoring ICMP checks (Ping) and just assume that all hosts are live. I do this because some network admins like to disable ICMP on live hosts as a security measure (Good on ’em!).
```
nmap -v -A --open -Pn -iL targets.txt -oA nmap_scan
```
Note: -Pn disables the ICMP check.

If the scope is extremely large and the Nmap scans won’t complete in the time allowed, I enable the ICMP check by remove the “-Pn”:
```
nmap -v -A --open -iL targets.txt -oA nmap_scan
```
Below is a screen shot of a typical initial scan I perform on network assessments (internal & external):
```
nmap -v -A -Pn --open {IP Range} -oA {Output File Name}
```
The commands above are easy to learn once you use them a few times, and I’ll cover what is going on here.
- First, I like to use the “-v” which enables verbose outputs.
- The “-A” enables OS and version detection, as well as script scanning and traceroute output.
- “-Pn” disables ICMP ping for host discovery, causing the scan to assume that all hosts are live.
- Next, we have the IP range, in this instance a standard /24 internal network. If I have specific hosts or multiple ranges to target, I will create a text file and use the “-iL” switch to point to the text file.
- Lastly, I like to output the results to all supported formats by setting “-oA.” The reason I do this is because I like to ensure I have the different file types for future use. For example, the .nmap output is easy to read when I want to scan through the output. I typically use the XML output for importing into Metasploit or when using Eyewitness to enumerate web hosts.
There are quite a few good cheat sheets out there too if you let the Googles do the work for you. If not, follow this series for more Nmap tips and tricks in the future.

Masscan

Another tool similar to Nmap is Masscan. Masscan is a TCP port scanner that scans faster than Nmap. Unlike Nmap, Masscan requires you to define the ports you want to scan. I typically don’t use Masscan and just stick with Nmap, but it’s a good option if you want to quickly look for specific open ports on a network.

OpenVas

Another tool I use on occasion is OpenVAS (a.k.a. Greenbone), a vulnerability scanner. Greenbone offers a commercial version, but there is an open-source version available as well. I’ve used this many times when I am unable to access my usual vulnerability scanners. One downside to the tool is that It can be difficult to install. I recently followed the instructions for installing with Kali and ran into quite a few issues with the install. I’ve also noticed that the initial setup can take some time due to the signatures that are downloaded. If purchasing a commercial vulnerability scanner is too expensive, then Greenbone is definitely worth looking into, despite its challenges.

Commercial Tools

Nessus

By far, my favorite vulnerability scanner is Tenable’s Nessus. There is a free version available, but it’s limited to 16 IP addresses. If you are doing a lot of vulnerability scanning or time-boxed penetration tests, then it might be worth looking into purchasing this.

The thing I like most about Nessus is how I can sort by vulnerabilities across all hosts in a given scan. I can also sort these vulnerabilities by risk rating, which helps me narrow down critical or specific vulnerabilities to exploit or signs that a host or service may be a high priority for a closer look.

When viewing Nessus results, never ignore the informational findings. They often provide clues that more may be going on on a host or service than you realize at first glance.

Nexpose

Another great vulnerability assessment tool is Nexpose, owned by Rapid7. Nexpose is similar to Nessus, as it provides similar vulnerabilities. There are some slight differences in the way the products display results.

Nexpose is built around “sites.” Each site has defined hosts or IP ranges under it. From there each host’s vulnerabilities will be listed. The easiest way I’ve found to list out all vulnerabilities is to create a report from the site I’m working in.

Besides greater extensibility, one major advantage with Nexpose is that it ties in with Rapid7’s vulnerability management product, InsightVM. If you’re looking for a full vulnerability management solution and not just a vulnerability scanner, Nexpose is a good option to check out.

There are many other tools that I use, but these are always my first go to tools to start an assessment.

Follow the series!

Stay tuned for more posts in the Cool Tools series, where the Raxis penetration testing team will highlight some of their favorite tools and explain how to get started with them.

Take a look as Adam Fernandez dives into Nmap for Penetration Tests in the next post in this series.
July 2, 2024
How to Create an AD Test Environment

Lead Pentester Andrew Trexler walks us through creating a simple AD environment.

Whether you use the environment to test new hacks before trying them on a pentest, or you use it while learning to pentest and study for the OSCP exam, it is a useful tool to have in your arsenal.

The Basics

Today we’ll go through the steps to set up a Windows Active Directory test environment using Proxmox to virtualize the computers. In the end, we’ll have a total of three connected systems, one Domain Controller and two other computers joined to the domain.

Setting up the Domain Controller (DC)

The first step is to setup a new virtualized network that will contain the Windows Active Directory environment. Select your virtualization server on the left:

This is a Windows based environment, but we’re using a Linux hypervisor to handle the underlying network architecture, so under System, select Network, and then create a Linux Bridge, as shown in Figures 2 and 3:

After setting up the network, we provision a new virtual machine where we will install Windows 2019 Server. Figure 4 shows the final configuration of the provisioned machine:

The next step is to install Windows 2019 Server. While installing the operating system make sure to install the Desktop Experience version of the operating system. This will make sure a GUI is installed, making it easier to configure the system.

Now that we have a fresh install, the next step is to configure the domain controller with a static IP address. This will allow the server to function as the DHCP server. Also make sure to set the same IP as the DNS server since the system will be configured later as the domain’s DNS server.

In order to make things easier to follow and understand later, let’s rename the computer to DC1 since it will be acting as our domain controller on the Active Directory domain.

Next, configure the system as a domain controller by using the Add Roles and Features Wizard to add the Active Directory Domain Services and DNS Server roles. This configuration will allow the server to fulfill the roles of a domain controller and DNS server.

After the roles are installed, we can configure the server and provision the new Active Directory environment. In this lab we will use the domain ad.lab. Other than creating a new forest and setting the name, the default options will be fine.

Setting Up the DHCP Service

The next step is to configure the DHCP service. Here we are using a portion of the 10.80.0.0/24 network space, leaving enough addresses available to accommodate static IP addressing where necessary.

There is no need for any exclusions on the network, and we will set the lease to be valid for an entire year.

Adding a Domain Administrator and Users

Additional configuration is now required within the domain. Let’s add a new domain administrator and some new domain users. Their names and passwords can be anything you want, just make sure to remember them.

First we create the Domain Administrator (DA):

Here we also make this user an Enterprise Admin (EA) by adding them to the Enterprise Admins group:

Next we will add a normal user to the domain:

Creating Windows PC

At this point we should have a functional Active Directory domain with active DHCP and DNS services. Next, we will setup and configure two other Windows 10 machines and join them to the domain.

The first step is to provision the resources on the Proxmox server. Since our test environment requires only moderate resources, we will only provision the machines with two processor cores and two gigabytes of RAM.

Then we install Windows 10 using the default settings. Once Windows is installed, we can open the Settings page and join the system to the ad.lab domain, changing the computer name to something easy to remember if called for.

Adding the system to the domain will require us to enter a domain admin’s password. After a reboot we should be able to login with a domain user’s account.

SMB Share

At this point, there should be three computers joined to the Active Directory domain. Using CrackMapExec, we can see the SMB server running on the domain controller but no other systems are visible via SMB. So let’s add a new network share. Open Explorer.exe, select Advance Sharing, and share the C drive.

I don’t recommend sharing the entire drive in an environment not used for testing, as it’s not secure: the entire contents of the machine would be visible. Since this is a pentest lab environment, though, this is exactly what we are looking for.

Creating the share resulted in the system exposing the SMB service to the network. In Figure 20 we verified this by using CrackMapExec to enumerate the two SMB servers:

Conclusion

At this point, our environment should be provisioned, and we are ready to test out different AD test cases, attacks, and other shenanigans. This environment is a great tool for ethically learning different exploits and refining pentesting techniques. Using a virtual infrastructure such as this also provides rollback capability for running multiple test cases with minimal downtime.

I hope you’ll come back to see my next posts in this series, which will show how to use this environment to test common exploits that we find during penetration testing.

Want to learn more? Take a look at the next part in our Active Directory Series.

April 27, 2023
Notes From a Hacker: Yes, You Have to Use Your VPN – and Here’s Why

Right now, across the globe, there are millions of exasperated IT helpdesk workers on the phone with an equal number of frustrated colleagues who are working from home, some for the very first time. I don’t have exact numbers, but I’m willing to bet that the most common issue they’re discussing is problems logging onto a company’s virtual private network (VPN). From my own experience, at least some of those end users (maybe you included) are asking, “Do we really have to do this?”

The answer is, yes, you do. And, because your IT team is likely overwhelmed right now, I’ll step in and share just a few reasons why a VPN helps keep your company safe from people like me.

The most common threat someone faces on unsecured WiFi networks is a man-in-the-middle (MitM) attack, where a hacker inserts himself into the data stream between two endpoints. You’ve probably been cautioned about public WiFi – coffee shops, airports, etc. – for that very reason. Trust me, it will work on your home as well.

A successful MitM attack allows a bad guy to intercept or modify data in transit, including credentials or financial information. In fact, most wireless attacks are perpetrated with the goal of acquiring MitM access to user data. A VPN connection encrypts your data and makes it much harder for a hacker to steal.

MitM is similar to another threat known as the “Evil Twin” attack. This is sometimes referred to a rogue access point that exploits how wireless endpoints behave. When a phone, laptop, or tablet joins a wireless network, it will remember that connection. From that point forward, the endpoint will send out beacons looking for that network.

Unfortunately for you, it’s easier than you think to trick your devices. We can use tools such as Mana or the WiFi Pineapple to respond to create a fake access point. Your device will associate with it as though it was the legitimate network. From there we have a MitM and can intercept or modify data in flight, or even create fake captive portals to capture credentials.

Other tools help attackers go after wireless networks directly by sending de-authentication packets, which cause devices to disconnect. When they attempt to reconnect to the network, they must re-authenticate. This process involves a four-way handshake in which a hashed form of the Pre-shared Key (PSK) is exchanged. A hacker can capture this handshake and attempt to crack it offline using tools such as Hashcat. If the hash is cracked, the PSK is revealed in cleartext.

The most widely used is the Aircrack-ng suite of tools which includes Airmon-ng for capturing wireless traffic, Aireplay for injecting wireless packets, and Aircrack for cracking the PSK. Other tools such as WiFite offer a menu-driven interface that automates a wide variety of attacks.

You may be thinking these tools are rare and hard to find, but that’s not the case. Both hardware and software are readily available and relatively cheap. They’re also very simple to set up and operate.

My point is that it can be relatively easy for a hacker to compromise your home WiFi. By contrast, your IT security team has a number of safeguards in place to protect you and the company’s network from the tools and tactics I described above. Extending that protection to those working remotely is the reason you have to use your VPN.

Does that mean you can’t be hacked? Certainly not. But it does make my job a lot harder and it probably will cause me to move on – to another employee, another method of attack, or best case, another company.

Preferably one that doesn’t use a VPN for remote workers.

May 1, 2020
Goodies for Hoodies: TCP Timestamps

The Picts were a tribal culture in northern Scotland that history has relegated to the realm of myth and enigmatic legend. Largely forgotten, the Picts fought off the military superiority of Rome’s army and built a sophisticated civilization on the whole before disappearing from history. These were a people dismissed by the advanced thinkers of the day as unimportant and trivial in their capabilities, only to rise up unexpectedly to great effect. What does this have to do with Security? Nothing really, unless your data center is staffed by Roman centurions on horseback. If that’s you, then I am ripe with envy. But all levity aside, so it was with the Picts, it is today with the humble and unassuming TCP Timestamp.

What is a TCP Timestamp?

If you’ve ever run a vulnerability scan, you’ve probably seen a low or informational severity finding associated with TCP Timestamp responses. The recommendation is always to disable them, but rarely is any background information provided. What are those little timestamps doing there and who really cares anyway? Like the Picts, much lies below the surface, and we dismiss them at our peril. Before we can get into the ramifications of this misunderstood protocol option, we must understand the mechanics behind TCP Timestamps, and what they actually are. The basis of TCP is that it is a stateful, reliable means of sending and receiving IP packets. In order for reliable communications to take place, there must be bidirectional communication between the sending and receiving nodes so that, in basic terms, the sender can know that the target system received the communication correctly, and the receiving node has confidence that the message it received was correct. To such ends, TCP communications are session-based, and the two nodes employ features in the protocol as a framework to manage the reliability of communications. This involves things like resets, syn-acks, re-transmissions, and the like, that you’ve probably seen in any number of network captures. TCP was designed to communicate reliably over any transmission medium at any speed; it provides the same level of communications integrity over dial up as it does on a LAN.

It is important to understand that TCP was originally designed to overcome the challenges of unreliable communication channels. Not much thought was given to excessively reliable and fast communications.

It seems counter intuitive, but, because TCP is synchronous and keeps track of packets, it can break down over high bandwidth connections. It sounds crazy, I know, but let’s look at how this might happen.

Grab your pocket protector here, folks. We have to get a little nerdy.

If you asked President Trump about packet loss on TCP communications, he might respond, “It’s bad, very, very, very bad.” And he would be correct. But packet loss does occur for any number of reasons, and TCP maintains reliability by using selective acknowledgments to tell the sending node what TCP segments are queued on the receiving node and what segments it is still waiting for. These segments are, like anything else in network communications, numbered in finite sequence numbers. This value occupies a 32 bit space and exists within the confines of a Maximum Segment Lifetime (MSL), which is enforced at the IP level by something we’re more familiar with, the Time to Live (TTL). This MSL is usually adjusted based on the transfer rate so that faster speeds have smaller MSLs. This works pretty well until we introduce things like fiber optics. The bandwidth on a fiber connection can be so high that a TCP session can exhaust all of its sequence numbers and still have segments queued up in the same connection, leading to sequence number reuse, aka TCP Wrapping. This causes problems.

In short, as things get faster, it becomes more error prone to use timeout intervals to manage reliability.

The number of sequence numbers can not exceed the 32 bit value of 4,294,967,295 so as transmission speed increases, the MSL values must get shorter to compensate. With enough bandwidth, they can shrink to the point that they are no longer able to provide message integrity. If only there was a way to identify whether packets were dropped based on actual timing rather than a sequence number, but how?

Behold the mighty TCP Timestamp!

TCP Timestamps are an important component of reliable high speed communications because they keep TCP from stumbling over its own sequence numbers!Officially, this benefit is referred to adoringly as “PAWS” or Protection Against Wrapped Sequence Numbers. PAWS operates within the confines of a single TCP connection under the assumption that the TCP timestamp value increases predictably over time. If a segment is received with an older timestamp than one that was expected, it’s discarded. In doing so, PAWS protects against sequence numbers being reused in the same connection. It’s worth pointing out that there are a lot of weird exceptions and math around how that actually takes place, but for purposes of a blog post, we’ll steer clear of that rabbit hole. It should be clear at this point that TCP Timestamps serve a purpose in network communications, and that disabling them as a standard practice is a perilous endeavor.

Still awake? Good! Now we can talk about security!

Strictly speaking, TCP Timestamps are no more a security risk than the TCP protocol itself. Why then are they subject to all the bad press and mob calls for their disablement? The security concerns arise with the underlying mechanisms that are used to populate the values within the timestamp option itself. As the name suggests, the timestamp makes use of a virtual “timestamp clock” in the sender’s operating system. This clock must approximate real time measurements in order to remain compatible with other RTT measurements. There is no requirement for the timestamp clock to match the system clock, but it often maps to it for ease of design. After all, why make a new clock if you can just use the existing clock to derive values to be presented as those belonging to the new clock?

This leads to the one thing for which we hackers profess a deep and undying love for, unintended and predictable behavior. Am I right?

By measuring multiple timestamp replies, we can determine what the clock frequency is of the target system. The clock frequency is how many “ticks” the timestamp clock increments per unit of real time. For example, if we measure 5 timestamp replies each 1 second apart, and each timestamp value increases by 100 with each reply, we can infer that the clock increments 100 ticks for every second of real time processed by the system clock.Since most (not all!!) clocks start at 0, we can compute the approximate uptime of the system. Using the above example, if the timestamp value is 60000, we know that each 100 ticks of that value equate to one second of real time. We can assume that 600 seconds have elapsed since the clock was started. In laymen’s terms, the system was rebooted 10 minutes ago. We’re using small whole numbers here for purposes of illustration, but you get the idea.

In the real world, accurately fingerprinting the system will help with establishing timestamp validity, since clock specifications are documented.

System uptime by itself is an arbitrary value and doesn’t give away much on it’s own. But consider that patch cycles almost always include mandatory reboots. By surveying these values over time, one might be able to determine patching intervals by correlating reboot times across systems. What if you surveyed the same IP address multiple times and received different but consistently disparate values in the timestamp responses? That might allow you to identify systems that are behind a NAT or a load balancer, and may even allow you to draw conclusions about the load balancing configuration itself. Suppose you were testing a customer for susceptibility to DOS attacks. You may be able to use timestamps to determine with certainty whether the target system was knocked over, or whether you were just shunned by the IPS.

TCP Timestamps grant the hacker insight into a given system’s operational state, and how we use that information is limited only by our imagination.

But to dismiss their presence as a low severity security finding just to be remediated is inappropriate, and it may do more harm than good. When to use TCP timestamps should be determined by operational requirements, not by blanket assumptions of their importance. Are you listening, vulnerability scanners?So next time you find yourself knee deep in informational findings from a vulnerability scan, put your ear close to a network cable. It’s possible you may hear the faint battle cry of a forgotten hero. Want to keep reading? Learn the difference between vulnerability scans and penetration tests, more about Vulnerability Management, and how a penetration test can help you understand which risks are most relevant to your network.

June 4, 2018