Hacker Halted Miami , USA 2010
View more presentations from Aditya K Sood.
Wednesday, November 10, 2010
Monday, August 23, 2010
User Interface Security - Google Chrome HTTP AUTH Dialog Spoofing through Realm Manipulation
Google Chrome ( 5.0.375.127 and previous versions) suffers from HTTP Auth Dialog spoofing vulnerability due to possible realm manipulation in the HTTP header. Previously, Google chrome has got a similar bug which can be seen HERE
This bug was actually patched. The issue mentioned in this bug was dialog spoofing due to long sub domain names. The patch worked only for that specific case which was outlined in that bug. There are number of tests have been conducted on Google Chrome
which verifies the inefficiency of Google Chrome to scrutinize the type of realm value set in the header. It can be tampered with double quotes and single quotes used in a definite manner.
Another related scenario: HERE
Note: Different variants have shown that these issues are still open and not patched yet.
As mentioned in RFC 2617: "The realm directive (case-insensitive) is required for all authentication schemes that issue a challenge.The realm value (case-sensitive), in combination with the canonical root URL (the absolute URI for the server whose abs_path is empty;of the server being accessed, defines the protection space. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database.//The realm value is a string,generally assigned by the origin server, which may have additional semantics specific to the authentication scheme. Note that there may be multiple challenges with the same auth-scheme but different realm/s"
So, realm value plays critical role in determining the framework of HTTP Access authentication for a particular resource. It has been analyzed that it is possible to spoof the HTTP Auth dialog by playing around realm values. This attack scenario
can be used to launch phishing attacks and stealing sensitive information from the legitimate websites.
As it has been released before, Google Chrome fails to sanitize the obfuscated URL and redirect it to the different domain. This potential flaw can be combined with the HTTP Auth dialog spoofing to launch attacks against legitimate websites. Looking at this particular point of time, certain solutions can be presented as
1. A new model of HTTP authentication dialog which shows the clarity between realm value and domain.
2. Setting a limit on size of strings to be passed as Realm value. This should not be applied on the string size of domain name.
3. Application of appropriate parameters in scrutinizing the strings passed in double quotes and single quotes.
Further: Tim from Vsecurity notifies about similar work related to HTTP Authentication. A very good paper has been presented HERE which covers lot of issues of HTTP authentication
The video is embedded below
Monday, August 09, 2010
Debugged MZ/PE - Holistic Approach to Analysis of Defective Threads
Abstract: Threads are considered as second level structures used in the process execution. As per semantics, threads run as dynamic entities under processes. Whenever a new process is created in a system a number of threads are initialized. To understand the real cause of infection in processes, one has to traverse along the working procedure of a thread.
Online : http://debuggingexpert.dumpanalysis.org/Debugged_March_2010.htm
The hard cover will be release at Amazon : HERE
Sunday, July 11, 2010
HITB Magazine: MS Office Infection Paper
A new paper has been released in the HITB magazine about infection styles in MS Office files. It projects a pattern of infection used by chinese malware.
Fetch:http://magazine.hackinthebox.org/issues/HITB-Ezine-Issue-003.pdf
Wednesday, May 05, 2010
Credentials Verification- Security Emails Phishing and Trust Manipulation
Phishing attacks based on trust exploitation are on rise. Banks are facing tremendous complexities and security issues due to these type of attacks. The primary focus of this sort of attack is to trick user’s sense of understanding and
segregating the trust to perform operations of attacker's choice. The case studies discussed in this article sheds light on phishing attacks that exploit users' trust with the third-party. Credit card forgeries are quite common considering the bank phishing frauds. The primary artifact of the attackers is to play with the user trust and to manipulate user thinking process by raising a complexity through spams. The user inability to distinguish between the trusted website and attacker controlled website, which is a replica of the original website, results in forged transactions.
Recently HSBC, Paypal security phishing emails are used to steal the credentials of users. The phished email carry online form as an attachment which looks similar to the original HSBC bank forms for updating the credentials of the user.
Case 1 - Paypal Verification Credentials Theft
The email is sent by phisher on the behalf of Paypal verification group for re-verifying your credentials. The email looks like as
During analysis the attachment is downloaded in a restrictive environment to scrutinize against malware, infection handlers etc.
Luckily the form page does not contain malware but the form is posted to a attacker controlled domain (http://probe.201w.com/verification.php) for verification as:
On further analyzing the domain, we came across the fact that some of the users have fallen into this trap as:
The users inability to distinguish between the trust boundaries lead to compromises and information stealing.
Case 2: HSBC Verification Credentials Stealing
We performed simple analysis in controlled environment. The form looked like as
The form itself does not contain any sort of malware but the form is posted to the malicious domain (http://www.thebluzmen.com/verify.php) for verification as
A normal user should be aware of the artifacts used by the phishers to betray the trust.
segregating the trust to perform operations of attacker's choice. The case studies discussed in this article sheds light on phishing attacks that exploit users' trust with the third-party. Credit card forgeries are quite common considering the bank phishing frauds. The primary artifact of the attackers is to play with the user trust and to manipulate user thinking process by raising a complexity through spams. The user inability to distinguish between the trusted website and attacker controlled website, which is a replica of the original website, results in forged transactions.
Recently HSBC, Paypal security phishing emails are used to steal the credentials of users. The phished email carry online form as an attachment which looks similar to the original HSBC bank forms for updating the credentials of the user.
Case 1 - Paypal Verification Credentials Theft
The email is sent by phisher on the behalf of Paypal verification group for re-verifying your credentials. The email looks like as
During analysis the attachment is downloaded in a restrictive environment to scrutinize against malware, infection handlers etc.
Luckily the form page does not contain malware but the form is posted to a attacker controlled domain (http://probe.201w.com/verification.php) for verification as:
On further analyzing the domain, we came across the fact that some of the users have fallen into this trap as:
The users inability to distinguish between the trust boundaries lead to compromises and information stealing.
Case 2: HSBC Verification Credentials Stealing
We performed simple analysis in controlled environment. The form looked like as
The form itself does not contain any sort of malware but the form is posted to the malicious domain (http://www.thebluzmen.com/verify.php) for verification as
A normal user should be aware of the artifacts used by the phishers to betray the trust.
Papers Published - HITB EZine and Hakin9
We have just published new papers in Hack in the Box EZine and Hakin9. The magazines are free and can be fetched from below mentioned links:
1. Open Redirect Wreck Off - HITB EZine
The paper talks about the real time scenarios analyzed while conducting security assessments of different websites. It has been detected that these websites are prone to invalidated redirects and forward issues. Recently, with the release of OWASP 2010 RC1 release, A8 has been marked against the redirection based flaws in websites. The
attacker can control the user’s trust behavior to visit the website which is malicious and controlled by the untrusted party
http://www.hackinthebox.org/misc/HITB-Ezine-Issue-002.pdf
2. Pwning Embedded ADSL Routers - Inside LAN | Hakin9
The paper is restricted to not only testing but also discusses the kinds of software
and firmware used and incessant vulnerabilities that should be scrutinized while
setting up a local network. A detailed discussion will be undertaken about the HTTP servers used for handling authentication procedure and access to firmware image providing functionalities to design and configure your own home local area network.
http://download.hakin9.org/en/hakin9_04_2010_EN.pdf
1. Open Redirect Wreck Off - HITB EZine
The paper talks about the real time scenarios analyzed while conducting security assessments of different websites. It has been detected that these websites are prone to invalidated redirects and forward issues. Recently, with the release of OWASP 2010 RC1 release, A8 has been marked against the redirection based flaws in websites. The
attacker can control the user’s trust behavior to visit the website which is malicious and controlled by the untrusted party
http://www.hackinthebox.org/misc/HITB-Ezine-Issue-002.pdf
2. Pwning Embedded ADSL Routers - Inside LAN | Hakin9
The paper is restricted to not only testing but also discusses the kinds of software
and firmware used and incessant vulnerabilities that should be scrutinized while
setting up a local network. A detailed discussion will be undertaken about the HTTP servers used for handling authentication procedure and access to firmware image providing functionalities to design and configure your own home local area network.
http://download.hakin9.org/en/hakin9_04_2010_EN.pdf
Saturday, January 09, 2010
NoScript 1.9.9.35 - XSS Injection Checker Nested Complexity Bug still persists
Just a few days ago I talked about the complexity issue with the NoScript author and the false positives encountered. I released a document on the below mentioned link:
http://secniche.org/papers/noscript_xss_chk_comp_flaw.pdf
Read it for the issue in action. Soon after that there were some build versions and finally 1.9.9.35 is out. but seems like this complexity issue still persists. This time it worked with more stealthier JavaScript and Injection Checker raises the false positive.
The complex links are from ad.doubleclick.net and are presented below:
http://www.linkedin.com/html/addineyeV2.html?strBanner=gEbServerData%3D%271%3A%3A1225342%3A%3A2272675%3A%3ASite-20936/Type-11/2272675_e0b24616-1ae2-4643-baee-12ebdd7a1647.js%3A%3AExpBanner%3A%3A0%3A%3A%3A%3A%3A%3A0%3A%3A%3A%3A%3A%3A%3A%3A%3A%3A1%3A%3A94684%3A%3A0%3A%3A0%3A%3A%3A%3A%27%3BgEbBannerData%3D%2715264925553351627%3A%3A1%3A%3A300%3A%3A250%3A%3A%3A%3A%3A%3A1%3A%3A0%3A%3A30%3A%3A%3A%3A%3A%3A%3A%3A0%3A%3A0%3A%3Atrue%3A%3A%3A%3Afalse%27%3BgEbInteractions%3D%27%5B_eyeblaster%2Chttp%253A//ad.doubleclick.net/click%253Bh%253Dv8/391c/3/0/*/v%253B221038779%253B0-0%253B11%253B40521440%253B4307-300/250%253B34909454/34927284/1%253Bu%253D18348940%253B%257Eaopt%253D2/0/ff/0%253B%257Esscs%253D%253F%2C%5D%27%3BebSrc%3D%27http%253A//ds.serving-sys.com/BurstingCachedScripts/ebExpBanner_3_0_67.js%27%3BebResourcePath%3D%27http%253A//ds.serving-sys.com/BurstingRes//%27%3B%3BebO%3Dnew%20Object%28%29%3BebO.sms%3D%27ds.serving-sys.com/BurstingScript/%27%3BebO.bs%3D%27bs.serving-sys.com%27%3BebO.fvp%3D%27Res/%27%3BebO.rpv%3D%27_2_5_1%27%3BebO.pv%3D%27_3_0_3%27%3BebO.pi%3D0%3BebO.wv%3D%27_3_0_1%27%3BebPtcl%3D%27http%3 //%27%3BebO.bt%3D2%3BebO.bv%3D3%3BebO.plt%3D8%3BgEbDbgLvl%3D0%3BgnEbLowBWLimit
%3D120%3B]
Another sanitized one:
http://ad.doubleclick.net/adi/linkedin.dart/home_nn;optout=false;lang=en;v=1;u=18348940;ue=1utcdckqzgglwtt4uqu6ap;title=o;title=ic;func=null;co_id=233588;co_id=376101;co_id=3027;co_id=60837;ind=96;ind=82;ind=121;ind=118;csize=d;csize=a;csize=h;csize=c;csize_num=1;csize_num=50;csize_num=7000;zip=110005;gdr=u;cntry=sg;reg=0;grp=3120;grp=54384;grp=113049;grp=115855;grp=742197;grp=894157;grp=1485107;grp=1613377;grp=1777141;grp=1805569;grp=1848637;edu=13494-2008;jobs=1;sub=0;con=j;age=a;age_num=24;seg=190;seg=218;tile=2;sz=300x250;extra%3Dnull;ord=41888994?]. Sanitized URL: [http://www.linkedin.com/html/addineyeV2.html?strBanner=gEbServerData%20%201%3A%3A1225342%3A%3A2272675%3A%3ASite-20936%2FType-11%2F2272675_e0b24616-1ae2-4643-baee-12ebdd7a1647.js%3A%3AExpBanner%3A%3A0%3A%3A%3A%3A%3A%3A0%3A%3A%3A%3A%3A%3A%3A%3A%3A%3A1%3A%3A94684%3A%3A0%3A%3A0%3A%3A%3A%3A%20%3BgEbBannerData%20%2015264925553351627%3A%3A1%3A%3A300%3A%3A250%3A%3A%3A%3A%3A%3A1%3A%3A0%3A%3A30%3A%3A%3A%3A%3A%3A%3A%3A0%3A%3A0%3A%3Atrue%3A%3A%3A%3Afalse%20%3BgEbInteractions%20%20%20_eyeblaster%2Chttp%253A%2F%2Fad.doubleclick.net%2Fclick%253Bh%253Dv8%2F391c%2F3%2F0%2F*%2Fv%253B221038779
%253B0-0%253B11%253B40521440%253B4307-300%2F250%253B34909454%2F34927284%2F1%253Bu%25
3D18348940%253B%257Eaopt%253D2%2F0%2Fff%2F0%253B%257Esscs%253D%253F%2C%20%20%3BebSrc%20%20http%253A%2F%2Fds.serving-sys.com%2FBurstingCachedScripts%2FebExpBanner_3_0_67.js%20%3BebResourcePath%20%20http%253A%2F%2Fds.serving-sys.com%2FBurstingRes%2F%2F%20%3B%3BebO%20new%20Object%20%20%3BebO.sms%20%20ds.serving-sys.com%2FBurstingScript%2F%20%3BebO.bs%20%20bs.serving-sys.com%20%3BebO.fvp%20%20Res%2F%20%3BebO.rpv%20%20_2_5_1%20%3BebO.pv%20%20_3_0_3%20%3BebO.pi%200%3BebO.wv%20%20_3_0_1%20%3BebPtcl%20%20http%3A%2F%2F%20%3BebO.bt%202%3BebO.bv%203%3BebO.plt%208%3BgEbDbgLvl%200%3BgnEbLowBWLimit%20120%3B#
20340333708575276684].
On further discussion with NoScript author the complexity in this issue is more versatile due to the presence of JavaScript in a more stealthier manner. It looks like as
gEbServerData = "1::1225342::2272675::Site-20936/Type-11/2272675_e0b24616-1ae2-4643-baee-12ebdd7a1647.js::ExpBanner::0::::::0::::::::::1::94684::0::0::::";
gEbBannerData = "15264925553351627::1::300::250::::::1::0::30::::::::0::0::true::::false";
gEbInteractions = "[_eyeblaster,http%3A//ad.doubleclick.net/click%3Bh%3Dv8/391c/3/0/*/v%3B221038779%3B0-0%3B11%3B40521440%3B4307-300/250%3B34909454/34927284/1%3Bu%3D18348940%3B%7Eaopt%3D2/0/ff/0%3B%7Esscs%3D%3F,]";
ebSrc = "http%3A//ds.serving-sys.com/BurstingCachedScripts/ebExpBanner_3_0_67.js";
ebResourcePath = "http%3A//ds.serving-sys.com/BurstingRes//";
ebO = new Object;
ebO.sms = "ds.serving-sys.com/BurstingScript/";
ebO.bs = "bs.serving-sys.com";
ebO.fvp = "Res/";
ebO.rpv = "_2_5_1";
ebO.pv = "_3_0_3";
ebO.pi = 0;
ebO.wv = "_3_0_1";
ebPtcl = "http://";
ebO.bt = 2;
ebO.bv = 3;
ebO.plt = 8;
gEbDbgLvl = 0;
gnEbLowBWLimit = 120;
The author seems like not interested in this layout because the scripts can not be allowed in this complex part. This means False Positive persists in the NoScript XSS Injection Checker. You are going to accompany it as:
This can lead to ambiguity whether there is a XSS attempt in real or not and can impact the user experience to some extent. All on users acceptance.
Friday, January 08, 2010
Google Chrome 3.0.195.38 | Chrome Frame - Reloading Memory Allocation based Tab Crashing
Google Chrome, right from the start has shown some stringency in tab crashing. But crashing tabs or full browser crash is becoming more smoother than the previously reported cases. On playing around with Google Chrome and Chrome Frame direct tab crashing has been reloaded. The specific points are mentioned below:1. Scripts are checked against memory allocation part and raises a warning.
2. In recent versions playing around with JavaScript based conversion of Unicode
values to characters and rendering it directly leads to tab crashing.
3. It has become more smoother and direct in the functionality.
The software tested against this rule set is mentioned below:
1. Google Chrome Browser
2. Google Chrome Frame. (IE8)
Both are installed on x64 systems running windows vista and IE8. The test is based on the script code designed to show the tab crashing in controlled manner.
Video :- Google Chrome 3.0.195.38 | Chrome Frame - Reloading Memory Allocation based Tab Crashing
IE8 directly raises a warning as:
IE8 functionality is hampered. The crash produces a register state as mentioned below:
EAX 00000000
ECX 3F800000
EDX 00000005
EBX 1FC00000
ESP 013DED00
EBP 013DED1C
ESI 0FDFFFF7
EDI 00CDEA00
EIP 6A28FCAA chrome_1.6A28FCAA
C 0 ES 002B 32bit 0(FFFFFFFF)
P 1 CS 0023 32bit 0(FFFFFFFF)
A 0 SS 002B 32bit 0(FFFFFFFF)
Z 1 DS 002B 32bit 0(FFFFFFFF)
S 0 FS 0053 32bit 7EFDA000(FFF)
T 0 GS 002B 32bit 0(FFFFFFFF)
D 0
O 0 LastErr ERROR_NOT_ENOUGH_MEMORY (00000008)
EFL 00000246 (NO,NB,E,BE,NS,PE,GE,LE)
ST0 empty 0.0
ST1 empty 0.0
ST2 empty 236.00000000000000000
ST3 empty 0.0
ST4 empty 0.0
ST5 empty 1000.000000000000000
ST6 empty 309683.00000000000000
ST7 empty 0.0747806972940452397
3 2 1 0 E S P U O Z D I
FST 0020 Cond 0 0 0 0 Err 0 0 1 0 0 0 0 0 (GT)
FCW 027F Prec NEAR,53 Mask 1 1 1 1 1 1
The issue presented in this post shows the advancement in execution of scripts and silently crashing the tabs. This issue has been designed as a controlled layout for showing the possibilities of crashing in Chrome.
Note: This is designed for educational purposes and improving the functionality of open source software.
Tuesday, January 05, 2010
Link Injection Redirection Attacks - Exploiting URL Pattern in Google Chrome - Browser Design Failure
Update: As pointed by Google in the below mentioned link that issues was not reported previously.
http://www.webappsec.org/lists/websecurity/archive/2010-01/msg00022.html
We strictly believe in responsible disclosures. It was reported on 28 November 2008 and the status was changed to "Wont Fix" by the team itself. You can have a look at:
http://code.google.com/p/chromium/issues/detail?id=4739
Recently with an outcome of Owasp RC1 top 10 exploited vulnerability list , redirection issues have already made a mark in that. Even the WASC has included the URL abusing as one of the stringent attacks.
Well to be ethical in this regard these are not the recent attacks but are persisting from long time. The only difference is the exploitation ratio has increased from bottom to top. So that's the prime reason it has been included in the web application security benchmarks. But the projection of redirection attacks is active now.
This post is not about explaining the basics of redirection issues. It is more about the design vulnerabilities in browsers that can lead to potential persistent redirection vulnerabilities. We will implement this attack as an example scenario against the long persisted vulnerability in Google Chrome released long back by Secniche Security. The details of this vulnerability can be found at below mentioned links:
1. Google Chrome URL Obfuscation Vulnerability.
2. Milw0rm Database
3. Securityfocus
The issue has been notified to Google Chrome Security team many times but it is still persisting and can be effectively exploited. Considering other browsers such as Mozilla , IE8 below mentioned restrictions have already been implemented as:
1. Mozilla has implemented an alert check when ever rogue link is clicked informing the user for the malicious operation in process.
2. IE8 has completely changed the link interpretation behavior.
The attack scenario - (Web Application Security Testing)
1. A vulnerable website prone to redirection.
2. Browser vulnerability in interpreting injected links: Google Chrome
The video can be seen here:
Link Injection Redirection Attack - Exploiting Google Chrome Design Flaw
Regards
