Penetration Testing with Kali Linux OffSec

Permissions 0644 for '/home/kali/dt_key' are too open.
It is required that your private key files are NOT accessible by others. 
This private key will be ignored. 
... 
kali@kali:~$ 
chmod 400 dt_key
kali@kali:~$ 
ssh -i dt_key -p 2222 [e-mail]
... 
offsec@68b68f3eb343:~$
Listing 137 - Using the Private Key to connect via SSH 
Before wrapping up this section, let’s briefly examine directory traversal attacks on Windows. On 
Linux, we usually use the /etc/passwd file to test directory traversal vulnerabilities. On Windows, 
we can use the file C:\Windows\System32\drivers\etc\hosts to test directory traversal 

---

Penetration Testing with Kali Linux
PWK - Copyright © 2023 OffSec Services Limited. All rights reserved. 
256 
vulnerabilities, which is readable by all local users. By displaying this file, we can confirm the 
vulnerability exists and understand how the web application displays the contents of files. After 
confirming the vulnerability, we can try to specify files containing sensitive information such as 
configuration files and logs. 
In general, it is more difficult to leverage a directory traversal vulnerability for system access on 
Windows than Linux. In Linux systems, a standard vector for directory traversal is to list the users 
of the system by displaying the contents of /etc/passwd, check for private keys in their home 
directory, and use them to access the system via SSH. This vector is not available on Windows 
and unfortunately, there is no direct equivalent. Additionally, sensitive files are often not easily 
found on Windows without being able to list the contents of directories. This means to identify 
files containing sensitive information, we need to closely examine the web application and collect 
information about the web server, framework, and programming language. 
Once we gather information about the running application or service, we can research paths 
leading to sensitive files. For example, if we learn that a target system is running the 
Internet 
Information Services
(IIS)
389
web server, we can research its log paths and web root structure. 
Reviewing the Microsoft documentation,
390
we learn that the logs are located at 
C:\inetpub\logs\LogFiles\W3SVC1\
. Another file we should always check when the target is 
running an IIS web server is C:\inetpub\wwwroot\web.config, which may contain sensitive 
information like passwords or usernames. 
In this section, we used the ../ sequence for directory traversal on Linux. As shown, Windows uses 
backslashes instead of forward slashes for file paths. Therefore, ..\ is an important alternative to 
../
on Windows targets. While RFC 1738
391
specifies to always use slashes in a URL, we may 
encounter web applications on Windows which are only vulnerable to directory traversal using 
backslashes. Therefore, we should always try to leverage both forward slashes and backslashes 
when examining a potential directory traversal vulnerability in a web application running on 
Windows. 
9.1.3
Encoding Special Characters 
Having honed our understanding of directory traversal concepts using the “Mountain Desserts” 
web application, let’s try applying these skills to a real vulnerability. In the “Vulnerability Scanning” 
topic, we scanned the SAMBA machine and identified a directory traversal vulnerability in Apache 
2.4.49.
392
This vulnerability can be exploited by using a relative path after specifying the cgi-bin 
directory in the URL. 
Let’s use curl and multiple ../ sequences to try exploiting this directory traversal vulnerability in 
Apache 2.4.49 on the 
WEB18
machine. 
kali@kali:/var/www/html$