This is default featured slide 1 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 2 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 3 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 4 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 5 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

Clickjacking| Clickjacking Attacks

By  September 09, 2022  No comments

 

What is Clickjacking?

Clickjacking is an attack that tricks a user into clicking a webpage element which is invisible or disguised as another element. This can cause users to unwittingly download malware, visit malicious web pages, provide credentials or sensitive information, transfer money, or purchase products online.

Typically, clickjacking is performed by displaying an invisible page or HTML element, inside an iframe, on top of the page the user sees. The user believes they are clicking the visible page but in fact they are clicking an invisible element in the additional page transposed on top of it.

The invisible page could be a malicious page, or a legitimate page the user did not intend to visit – for example, a page on the user’s banking site that authorizes the transfer of money.

TYPE Of Clickjacking Vulnerability:-

Likejacking –

a technique in which the Facebook “Like” button is manipulated, causing users to “like” a page they actually did not intend to like.


Cursorjacking –

a UI redressing technique that changes the cursor for the position the user perceives to another position. Cursorjacking relies on vulnerabilities in Flash and the Firefox browser, which have now been fixed.

Prepopulate forms trick

Sometimes is possible to fill the value of fields of a form using GET parameters when loading a page. An attacker may abuse this behaviours to fill a form with arbitrary data and send the clickjacking payload so the user press the button Submit.

Populate form with Drag&Drop

If you need the user to fill a form but you don’t want to directly ask him to write some specific information (like your email or and specific password that you know), you can just ask him to Drag&Drop something that will write your controlled data like in this example.

Examples Of Clickjacking Attacks:-

Basic Payload

Multistep Payload

Drag&Drop + Click payload

XSS + Clickjacking Vulnerability

If you have identified a XSS attack that requires a user to click on some element to trigger the XSS and the page is vulnerable to clickjacking, you could abuse it to trick the user into clicking the button/link.

Example:
You found a self XSS in some private details of the account (details that only you can set and read). The page with the form to set this details is vulnerable to Clickjacking and you can prepopulate the form with GET parameters.
An attacker could prepared a Clickjacking attack to that page prepopulating the form with the XSS payload and tricking the user into Submit the form. So, when the form is submited and the values are modified, the user will execute the XSS.

How to avoid Clickjacking Attacks?

Client side defences

It’s possible to execute scripts on the client side that perform some or all of the following behaviours to prevent Clickjacking:

  • check and enforce that the current application window is the main or top window,
  • make all frames visible,
  • prevent clicking on invisible frames,
  • intercept and flag potential clickjacking attacks to the user.

Bypass

As frame busters are JavaScript then the browser’s security settings may prevent their operation or indeed the browser might not even support JavaScript. An effective attacker workaround against frame busters is to use the HTML5 iframe sandbox attribute. When this is set with the allow-forms or allow-scripts values and the allow-top-navigation value is omitted then the frame buster script can be neutralized as the iframe cannot check whether or not it is the top window:

Both the allow-forms and allow-scripts values permit the specified actions within the iframe but top-level navigation is disabled. This inhibits frame busting behaviours while allowing functionality within the targeted site.


Depending on the type of Clickjaking attack performed you may also need to allow: allow-same-origin and allow-modals or even more. When preparing the attack just check the console of the browser, it may tell you which other behaviours you need to allow.

X-Frame-Options

The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame> or </frame> . Sites can use this to avoid Clickjacking attacks, by ensuring that their content is not embedded into other sites. Set the X-Frame-Options header for all responses containing HTML content. The possible values are:</p>

  • X-Frame-Options: deny which prevents any domain from framing the content (Recommended value)
  • X-Frame-Options: sameorigin which only allows the current site to frame the content.
  • X-Frame-Options: allow-from https://trusted.com which permits the specified ‘uri’ to frame this page.
  • Check limitations below because this will fail open if the browser does not support it.
  • Other browsers support the new CSP frame-ancestors directive instead. A few support both.

Content Security Policy (CSP) frame-ancestors directive

The recommended clickjacking protection is to incorporate the frame-ancestors directive in the application’s Content Security Policy.


