IIS - Internet Information Services
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Test executable file extensions:
asp
aspx
config
php
On any IIS server where you get a 302 you can try stripping the Host header and using HTTP/1.0 and inside the response the Location header could point you to the internal IP address:
Response disclosing the internal IP:
You can upload .config files and use them to execute code. One way to do it is appending the code at the end of the file inside an HTML comment: Download example here
More information and techniques to exploit this vulnerability here
Download the list that I have created:
It was created merging the contents of the following lists:
https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/IIS.fuzz.txt http://itdrafts.blogspot.com/2013/02/aspnetclient-folder-enumeration-and.html https://github.com/digination/dirbuster-ng/blob/master/wordlists/vulns/iis.txt https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/SVNDigger/cat/Language/aspx.txt https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/SVNDigger/cat/Language/asp.txt https://raw.githubusercontent.com/xmendez/wfuzz/master/wordlist/vulns/iis.txt
Use it without adding any extension, the files that need it have it already.
Check the full writeup in: https://blog.mindedsecurity.com/2018/10/from-path-traversal-to-source-code-in.html
As summary, there are several web.config files inside the folders of the application with references to "assemblyIdentity" files and "namespaces". With this information it's possible to know where are executables located and download them. From the downloaded Dlls it's also possible to find new namespaces where you should try to access and get the web.config file in order to find new namespaces and assemblyIdentity. Also, the files connectionstrings.config and global.asax may contain interesting information.\
In .Net MVC applications, the web.config file plays a crucial role by specifying each binary file the application relies on through "assemblyIdentity" XML tags.
An example of accessing the web.config file is shown below:
This request reveals various settings and dependencies, such as:
EntityFramework version
AppSettings for webpages, client validation, and JavaScript
System.web configurations for authentication and runtime
System.webServer modules settings
Runtime assembly bindings for numerous libraries like Microsoft.Owin, Newtonsoft.Json, and System.Web.Mvc
These settings indicate that certain files, such as /bin/WebGrease.dll, are located within the application's /bin folder.
Files found in the root directory, like /global.asax and /connectionstrings.config (which contains sensitive passwords), are essential for the application's configuration and operation.
MVC applications also define additional web.config files for specific namespaces to avoid repetitive declarations in each file, as demonstrated with a request to download another web.config:
The mention of a custom namespace hints at a DLL named "WebApplication1" present in the /bin directory. Following this, a request to download the WebApplication1.dll is shown:
This suggests the presence of other essential DLLs, like System.Web.Mvc.dll and System.Web.Optimization.dll, in the /bin directory.
In a scenario where a DLL imports a namespace called WebApplication1.Areas.Minded, an attacker might infer the existence of other web.config files in predictable paths, such as /area-name/Views/, containing specific configurations and references to other DLLs in the /bin folder. For example, a request to /Minded/Views/web.config can reveal configurations and namespaces that indicate the presence of another DLL, WebApplication1.AdditionalFeatures.dll.
From here
If you see an error like the following one:
It means that the server didn't receive the correct domain name inside the Host header. In order to access the web page you could take a look to the served SSL Certificate and maybe you can find the domain/subdomain name in there. If it isn't there you may need to brute force VHosts until you find the correct one.
You can try to enumerate folders and files inside every discovered folder (even if it's requiring Basic Authentication) using this technique. The main limitation of this technique if the server is vulnerable is that it can only find up to the first 6 letters of the name of each file/folder and the first 3 letters of the extension of the files.
You can use https://github.com/irsdl/IIS-ShortName-Scanner to test for this vulnerability:java -jar iis_shortname_scanner.jar 2 20 http://10.13.38.11/dev/dca66d38fd916317687e1390a420c3fc/db/
Original research: https://soroush.secproject.com/downloadable/microsoft_iis_tilde_character_vulnerability_feature.pdf
You can also use metasploit: use scanner/http/iis_shortname_scanner
A nice idea to find the final name of the discovered files is to ask LLMs for options like it's done in the script https://github.com/Invicti-Security/brainstorm/blob/main/fuzzer_shortname.py
Bypass a basic authentication (IIS 7.5) trying to access: /admin:$i30:$INDEX_ALLOCATION/admin.php or /admin::$INDEX_ALLOCATION/admin.php
You can try to mix this vulnerability and the last one to find new folders and bypass the authentication.
ASP.NET include a debugging mode and its file is called trace.axd.
It keeps a very detailed log of all requests made to an application over a period of time.
This information includes remote client IP's, session IDs, all request and response cookies, physical paths, source code information, and potentially even usernames and passwords.
https://www.rapid7.com/db/vulnerabilities/spider-asp-dot-net-trace-axd/
ASPXAUTH uses the following info:
validationKey (string): hex-encoded key to use for signature validation.
decryptionMethod (string): (default “AES”).
decryptionIV (string): hex-encoded initialization vector (defaults to a vector of zeros).
decryptionKey (string): hex-encoded key to use for decryption.
However, some people will use the default values of these parameters and will use as cookie the email of the user. Therefore, if you can find a web using the same platform that is using the ASPXAUTH cookie and you create a user with the email of the user you want to impersonate on the server under attack, you may be able to use the cookie from the second server in the first one and impersonate the user. This attacked worked in this writeup.
Full report here: A bug in the code didn't properly check for the password given by the user, so an attacker whose password hash hits a key that is already in the cache will be able to login as that user .
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
