This post is a result of reading the following useful report:

The other reason to beware ExternalInterface.call() (http://lcamtuf.blogspot.com/2011/03/other-reason-to-beware-of.html)

The issue that I want to discuss here is not something different; however, I want to add something to the current materials.

Description:

According to the Adobe website, ExternalInterface.call() can accept a JavaScript function name as the first argument and a string which would be sent to that JavaScript function. Adobe says “When the call is to a JavaScript function, the ActionScript types are automatically converted into JavaScript types; when the call is to some other ActiveX container, the parameters are encoded in the request message.”. Therefore, in our case, the string would be converted into JavaScript type.

All we are trying to say is that it is possible to inject a specific parameter to an input and change the way of running the JavaScript. I should say it is very similar to the current code Injection methods in which we actively change the queries/requests to run whatever we want!

Proof of Concepts:

I want to explain it by using the example that Adobe has put in its document. I have put all the files in the following URL: http://0me.me/demo/adobeflash/ExternalInterface.call/ . Please use Mozilla Firefox if you want to see the same error messages as this PoC.

Now follow these steps:

1- Open this link: http://0me.me/demo/adobeflash/ExternalInterface.call/demo.html

2- Enter “\”” in the flash box (dark box) and press the gray button in front of it:

3- Now, you should be able to see this error in Error Console:

As you can see, we could escape the slash character “\” which was for escaping the double quotation character. Therefore, we are able to inject our JavaScript here now.

4- Now, try to enter “\”));alert(/XSS/)}catch(e){}//” in that box and press the gray button. You should be able to see the alert message:

It is because of the fact that we could complete the main functions and comment the remaining bits which is the method of code injection.

Now, you may think that we need to have a valid JavaScript function in the page or you may even think we always need to have a HTML file. I will explain this in the next section and I will prove that you can execute a JavaScript code even by running the SWF file directly without using any HTML file or JavaScript function.

Run the flash file directly now:

Now I want to add this bit that we do not need to have a real JavaScript function or a HTML page to execute a JavaScript code under the website content. In this case we only need to put the JavaScript code inside the “catch” section. This is the PoC:

1- Open this URL: http://0me.me/demo/adobeflash/ExternalInterface.call/ExternalInterfaceExample.swf

2- Now, enter the following text in the box and press the button:

“\”));alert(/XSSThis/);}catch(e){alert(/XSSOr/)}//”

3- You should be able to see this message now:

As a result, we can do a XSS attack just by opening a vulnerable or malicious/uploaded SWF file.

Note: you may have problem with closing the alert window in some browsers.

Why can this be a risk?

The websites which are using ExternalInterface.call() with the user’s provided input -without having input validation- can be in risk of having XSS vulnerability. Besides, an attacker can upload a malicious SWF file when a website lets him/her do so in order to make the website vulnerable to XSS attack – in this case I should say, an attacker might be able to do more than a XSS by uploading a SWF file.

Solution(s):

If we think about this code injection, it is really another input validation issue. It again says that the developers must not trust the provided inputs and we certainly need to have input validation when we receive the user’s input.

Note: Regarding the main reference of this text, Adobe has not accepted this as an issue to fix it fundamentally yet.

References:

- The other reason to beware ExternalInterface.call() http://lcamtuf.blogspot.com/2011/03/other-reason-to-beware-of.html

- Agora 3.0.0 RC1 Rev.4 XSS Vulnerability http://jeffchannell.com/Joomla/agora-300-rc1-rev4-xss-vulnerability.html

- Finding Vulnerabilities in Flash Applications http://www.owasp.org/images/d/d8/OWASP-WASCAppSec2007SanJose_FindingVulnsinFlashApps.ppt

- Cross-Site Scripting through Flash in Gmail Based Services http://blog.watchfire.com/wfblog/2010/03/cross-site-scripting-through-flash-in-gmail-based-services.html

- ActionScript 3.0 Language and Components Reference http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/external/ExternalInterface.html

- Code Injection http://en.wikipedia.org/wiki/Code_injection

There was a Cross Site Scripting (XSS) vulnerability in hero’s mansion rename section. This issue was because of using “id” and “gid” input parameters at the same time. “gid” was used for loading the hero’s mansion, and “id” was used to insert a Javascript code. You can only see one of them as an input for a single file at the same time. However, I used them together and found this vulnerability:

http://sN.travian.EXT/build.php?gid=37&id=<script here>&rename

As there was a “httponly” flag for the cookies, it was not possible to hijack the sessions. However, we could still use it to do several things. The simplest one was to hijack the saved username/password from the browser. I should say that there was another issue with the login page last year based on which someone could create the Travian cookie and log into the system by the victims session.

There was also another issue with validation of unique email addresses by which a user could create several accounts with the same email address. It was sufficient to enter a “comma” in front of the email address to have a new valid email address. For example someone could register several times without having any problem in receiving the confirmation code by using “test@secproject.com”, “,test@secproject.com” , “,,test@secproject.com”, and so on.

Fortunately these issues have been patched after more than a year. This delay was only because of not having a direct reference to contact as no one/source was publicly responsible for the security issues.

These issues go back to June 2009. Related Link: http://soroush.secproject.com/blog/2009/11/travian-game-vulnerabilities-in-progress/

Note: I highly suggest the providers to put at least one email address in their contact page for normal bugs and security issues. They should also have a process to fix a security issue and give its credit to the finder(s) somehow (by putting the finder’s name in the website news, release notes, …) if they do not want to pay for their vulnerabilities! It is a pain when the security researchers can only see sale and marketing email addresses in many of the providers’ contact pages; and that’s why too many of these security issues are being published before having any patch every day.

Now, I want to show a flaw in this process in which by clicking on an external URL in Facebook, users can go directly to the destination URL without passing the “facebook.com/l.php” page:

Add a “:/” at the end of the domain name! That’s it!
PoC:
Put these links in a comment section on your Facebook page and click on them too see the result (If you know how to work with local proxy tools such as burp suite, you can directly post a link on your wall [not just in comment section] with “:/” in the URL to exploit this flaw):
     - https://fp.auburn.edu:/oit/show_server_variables.asp
     - http://soroush.secproject.com:80:/

Now, do not click on the links which have “:/” after the domain name with or without port number! (18 Dec. 2010)

NOTE: This issue had been reported to Facebook at least twice more than 1 month ago without having any response.

However, Gareth Heyes has already written great things about it that I can just refer you to the pages (instead of writing it again):

http://www.thespanner.co.uk/2010/10/31/jsreg-bypasses/
http://rgaucher.info/planet/The_Spanner/2010/11/07/Soroush_Dalili_breaks_JSReg_again

Gareth is writing these functions alone, so if you have any great idea please let him know. He is a nice and clever guy; so, do not miss your chance to have a great friend!

Again, thanks Gareth.

For example:

And look at this if you currently have installed a Skype on your computer: 0044-7987654321

Now the problem is: Skype always sends all of these selected numbers to one of its servers “pnrws.skype.com”. The worst thing is that they are actually sending the page URL in “referrer” section of the header as well. As a result, Skype server can log all of this information with IP address of the user to track a user or to identify a person. And the question is why Skype needs this information?

For proof of concept, I will put a phone number in a Facebook page and monitor the HTTP requests by using Fiddler. The result has been shown in the following images (if you cannot see the images, your ISP has been blocked by GoDaddy):

Facebook page:

In Fiddler:

As you can see, my Facebook URL and the phone number are sent to the Skype server.

However, I think number detection of Skype Add-On does not send more important information such as credit card numbers!

Now, if you are a bit concern about your privacy, just disable the Skype Add-Ons (Plug-Ins) in your browsers.

Please let us know if you know how Skype uses this information and why Skype needs this information.

http://secunia.com/community/forum/thread/show/4951/secunia_psi_how_to_delete_information

 I want to prove that the Secunia PSI actually passes the following information which can be treated as a confidential data for a company or causes privacy issues for a real person:

1- Domain Name or Workgroup Name (“langgourp”)

2- Computer Name (“hostname”)

3- Username (as there are special files on “Application Data” directory such as Mozilla Firefox “extensions” folder which should be listed by using Secunia PSI)

4- List of directories of the hard disk which contain some special name with extensions such as “exe”, “dll”, “ocx”, and so on. Some of these directories can contain important information such as the personal names, project names, company names, and so on.