The frame-ancestors ‘none’ directive is similar in behaviour to the X-Frame-Options deny directive (No-one can frame the page).


The frame-ancestors ‘self’ directive is broadly equivalent to the X-Frame-Options sameorigin directive (only current site can frame it).


The frame-ancestors trusted.com directive is broadly equivalent to the X-Frame-Options allow-fromdirective (only trusted site can frame it).

The following CSP whitelists frames to the same domain only:


Content-Security-Policy: frame-ancestors ‘self’;


See the following documentation for further details and more complex examples:

Limitations

  • Browser support: CSP frame-ancestors is not supported by all the major browsers yet.
  • X-Frame-Options takes priority: Section “Relation to X-Frame-Options” of the CSP Spec says: “If a resource is delivered with an policy that includes a directive named frame-ancestors and whose disposition is “enforce”, then the X-Frame-Options header MUST be ignored”, but Chrome 40 & Firefox 35 ignore the frame-ancestors directive and follow the X-Frame-Options header instead.
Read More

Best Hacking Android Phones for Hacker (2022)

By  September 09, 2022  No comments

 

What things do hackers need in mobiles?

  • Ram:- 4 to 8 GB
  • Rom:- 64 GB to Unlimited
  • Battery:- 3050mAh to 6000mAh
  • Kernel:- Hacking Framework Supported Kernels
  • Os:- Android Or Linux
  • SoC:- Media Tek G35 or Up And SD 635 or Up

Linux Phones Made For Hackers:-

  • Pro 1X
  • pro1x
    Pro 1X

An interesting smartphone that supports Ubuntu Touch, Lineage OS, and Android as well.

It is not just a Linux smartphone but a mobile phone with a separate QWERTY keypad, which is rare to find these days.

The Pro 1 X features a decent specification, including a Snapdragon 662 processor coupled with 6 GB of RAM. You also get a respectable AMOLED Full HD display with the Pro 1 X.

  • WiPhone
  • WiPhone, A Phone for Hackers and Makers project video thumbnail
    WiPhone

WiPhone is a unique, minimal phone.

It’s designed to enable hackers by making it easy to extend and modify the electronics and software. Something typical phones are not good for.

WiPhone is also a VoIP mobile phone. It uses WIFI to make HD voice calls, for free. This means that there is no required service contract – and it’s yours for life.

List of Best Hacking Android Phones for Hackers

Under 10k:-

  • POCO C31 (Royal Blue, 64 GB)
    Poco C31

POCO C31

  • Ram:- 4Gb
    ROM:- 64Gb Upto 512 GB
  • Display:- 16.59 cm (6.53 inch) HD+ Display
  • Battery:- 5000 mAh Lithium-ion Polymer Battery
  • SoC:- MediaTek Helio G35 Processor
  • Infinix Hot 10 Play (7° Purple, 32 GB)
    Infinix Hot 11 Play

Infinix Hot 11 Play

  • Ram:- 4Gb
  • Rom:- 128GB
  • Display:-6.82-inch (1640×720)
  • Battery:- 6000mAh
  • SoC:- MediaTek Helio G35
  • realme C21 (Cross Blue, 64 GB)
    Realme c21

Realme C21

  • Ram:- 4 GB
  • Rom:- 64 GB Upto 256Gb
  • Display:- 16.51 cm (6.5 inch) HD+ Display
  • Battery:- 5000 mAh
  • SoC:- MediaTek Helio G35 Processor
  • Micromax IN Note 1 (Green, 64 GB)
    Micromax In Note 1

Micromax IN Note 1

  • Ram:- 4 GB
  • Rom:- 64 GB Upto 256Gb
  • Display:- 16.94 cm (6.67 inch) Full HD
  • Battery:- 5000 mAh Li-Polymer
  • SoC:- MediaTek Helio G85

Under 20k:-

  • Realme narzo 30

realme narzo 30

  • Ram:6gb
  • Rom:128 upto 256Gb
  • Display:16.51 cm 6.5 inch Full HD
  • Battery:5000 mAh
  • SoC:MediaTek Helio G95 Processor
  • SAMSUNG Galaxy M32 (Black, 128 GB)
    Samsung Galaxy M32

