niedziela, 6 października 2019

Testing DVNA

I was looking for example vulnerable webapps based on NodeJS and that's how I found Damn Vulnerable NodeJS Application. I decided to check it. Below you will find the details. Here we go...
We will start here:



According to the authors:



Let's leave the fixing-part for the developers ;) My goal here was to exploit found bugs as fast as possible.

I created fresh VM with Ubuntu 18.04.3:



Steps to prepare environment for the DVNA you can find (and read) in the friendly manual. I decided to use docker (goto: „Using Official Docker Image” section to continue). 



As you can see we have a header „X-Powered-By: Express”. It can be a good indicator of 'NodeJS-based webapp' [1,2]. 

Now we should be on the main web page where we can use login form, register new user or try to use some ‘forgot password’-functionality. After I tried few default login/password pairs I decided to create new user – called tester:  


Tester-user is created so we can proceed with challenges.


I started from A10 – Unvalidated Redirects and Forwards:

 


As you can see on the picture (red frames) above – few hints for us. If we can trick user somehow to click our link we can redirect his/her browser to some ‘evil place’ (for example phishing site).

According to the hint („The app redirects the user to any URL including external without validation.”) we can redirect user’s browser to the page we can control. 




Cool, (now right-click and) send to repeater (and with  netcat listener prepared on Kali VM):





...we can now Follow redirections to see request from NodeJS webapp to Kali VM listener.

Good. It was easy. ;>

Let’s move to the section „A9: Using Components with Known Vulnerability”:
 
In my opinion - the most interesting case. ;)
 
 


As you can see ‘using compontents with known vulnerabilities makes the application an easy target’. Let’s see what we can do with that hint[1, 2]:




Great, we have another hint: calculations ;] Let’s calculate: a to b to c ;> Like this:
 


Click Submit:



Ok, cool. ;] After a while (and another stacktrace
 


) I decided to search for some bugs (available online) related to mathjs (found in /node_modules/ path) . I found this:
 



Very nice page. After a while of few simple injections and error messages I used function cos in the parser:



Next step:


Let’s try it:


Looks good. ;] At this stage (and reading few more papers found via Google) I decided to try to run some code on remote box using mathjs:




I assume that listing the calatogs on remote box will be 'good enough' to go to the next section;)

Moving to A7: Missing Function Level Access Control:

 





As you can see there is a link to Admin API Dashboard but when we’ll go there we will see an error message:
 



:C



In the source we can see a link to /users and there to /usersapi. Let’s go there:
 





Of course in case of more registered users - you should see there more details in /usersapi link. (In my case there are only two users: tester and tester2.)


Next we’ll move directly to the section: A4: Insecure Direct Object Reference:




As you can see our challenge is to update user’s information – but for someone else not for our user ;] Let’s try to do it: request is grabbed using Burp:



As you remember from section A7: Missing Function Level Access Control we had an id parameter listed as well. Let’s change it/d (during interception) to id of other user – in my case id was changed to 1. Let the request continue and after a while you can go to /usersapi to check if there is any change for any other user. Checking:




 
Looks like we did it! ;]


Next stage - A3: Cross-site Scripting:
 





Some time ago I found somewhere online a nice payload to check for XSS – it is HTML-strike-tag ;]
I will use it for both cases.

Case 01 – reflected XSS – (bug in search query):
 




Submit your query to see new listing of the products:
  
So far, so good. Let’s move to case 02 – stored XSS:


Let’s add some new product:
 




Small modification:




...and we can see that all the fields are vulnerable to injection. ;[
 


Let’s move to the next step:


A1: Injection:

Just like before we have 2 cases here. I’ll start from SQL Injection because from the beginning I planned to use this command injection to something next but let’s not spoilt it for now. ;]

Currently – we are here:
 

 




Quick shortcut for sqli bug: answer for correct user:
 






And this one is for non-existent user:




Quick diff (with sqlmap):


Cool. Let’s skip to the next one section: Command Injection: Network Connectivity Test:




Looks pretty good ;] Checking:




That’s great information, isn’t it? ;]
Checking (read as: preparing msfvenom for x64 and we should be somewhere here):
 

 So?



Cool. As you can see we are on docker-vm:
 


Checking source code directory:



App is ready to download it onKali and read source at localhost ;]

For example: checking what is required by the application:

(See: components with known vulnerablity.) Few (default) passwords:



Checking server.js file:

No we can continue...


 
More from the source:
 


More details:

More from the source:

Looking for the details:


Next bug:

Looking for functions:

 ...and routes:

I really recommend reading documentation available here.

Also checking some tutorials (google/youtube) related to creating webapps in NodeJS will help you understand more details about possible bugs you can (and will) find in the code during pentest(s).

In case of any questions - feel free to leave a comment.


Nice links to check:
* nodejs docs
* mathjs security
* RCE in mathjs

See you next time.

Cheers

Brak komentarzy:

Prześlij komentarz