Server Side Request forgery


Server side request forgery uses the vulnerable web server to interact with its internal servers  based on the attacker’s request
Generally the access to the internal nodes on the server i.e.: intranet is not publicly available any direct communication attempt would be objected by the fire wall , but the server would have unrestricted access to the intranet as it is the one which has to save the parameter in another server typically a database server, application server etc
So, In order to interact with the servers in the intranet of the server we design payloads to establish communication in our normal http requests, so the server would be executing the payloads on our behalfs so the packets would be accessed by the intranet server
A typical scenario is the port scanning of various servers present in the intranet
For example if a parameter contains a database field in the request such as username or password we inject the portscanning mechanism into the normal http request , as a result the server on receiving the request would start scanning
This scenario is possible when the user input is not carefully sanitized at the server end
Depending on the mechanism of the payload and the implementation of ports three types of responses are expected through port scanning :
1.       Open (Error based messages)
2.       Closed
3.       Open (Blind )
So, the above approach is different from traditional portscanning in the way :
·         The communication is through server, there is no direct communication to the user to the port scanning machine
·         The request sent to the server is HTTP methods instead of TCP packets in traditional port scanning

To perform this port scanning functionality we have a predetermined module called SKANDA which comes as a bundle with the IRONWASP scanner tool
The steps to be performed to scan the ports using SKANDA are as follows:
Ø  Connect IRONWASP as proxy to the browser through which communication is taking place
Ø  Navigate to the web page in browser and send the request to the server as done normally
Ø  Go to the proxy logs on IRON wasp tool which are present in ‘Logs’ section of the menu
Ø  Right click the request which is used for port scanning the application and click on “Run Module on the request”->Exploitation ->Skanda
Ø  In The GUI window click on ‘Next Step’ ,select the parameter to be used and click ‘Next Step’ until finish button is visible
Ø  In the CLI window enter the option 1 for port scan and 2 for network discovery and press ‘ÉNter’
Ø  Click on 1 for predefined list of ports and 2 for all the ports
Ø  Click ‘Done’
Ø  SKanda will process all the ports and display which ports are closed or open

In addition to SKANDA for IRONWASP, Acunetix web vulnerability scanner version 9 with Acumonitor also has the functionality to check and verify the SSRF vulnerability in an application


Comments

Post a Comment

Popular posts from this blog

Exploliting SQL injection flaws using SQLMap

A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands SQLMap SQLMap is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers. It comes with a powerful detection engine, many niche features for the ultimate penetration tester and a broad range of switches lasting from database fingerprinting, over data fetching...
Read more

Importance of enabling Secure and HTTPOnly flag for cookies

Image
Often automated scan results give lot of false positives, some may be legitimate and some are as per design which can be omitted. Most automated scanners give medium level vulnerabilities when the session identifier cookie does not have HTTPOnly and Secure flag enabled. What exactly is the problem? What happens if these flags are disabled for a session identifier? Let me explain as follows: HTTPOnly: The Httponly flag is an additional property that is added to cookies which helps to mitigate accessing cookie information through XSS. Which means declaring a cookie to httponly will restrict the client side script from accessing the cookie and return an empty string Exploitation: Consider a web application which doesn't have HTTPOnly flag enabled, auth_token is the session identifier of the application,upon executing the <script>alert(document.cookie)</script> in the application the output would be  Now let us enable the HTTPOnly flag on the s...
Read more

My encounter with successful social engineering attack

11/8/2018 9:41 AM - I was getting ready to Office when I received a call from one of our relatives, He was telling me about a hacking attempt on his email address due to which he was unable to receive any mail from yesterday, and an email is sent to all his contacts that he is in a life threatening situation in another country and he need money immediately. As a precaution he has changed his password but the issue didn't resolve. He was worried that his company's email and sensitive information is lost. He inquired if I can help him out since I was working in IT, I felt this was a opportunity for me to see hacking attempt first hand, I wanted to spend some time investigating in it, so I've asked him to share his mail details(Which is highly not recommended but at the situation I couldn't help it) and told him I'm heading to office and will have information by evening. This excitement to see what happened got the better off me, so I stayed back at home logging in...
Read more