Samsung Galaxy M32

  • Ram:6Gb
  • Rom:128Gb upto 1TB
  • Display:16.26 cm (6.4 inch) Full HD
  • Battery:6000 mAh
  • SoC:MediaTek Helio G80 Processor
  • MotoRola Moto G60

MotoRola Moto G60

  • Ram:6Gb
  • Rom:128Gb
  • Display:17.22 cm (6.78 inch) Full HD + 120hz Refresh Rate
  • Battery:6000 mAh
  • SoC:Qualcomm Snapdragon 732G Processor

Best With Support Kali Nethunter Without Custom Recovery (Kernel)

The Kali NetHunter project is the first Open-source Android penetration testing platform for Android devices, allowing for access to the Kali toolset from various supported Android devices. There are multiple unique features not possible on other hardware platforms.

The Kali NetHunter interface allows you to easily work with complex configuration files through a local web interface. This feature, together with a custom kernel that supports 802.11 wireless injection and preconfigured connect back VPN services, make the Kali NetHunter a formidable network security tool or discrete drop box – with Kali Linux at the tip of your fingers wherever you are!

  • One Plus One

OnePlus One

  • Ram:3Gb
  • Rom:64Gb
  • Display: Multi-touch IPS 5.5″ (13.97 cm) Corning Gorilla Glass 3 (full HD 1080 x 1920 pixels @ 401 PPI) touch-screen by JDI with LTPS technology
  • Battery:3,100 mAh Li-Po battery
  • SoC: 2.5GHz Qualcomm Snapdragon 801 quad core processor
  • Nokia 6.1

Nokia 6.1

  • Ram: 4Gb
  • Rom: 64Gb
  • Display:14.73 c.m. (5.8-inch) FHD
  • Battery:3060mAH lithium-ion battery
  • SoC: 1.8GHz Qualcomm Snapdragon 636 octa core processor
  • Installing NetHunter On the TicWatch Pro | Kali Linux Documentation
    TicWatch Pro

TicWatch Pro

  • Ram: 1Gb
  • Rom: 4Gb
  • Display: 1.39″ AMOLED (400 x 400 px) + FSTN LCD
  • Battery: 415mAh
  • SoC: Qualcomm® Snapdragon Wear™ 2100 (MSM8909W)

More Supported List

1.One Plus Devices

One Plus 2
One Plus 3
One Plus 6
One Plus 7
One Plus Nord (11)

2. Xiaomi

Davinci Miui (10)
Xiaomi Mi A3

3. Nexus

Nexus 5 And 5x
Nexus 6 and 6x
Nexus 7 and 7x
Nexus 9
Nexus 10

Others:-

Samsung Galaxy Tab S4
Nokia 3.1
Sony XPeria Z1

Which is the Best Hacking Android Phone?

One Plus Nord 11

Equipped with impressive features and decent specifications, the Oneplus 11 is a perfect choice that is available at a starting price of Rs 43,548.

This stylish handset from OnePlus comes with a 6.55 inches (16.63 cm) display that has a resolution of 1080 x 2400 Pixels offering immersive and comfortable viewing..

You can enjoy speed and lots of storage space as the phone comes with 8 GB of RAM and 128 GB of internal storage.

the phone is powered with Octa-core (1×3.2 GHz Kryo 585 & 3×2.42 GHz Kryo 585 & 4×1.80 GHz Kryo 585) Qualcomm SM8250-AC Snapdragon 870 5G (7 nm) processor.

Various connectivity options on the Oneplus 11 include WiFi – Yes, Wi-Fi 802.11, a/ac/b/g/n, Mobile Hotspot, Bluetooth – Yes, v5.2, and 5G supported by device (network not rolled-out in India), 4G (supports Indian bands), 3G, 2G.

AND also It support The Kali Nethunter framework. So It is Best Phone for Hacking.

Read More

Cross-Site Script Incusion(XSSI)

By  September 09, 2022  No comments

 

