week 4

week 4

  • sqli
  • path traversal + local file disclosure (havent covered inclusion yet)
  • command injection
  • demos

SELECT * FROM payportal WHERE id = "' . $id . '" AND period LIKE "x" OR true UNION SELECT

midsem notes

  • If you are spending more than 10 minutes on a question skip it and come back
  • Is your environment completely set up?
  • Do you know the difference between your hashes/encryption/encoding?
    • To quickly identify what hash/character set it uses I would recommend the following tool:
    • Do you see == / = / %3d%3d / %3d at the end of the string? It is most likely base64. Best tools for this:
    • Do you see something that starts with an ey / eY ? This is most likely a JWT or a flask token. I'll break down the difference between a JWT or flask token and what tools you can use for them:
      • JWT:
        • Best tool for JWT token would have to be: https://jwt.io/
        • If you paste a payload you suspect to be a JWT token into jwt.io:
          • In the Header, you should be able to see "typ":"JWT" and the alg it uses to create a signature. Common algorithms that are used for encryptionin JWT would be HS256 or RS256. Flask sessions tend to not have this.
        • If you have the key needed to encrypt a JWT you can also use https://jwt.io/ to modify the payload within the JWT then encrypt it to get a new JWT.
      • Flask:
    • What is %blah (e.g. %22)?
      • If you see % followed by two characters or integers or a combination of both it is URL encoding. Treat like ASCII with a percent before it.
      • To decode URL encoded characters use this website: https://www.urldecoder.org/
      • Things that are double encoded will contain a %25 before the two characters or integers or a combination of both

  • Topics and cheats to hack the vulnerability:

    • Recon:

      • Always check for: /robots.txt, /sitemap.xml

        • **Always always always check the source of the page to see anything hidden 

              **
          • Authentication:
            • This will probably show up in the exam. Some common authentication vulnerabilities include default passwords, weak passwords, SQL injection, weak session management, username enumeration, credentials located in javascript or HTML source code. I'll break down how to effectively attack these vulnerabilties:
              • Default passwords:
                • Head over to the login page of the web app that you are attacking.
                • Is there anything indicating what framework (WordPress, Tomcat, Apache) is in use for this web app?
          • Check for any logos, open up the inspect tool, check the headers in Burp - Try these credential combo against the login page: https://github.com/danielmiessler/SecLists/blob/master/Passwords/Default-Credentials/default-passwords.csv - Weak passwords: - You are presented with an application that may or may not have a sign up/register function - You but in some usernames and potentially get back an error message like: "The password for is wrong" or "The username is already in use". - Figure out what happens when an incorrect login occurs and what remains unchanged in the an incorrect login (response's content lenght, a specific string within the response body, HTTP status code, etc...) - Use a python script to brute force the password. Code would potentially look like this: - ```

          **import requests import re import time

          wordlist = open("passwords.txt", "r", encoding="utf8").readlines() url_memes = "https://memes.quoccabank.com/login"

          headers_memes = { "Content-Type": "" }

          for pass in wordlist: pass = pass.strip('\n') body_memes = {'username':'', 'password':pass} r = requests.post(url_memes, headers = headers_memes, data = body_memes) if "Incorrect" not in r.text: print("Password is: " + pass) break sleep(0.5)**

          - Credentials are normally entered by the user and passed towards the web apps backend. The username and passwords are normally then passed towards the SQL database via SQL query. If the SQL query isn't written correctly it might result in an SQL injection allowing you write SQL code and bypass authentication by forcing a true condition.
          - You go on a login page. - Enter in an ' or " in both the username and password field and submit it. - If you noticed an SQL error returned in the page you got the injection. However, this always doesn't happen. - If an error isn't returned and you suspect that there is an SQL error you can test something like this: sleep(5) or ' or sleep(5);-- or " or sleep(5);-- . - If you notice a 5 second delay in the page you got a blind SQL injection - A basic SQL injection for authentication bypass may look like: " or 1=1-- - or ' or 1=1-- - - Once you confirm there is SQL injection within the page I would recommend this page and testing these paylaods to see if you can bypass the authentication in place: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/SQL%20Injection . - Weak session management: - If a session is incorrectly implemented it may result in authentication bypass. - Using the edit this cookie extension, view the cookies in the web app as an unauthenticated user. - See if you can decode the cookie (if it is decodable) and tamper with it. - If you see a flask token you need to find the key that signed the token. Once you find the key and then use this tool: https://noraj.github.io/flask-session-cookie-manager/. - If you see a JWT token you need to determine if the algorithm to sign the token is using HS or RS. If HS you can keep attacking it. I'll cover the 3 main methods below on how to how to attack HS JWT tokens: - Can you find the key to reencrypt the JWT token with a modified payload? If you can this tool is your best friend: https://jwt.io/ - Does the JWT token actually verify the signature . If not just modify the payload/body after you decoded at jwt.io. You can also modify the payload/body in jwt.io and submit :D - Always test the None algorithm for JWT. Read up about this attack here: https://blog.pentesteracademy.com/hacking-jwt-tokens-the-none-algorithm-67c14bb15771 . - If these don't work move on and try something else! It probably isn't related to a JWT flaw. - Username enumeration: - This is a vulnerability that aids in identifying valid users within the web application. - Try and figure out the error that is spat out by the web app when - Just write up a simple python script with a set password that will fail. - Grab a wordlists of common usernames and run the script. - The script would look something like this: ``` import requests import re import time

        wordlist = open("usernames.txt", "r", encoding="utf8").readlines() url_memes = "https://memes.quoccabank.com/login"

        headers_memes = { "Content-Type": "" } for users in wordlist: user = user.strip('\n') body_mames = {'usernames': user, 'password': 'badpasswordhere'} r = requests.post(url_memes, headers = headers_memes, data = body_memes) if 'Wrong password' in r.text: print("Valid username found: " + user) sleep(0.5)
        ```

      • Credentials located in javascript or HTML source code:

        • Bad devs may accidently leave API keys or credentials within the front end source code. That means that it is viewable for everybody and you can use these credentials to authenticate yourself.
        • Use the inspect tool to see if there are any credentials on the login page that may help with logging in.
        • Check the javascript files to see if there are any APIs or crednetials hidden within them that may aid in logging in.

    • Authorisation:

      • This will probably show up in the exam. Some common authorisation vulnerabilities include weak session management, APIs located in javascript or HTML source code, insecure direct object reference (IDOR), URL tampering (probably missed a few things but these are the major ones). Please do note that there are two types of authorisation attack: vertical (e.g. low priv -> high priv) & horiztonal (e.g. low priv -> low priv account). I'll break down how to effectively attack these vulnerabilties:
        • Weak session management:
          • This vulnerability checks to see if you can escalate privilegs by abusing poorly designed session management.
          • Navigate to the challenge and login with credentials you found or an account that you created
          • Using an extension like edit this cookie, view the cookie of the page you logged into.
          • Do you see any cookies relating to roles? If you do can you change it to something higher.
          • Do you see just a cookie relating to your user or ID? If you do can you change it to another user. Potientially you can even perform SQL injections on these cookie values to escalate your privileges.
        • APIs located in javascript or HTML source code:
          • Sometimes developers mess up and leave privileged API endpoints within the the Javascript or HTML source code.
          • Check the javascript files or HTML source code to see if there are any APIs or crednetials hidden within them that may aid in privelge esclation.
        • Insecure direct object reference (IDOR):
          • This vulnerability stems from when inadequate access control is implemented within the application that allows you to emunerate certain parameters to access what you normally can't (i.e. someone else's dashboard settings that isn't yours)
          • Go to a challenge and log yourself into the web application.
          • Do you notice any parameters within the GET or POST parameters that could look enumerable? This could be id (numbers), username, email, etc...
          • Tamper with these parameters and see if you can get access to things you aren't able to.
          • To escalate vertically, can you visit an admin profile and perform a function on their behalf.
          • Might be useful to have two accounts here to see if you can IDOR your other account.
        • URL tampering:
          • This vulnerability would be very useful for privilege escalation. This is a result of poor access control (forgot to restrict an API to just admin so anyone would be able to execute the endpoint which could be devasting) for certain API endpoints . But can be quite time consuming so be smart with your guesses around these area. A few things vulnerability class fall within this one including IDOR just talked about above.
          • Go to the challenge and log yourself into the web application.
          • Start exploring and view source code/JavaScript files to see if there are any interesting API endpoints you can see that maybe you can tamper with to perform privileged actions.
          • If you could perform IDOR, can you access an admin profile and see what they can perform and see if you can execute with a lower privileged account.
          • Run a gobuster for directories/files to see if you can see any in unsecured endpoints that you exploit or view and further exploit.
            • If you see 403 continue to bruteforce that directory because 403 only restricts you for that path. What happens if you find something further down that you can mess with?

      • **PAY ATTENTION TO EVERYTHING IN BURP IN THE URL OR THE REQUEST BODY

        ** - Input Injection Vulnerabilties: - This will probably show up in the midsem. Some common vulnerabilties input injection that may pop up in the exam will only be SQL injection. As this vulnerability class suggest it is all about input. I can't help here much without demo but I'll break down what you can inject and where. So every parameter you see logically attack it with the injection type you think should match. I'll break down how to effectively attack these vulnerabilties: - SQL injection: - This vulnerabilties relates to whatever is involved with the database. Database store information that can be used later or for server-side validation. When you explore a web app, look for things that relates to database columns such as: id (also known as primary keys), comments, email, passwords, names, etc.... Just logically think what could be within a database. - Use the following payloads and start testing the input fields/parameters to see if you can get SQL: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/SQL%20Injection - I'll break down the attack vector for SQL injection: - GO FIND WHERE THE INJECTION IS: - Either you will get an SQL error message once you stick ' or " everywhere that is injectable - Or you will get a delayed response by using the following payloads: ' or sleep(5)-- - or " or sleep(5)-- -. Note that sometimes you might need a ; after the ) and before the -- - Sometimes it might just be a 500 response. - Once you get the injection, FIND THE NUMBER OF COLUMNS: - Your payload should look something like: ' order by 5-- - . Whatever you get an error for is that number minus one. For example if I ran, ' order by 10-- - and it fails it will mean that there a 9 columns in that table. - Once you know how many columns, FIND WHERE THE INJECTION IS VISIBLE: - Your payload should look something like: ' union select NULL,NULL,NULL,NULL,NULL FROM <table_name>-- - If you know that it is numbers it can look something like: ' union select 1,2,3,4,5FROM -- - - If you know that it is char or string it can look something like: ' union select 'a','b','c','d','e'FROM <table_name>-- - . - Once you know where the injection is visible, TIME TO FIND THE TABLE NAMES : - Your payload should look something like: ' union select NULL,NULL,NULL,table_schema,table_name FROM information_schema.tables WHERE table_schema != 'mysql' AND table_schema != 'information_schema'-- - - Once you know the table names, TIME TO FIND THE COLUMN NAMES: - Your payload should look something like: ' union select NULL,NULL,table_schema, table_name, column_name FROM information_schema.columns WHERE table_schema != 'mysql' AND table_schema != 'information_schema'-- - - Once you know the column names, TIME TO EXTRACT THE DATA: - Your payload should look something like: ' union select column_name1, column_name2, column_name3, column_name4, column_name5 FROM -- - - **Server-Side Vulnerabilties:
        **

This will show up in the midsems but don't worry it will be some easy stuff. With these ones focus on parameters that are making calls for files or ways to download files or explore URLs.

  • Path Traversal/Directory Traversal/Local File Disclosure:

    • Path traversal is also known as directory traversal. These vulnerabilities enable an attacker to read arbitrary files on the server that is running an application. This might include: application code and data, credentials for back-end systems, sensitive operating system files.

    • Use the following payloads and start testing the input fields/parameters to see if you can get Path Traversal: https://github.com/swisskyrepo/PayloadsAllTheThing...

    • I'll break down the attack vector for basic path traversal (similar to SSRF):
      • Look for URLs thats that has parameters makes calls to grab a file of the server/OS. E.g hi.jpg, downloads/hi.pdf, etc... anything that looks like it doesn't run of a CDN.
      • Once you are able to locate an endpoint start trying to see if you can grab a world readable file such as /etc/passwd. The payload may look like ../../../../../../etc/passwd. If it does hit try and lower the amount of ../ used. The cheat aboe will include bypasses if you run into any issues.

Practice for exams:

Go checkout pentesterlabs or burp academy :D

Please study for the exam and try your best. Don't get discouraged at all and please feel free to reach out to me for anymore questions that you may have and I'm here to help!

z5626137