My proof is very simple and you can do it yourself. As Secunia PSI is based on a Web Application, all of its messages to its server can be monitored by using Fiddler HTTP Debugging Proxy which is absolutely free: http://www.fiddler2.com/Fiddler2/version.asp

Now follow these steps:

- Scanning the computer once by using the Secunia PSI (If it is the first time)

- Close the Secunia PSI application completely from the task manager

- Open Fiddler and go to “Tools”> “Fiddler Options”> “HTTPS”> and select “Decrypt HTTPS traffic” option and click on “OK”

- Now, open Secnuia PSI application again

- Monitor its behavior by using Fiddler. If there isn’t anything on Fiddler, click on “Start Scan” button of Secunia PSI to scan your computer.

- Now, look at the responses from the Secunia server. As you can see there are information of your computer in responses which means the Secunia server has stored them on its database.

For example, look at the following images (if you cannot see the images, your ISP has been blocked by GoDaddy):

Now, my recommendation for Secunia is to use a local database on each computer to keep location of files and folders private. The only thing that should be passed to the server is the user ID, signature (hash) of the application, and file or application ID which can be linked to the database in order to find the exact place of that files and/or folders on the local computer. Moreover, I cannot understand why it needs to send the Domain/Workgroup Name and the Computer name to its server (maybe it is used for copyright!).

My suggestion to the users: Currently – 1^st Dec. 2010 -, using Secunia PSI for those people who want to be anonymous and those companies which want to keep all of their information private is a nightmare and this application should be removed. Ask Secunia to fix this issue.

Hope to see a better Secunia PSI soon. 

Please visit the project section:

http://soroush.secproject.com/blog/projects/csrf_poc_template/ 

I’m scared. What should I do then?
1- Only open your email in private browsing mode.
2- Do not click on unknown links which are sent to you via offline messages or your email. If you want to open that link, simply open another private browsing and copy/paste that link there to open it. Moreover, you can open those links in a different browser from your open yahoo mail or your default browser.
3- Please always look at the link destination and do not trust its name. For example this link will redirect you to google.com instead of: http://www.yahoo.com/.

I clicked on a link by mistake. What should I do?
1- If you have knowledge of web security, you can open that link while monitoring your browser by using a local proxy such as Fiddler or BurpSuite. You will see if there is any request to yahoo.com or any other domains then.
2- If you are not sure about what you have done, you MUST change your password immediately. This is the only way that you can protect yourself. Even decreasing the life time of your Yahoo session (Cookie) cannot solve your problem.

What will happen if I don’t care?
1- Attackers will have access to your Yahoo.com account without knowing your password. Fortunately, they cannot change your password directly (they still can use forgot password section).

NoScript v2.0.2.3 does not have this problem anymore. I’m happier now. tnx to its clever author.

As I told Giorgio, all the problems will be reported to him first ;) 

Woohoo! You/We/They/or whatever! can still use unicode in some places!

NoScript cannot find out special unicode characters which mean something in ASP:

PoC:

http://Example.com/VulnFile.asp?DangInput=%u2329scr%u0131pt%u232A%u212Fval(‘alert’%2b’(“NoScript Bypass in ASP!\\nBy Soroush Dalili”)’)%u2329/scr%u0131pt%u232A

In this example I selected the characters from: http://rishida.net/scripts/uniview/uniview.php . For instance:
%u2329 = <
%u0131 = i
%u232A = >
%u212F = e
From Microsoft point of view! Therefore, IE8 XSS prevention can detect this encoding and NoScript cannot detect it.

- Some software are immune against my reports like Fortify! I’m not sure if it’s a good thing for them however! This is not my policy!

- Burpsuite Pro is great and I’m waiting for the new version after fixing my issues (current version is 1.3.07).

- A dangerous CSRF vulnerability in Secunia Community has been fixed – in which attacker could change a user’s email address and then use forgot password feature to reset his/her password – immediately after my report.

More info: http://secunia.com/community/forum/thread/show/4856/notification_of_fixed_csrf_issue

- CodeProject.com wants to fix a vulnerability that I’ve reported 1 month ago.

- I’ve reported a Microsoft .Net security vulnerability to them and I’ve just received their first “thank you” email. Now, I’m waiting to see what would happen.