Cross-Site Script Incusion (XSSI)

XSSI designates a kind of vulnerability which exploits the fact that, when a resource is included using the script tag, the SOP doesn’t apply, because scripts have to be able to be included cross-domain. An attacker can thus read everything that was included using the script tag.


This is especially interesting when it comes to dynamic JavaScript or JSONP when so-called ambient-authority information like cookies are used for authentication. The cookies are included when requesting a resource from a different host.

Types Of XSSI

  • Static JavaScript (regular XSSI)
  • Static JavaScript, which is only accessible when authenticated
  • Dynamic JavaScript
  • Non-JavaScript

1. Regular XSSI

The private information is located inside a global accessible JS file, you can just detect this by reading files, searching keywords or using regexps.


To exploit this, just include the script with private information inside the malicious content:

2. Dynamic-JavaScript-based-XSSI and 3. Authenticated-JavaScript-XSSI

Confidential information is added to the script when a user requests it. This can be easily discovered by sending the request with and without the cookies, if different information is retrieved, then confidential information could be contained. To do this automatically you can use burp extension: https://github.com/luh2/DetectDynamicJS.


If the information resides inside a global variable, you you can exploit it using the same code as for the the previous case.


If the confidential data is sent inside a JSONP response, you can override the executed function to retrieve the information:

Or you could also set a prepared function to be executed by the JSONP response:

If a variable does not reside inside the global namespace, sometimes this can be exploited anyway using prototype tampering. Prototype tampering abuses the design of JavaScript, namely that when interpreting code, JavaScript traverses the prototype chain to find the called property. The following example is extracted from the paper The Unexpected Dangers of Dynamic JavaScript and demonstrates how overriding a relevant function of type Array and access to this, a non-global variable can be leaked as well.

In the original code slice from type Array accesses the data we’re interested in. An attacker can, as described in the preceding clause, override slice and steal the secrets.

Security Researcher Sebastian Lekies just recently updated his list of vectors.

4. Non-Script-XSSI

Takeshi Terada describes another kind of XSSI in his paper Identifier based XSSI attacks. He was able to leak Non-Script files cross-origin by including, among others, CSV files as source in the script tag, using the data as variable and function names.


The first publicly documented XSSI attack was in 2006. Jeremiah Grossman’s blog entry Advanced Web Attack Techniques using GMail depicts a XSSI, which by overriding the Array constructor was able to read the complete address book of a google account.


In 2007 Joe Walker published JSON is not as safe as people think it is. He uses the same idea to steal JSON that is inside an Array.


Other related attacks were conducted by injecting UTF-7 encoded content into the JSON to escape the JSON format. It is described by Gareth Heyes, author of Hackvertor, in the blog entry JSON Hijacking released in 2011. In a quick test, this was still possible in Microsoft Internet Explorer and Edge, but not in Mozilla Firefox or Google Chrome.

JSON with UTF-7:

Including the JSON in the attacker’s page

PROTECTION FROM XSSI

Developers should never place sensitive content inside JavaScript files and also not in JSONP. This already thwarts a large number of attacks from category 1 to 3. Category 4 vulnerabilities are usually fixed through browserside measurements. Nevertheless, user entries which are saved to JSON files and read from them should be sanitized.

The majority of bugs described in Takeshi Terada’s paper have been fixed. However, there is always the possibility that similar bugs are found again. These can be blocked at least partially by instructing the browser to not guess the content-type. Some browsers accept the not-yet-standard response header X-Content-Type-Options: nosniff to do so. A correct Content-Type is also helpful in reducing the chance of XSSI.

Read More

SSTI (Server Side Template Injection) Vulnerability | Detect | Idenfify | Exploit

By  September 09, 2022  No comments

 

What is server-side template injection(SSTI Vulnerability)?

A server-side template injection occurs when an attacker is able to use native template syntax to inject a malicious payload into a template, which is then executed server-side.


Template engines are designed to generate web pages by combining fixed templates with volatile data. Server-side template injection attacks can occur when user input is concatenated directly into a template, rather than passed in as data. This allows attackers to inject arbitrary template directives in order to manipulate the template engine, often enabling them to take complete control of the server.

