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