- I reported a dangerous CSRF vulnerability in BlogFa.com to them several months ago. Although they’ve fixed that issue, they did not give me any credit! Should I report their flaws in future? I’m not so sure!

- I want to release a powerful tool for Steganography in text soon! This is my MSc. project that I’ve changed it a bit.

Description:
Although IIS5 is very old, finding one is not impossible! Therefore, I want to introduce a technique to bypass the IIS authentication methods on a directory.
This vulnerability is because of using Alternate Data Stream to open a protected folder.
All of IIS authentication methods can be circumvented. In this technique, we can add a “:$i30:$INDEX_ALLOCATION” to a directory name to bypass the authentication.
In a protected folder such as “AuthNeeded” which includes “secretfile.asp”:
It is possible to run “secretfile.asp” by using:
“/AuthNeeded:$i30:$INDEX_ALLOCATION/secretfile.asp”
Instead of:
“/AuthNeeded/secretfile.asp”

More description:
Why IIS6 and 7 are not vulnerable:
- In these versions, IIS does not accept colon (“:”) character from the URL before the querystring.

Why we cannot use “::$Data” in IIS 5.1 anymore:
- IIS rejects the request if its URL contains “::$” (before querystring).

Why IIS5 is vulnerable to “Directory Authentication Bypass” by using “:$I30:$Index_Allocation”:
- IIS only verifies the directory name to check for authentication. Therefore, we can use “http://victim.com/SecretFolder:$I30:$Index_Allocation/” instead of “http://victim.com/SecretFolder” to bypass the authentication.

Is it possible to bypass something else by using “:$I30:$Index_Allocation” on a NTFS partition:
- If a checking is only based on the directory name, it can be bypassed by using this method.

Download this advisory from: http://soroush.secproject.com/downloadable/IIS5.1_Authentication_Bypass.pdf
or: http://0me.me/demo/IIS/IIS5.1_Authentication_Bypass.pdf

Now, I want to share some odd behaviour of browsers with you. Let’s make them Crazy!

 1- First, we load a URL in an IFrame. Then, we load another website on the same frame. Now, by using “javascript:window.history.go(0)”, it will change the IFrame SRC to the first URL,  but it keeps the 2nd website on the IFrame!

 Try it here: http://0me.me/demo/crowzers/irsdl/addressbar_halt.html

 Which Browsers?

  - Mozilla Firefox 3.6.6

  - IE7

  - IE8

 2- We want to lock the address bar in different browsers by using “onblur” and “onload” events with “this.focus()”.

 Try it here: http://0me.me/demo/crowzers/irsdl/iframe_src_fool.html

 Which Browsers?

  - Mozilla Firefox 3.6.6

  - IE7

  - IE8

  - Opera 10.54

 3- We want to stop the browsers from working by using infinite loops and so on.

 Try it here: http://0me.me/demo/crowzers/irsdl/halt.html

 Which Browsers?

  - Mozilla Firefox 3.6.6: Halted with Mozilla Crash Reporter

  - IE7: Halted

  - IE8: Halted

  - Safari 5: Crashed on “javascriptcore.dll”

Good luck!

Download From Here: http://soroush.secproject.com/downloadable/XSUH_FF_1.pdf
Or Here: http://0me.me/demo/XSUH/XSUH_FF_1.pdf

Proof of Concept: http://0me.me/demo/XSUH/XSUH_demo_firefox_all_in_1.html

Note:  This technique has been tested on Mozilla Firefox 3.6.3, 3.5.9, 3.6.4build5 (26th May 2010).

Therefore, we need something else as a signature to improve the scanners result. And as a solution we can use a “/” as an identifier. In case of requesting a valid directory without adding a slash at the end of it, the web-server will add an slash automatically, and in case of having an invalid directory there will not be any slash at the end of the directory name.

Some examples:

Invalid Directory: http://www.microsoft.com/foobars

Valid Directory: http://www.microsoft.com/test

——–

Invalid Directory: http://code.google.com/foobars

Valid Directory: http://code.google.com/js

——–

Invalid Directory: http://www.facebook.com/foobars

Valid Directory: http://www.facebook.com/admin

——–