An example of vulnerable code see the following one:

$output = $twig->render("Dear " . $_GET['name']);

In the previous example part of the template itself is being dynamically generated using the GET parameter name. As template syntax is evaluated server-side, this potentially allows an attacker to place a server-side template injection payload inside the name parameter as follows:

http://example.com/?name={{bad-stuff-here}}

Constructing a server-side template injection attack

Server-Side Template Injection | PortSwigger Research
Constructing a server-side template injection attack

How To Detect SSTI Vulnerability

As with any vulnerability, the first step towards exploitation is being able to find it. Perhaps the simplest initial approach is to try fuzzing the template by injecting a sequence of special characters commonly used in template expressions, such as the polyglot ${{<%[%'”}}%.
In order to check if the server is vulnerable you should spot the differences between the response with regular data on the parameter and the given payload.


If an error is thrown it will be quiet easy to figure out that the server is vulnerable and even which engine is running. But you could also find a vulnerable server if you were expecting it to reflect the given payload and it is not being reflected or if there are some missing chars in the response.

Detect – Plaintext context

The given input is being rendered and reflected into the response. This is easily mistaken for a simple XSS vulnerability, but it’s easy to differentiate if you try to set mathematical operations within a template expression:

Detect – Code context

In these cases the user input is being placed within a template expression:

The URL access that page could be similar to: http://vulnerable-website.com/?greeting=data.username

If you change the greeting parameter for a different value the response won’t contain the username, but if you access something like: http://example.com/?greeting=data.username}}hello then, the response will contain the username (if the closing template expression chars were }}).


If an error is thrown during these test, it will be easier to find that the server is vulnerable.

Identify SSTI Vulnerability

Once you have detected the template injection potential, the next step is to identify the template engine.
Although there are a huge number of templating languages, many of them use very similar syntax that is specifically chosen not to clash with HTML characters.

If you are lucky the server will be printing the errors and you will be able to find the engine used inside the errors. Some possible payloads that may cause errors:

${}{{}}<%= %>
${7/0}{{7/0}}<%= 7/0 %>
${foobar}{{foobar}}<%= foobar %>
${7*7}{{7*7}}“

Otherwise, you’ll need to manually test different language-specific payloads and study how they are interpreted by the template engine. A common way of doing this is to inject arbitrary mathematical operations using syntax from different template engines. You can then observe whether they are successfully evaluated. To help with this process, you can use a decision tree similar to the following:

Exploition of SSTI Vulnerability

Read

The first step after finding template injection and identifying the template engine is to read the documentation. Key areas of interest are:

  • ‘For Template Authors’ sections covering basic syntax.
  • ‘Security Considerations’ – chances are whoever developed the app you’re testing didn’t read this, and it may contain some useful hints.
  • Lists of builtin methods, functions, filters, and variables.
  • Lists of extensions/plugins – some may be enabled by default.
test different language-specific payloads

Explore

Assuming no exploits have presented themselves, the next step is to explore the environment to find out exactly what you have access to. You can expect to find both default objects provided by the template engine, and application-specific objects passed in to the template by the developer. Many template systems expose a ‘self’ or namespace object containing everything in scope, and an idiomatic way to list an object’s attributes and methods.


If there’s no builtin self object you’re going to have to bruteforce variable names using SecLists and Burp Intruder’s wordlist collection.


Developer-supplied objects are particularly likely to contain sensitive information, and may vary between different templates within an application, so this process should ideally be applied to every distinct template individually.

Attack

At this point you should have a firm idea of the attack surface available to you and be able to proceed with traditional security audit techniques, reviewing each function for exploitable vulnerabilities. It’s important to approach this in the context of the wider application – some functions can be used to exploit application-specific features. The examples to follow will use template injection to trigger arbitrary object creation, arbitrary file read/write, remote file include, information disclosure and privilege escalation vulnerabilities.

Read More
By  September 09, 2022  No comments

 

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.

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:

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.

By  September 09, 2022  No comments

 

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

By  September 09, 2022  No comments

 

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