Invalid Directory: http://uk.yahoo.com/foobars

Valid Directory: http://uk.yahoo.com/private

——–

Cheers,

Soroush Dalili

Cheers,
Soroush Dalili

The Web Application Security Consortium (WASC) is pleased to announce the long awaited release of the WASC Threat Classification v2.0.

You can read more information from these links: http://projects.webappsec.org/Threat-Classification and http://projects.webappsec.org/f/WASC-TC-v2_0.pdf

Cheers,

Soroush

I’m writing this post as a response to the Microsoft security response in: “http://blogs.technet.com/msrc/archive/2009/12/29/results-of-investigation-into-holiday-iis-claim.aspx”.

They said that “We’ve completed our investigation into the claims that came up over the holiday of a possible vulnerability in IIS and found that there is no vulnerability in IIS.”. Therefore, I realized that this is not a Microsoft IIS hole. So, it should be a feature of IIS 6.0! In my opinion it’s a good feature for the attackers to bypass the web uploaders protection. Now my question is: why have they removed this feature from IIS version 7 and 7.5 then? And why are the others so concerned about this feature and some people added it to their exploits collection?

I think it’s not even a critical bug for IIS, but it is highly critical for most of the web applications.

Besides, Microsoft is so wrong about the default configurations since they said “customers who are using IIS 6.0 in the default don’t need to worry about this issue”.  I think they should look at the shared servers default configurations as well as the dedicated ones.

Finally, I think Microsoft should fix this feature as soon as possible to eliminate its risks! And, it is up to the web security researchers and the web penetration testers to decide about the impact of this vulnerability on the web applications.

PS:

You can also look at these links:

-          http://www.darknet.org.uk/2009/12/microsoft-iis-semicolon-bug-leaves-servers-vulnerable/

-          http://www.esecurityplanet.com/trends/article.php/3855936/article.htm

-          http://www.securityfocus.com/bid/37460/references

<script>
function recursiveFunc(){setInterval(“recursiveFunc()”,1);}
recursiveFunc();
</script>

Just save it as an HTML file, and try to open it with your browsers. You can convert “1” to “0” to get better result in Mozilla Firefox and Chrome.
I reported it to Mozilla Firefox as a bug.
Good luck.

The result was too simple, but interesting! I need only a semicolon between the “.asp” and the “.jpg” to execute an ASP file. So, the answer was “myfilename.asp;,jpg”. I have written some information about this vulnerability in:

http://soroush.secproject.com/downloadable/iis-semicolon-report.pdf

I’ll try to update this PDF file if there was a need to add or change some information.

Description of this vulnerability from Secunia.com is:

Description:
Soroush Dalili has discovered a vulnerability in Microsoft Internet Information Services (IIS), which can be exploited by malicious people to potentially bypass certain security restrictions and compromise a vulnerable system.

The vulnerability is caused due to the web server incorrectly executing e.g. ASP code included in a file having multiple extensions separated by “;”, only one internal extension being equal to “.asp” (e.g. “file.asp;.jpg”). This can be exploited to potentially upload and execute arbitrary ASP code via a third-party application using file extensions to restrict uploaded file types.

The vulnerability is confirmed on a fully patched Windows Server 2003 R2 SP2 running Microsoft IIS version 6. Other versions may also be affected.

There are also several websites which wrote about this weakness:

1. Secunia Advisory: Microsoft IIS ASP Multiple Extensions Security Bypass

2. Securityfocus: Microsoft IIS Malformed Local Filename Security Bypass Vulnerability

3. The Register: Microsoft IIS vuln leaves users open to remote attack

4. VUPEN Security: Microsoft IIS File Extension Processing Security Bypass Vulnerability

5. Securitytracker: Microsoft Internet Information Services (IIS) Filename Extension Parsing Flaw May Let Users Bypass Security Controls

I reported these two vulns. to its website just for having more security. And, I think these two vulnerabilities are fixed now.

However, I believe that still 70% of webistes are vulnerable against the OWASP TOP 10!

Also, I think you should read “Survey: Majority of Web sites vulnerable” as well.

Cheers,

Soroush

]]> http://soroush.secproject.com/blog/2009/11/my-belief-70-of-websites-are-vulnerable/feed/ 0