Operation n

Update: Removed JavaScript Example
Update: Removed tables due to cross browser issues.

JavaScript External File Scanner (JSEScanner)
Author: david.kierznowski_at_gmail.com
http://michaeldaw.org

JSEScanner is a simple idea:
1. Use uses <script src=”"> to request a JavaScript file.
2. Use typeof to verify its existence.
3. Use result in fingerprint.

This technique can be used to enumerate internal web servers and/or applications via a clients browser. It is limited in that it can only detect web servers as it uses <script src=”"> for connections and relies on detecting JavaScript functions for callback.

It is possible to add Iframe Timeouts to extend its port scanning capabilities. However, this is nothing new. I may add it later.

This tool was inspired by Spidynamics recent IMG based JavaScript port scanner (or was this Jeremiah Grossman’s idea…?).

Due to the limitations of client-side scanning, additional techniques are required to produce more accurate results. I can see a JavaScript Scanning Suite on its way. I wouldn’t be surprised if it were named, “jmap”.

Please email fingerprints as you play around.

Fingerprinting Web Server Software:
Device | JavaScript File | Valid JavaScript Function
Linksys Wireless Router | Gozila.js | LogButton_check
IIS ASP.NET | $JSVALDIR/$VER/WebUIValidation.js | ValidatorUpdateDisplay

Note: See http://michaeldaw.org/projects/asp-auditor-v2/ for more information regarding ASP.NET’s JS Validate directories.

Fingerprint Applications on Web Servers:
Device | JavaScript File | Valid JavaScript Function
TWiki | /pub/TWiki/TWikiJavascripts/twiki.js | initForm
bblog | /bblogg/bblog/script/index.js | removeFocusBorders
wordpress | /wp-admin/xfn.js | GetElementsWithClassName

The source for the tool is available here

A shiver ran down my spine as Cole’s shadow faded back into the compound.

“Okay, this could be worse,” I muttered. Standing quickly, determined to find an exit, I began my mission of circling the building. I put my left arm out with my fingers extended, so that my fingertips brushed along the side of the wall as I walked.

“What a night!” I grumbled, moving slowly in the dark, my pupils now fully dilated, compensating for the lack of light.

Reaching the corner of the wall, I could make out, that the wall was cutting off entry to the side of the building. Feeling trapped, I turned and ran back the way I had come. I slowed my pace as I reached my initial starting point. I walked as before, except this time running the fingertips of my right hand along the side of the wall.

I made my way around the barrier, stopping at the corner, on the opposite end of yard, my breathing sporadic. It wasn’t looking very bright.

You would think there would be a gate or something but I guess that would be to easy for the type of night I was having.

I wasn’t getting anywhere. I headed towards the front door to check on the whereabouts of my new found “friend”.

After a few meters, a small green light suddenly shone on my right hand side. A light appeared through a now opening door. I stepped back and clinched my eyes for a few moments.

ASP Auditor v2.1B is now available. Changelog below:

 Changelog:
 --v2.1-- 25/Sep/06
  * GET /Trace.axd often leaks ASP.NET version when other methods fail. AA now catches
  the ADN Version if it is available.
  * Fixed "?" bug in JavaScript Validate test
  * Added Version into usage()

  --v2.0-- 16/Sep/06
 * Version plugin allowing specific ASP.NET versioning.
 * Version brute force capabilities using JavaScript validate
 directories.
 * Check if global ASP.NET validate is being used.
 * Added brute force function and option in usage()

“The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are.” - quote from OWASP Top Ten.

I did a brief search on Google and did not see any obvious objections or flames with regards to the OWASP Top Ten. The industry as a whole seems to be adopting it, including automated web application testing tools and penetration testing companies. I recently performed the PCI Visa/MasterCard assault course, which also rates (or did) its application testing against this standard. These are my thoughts (or mad rantings):

Some of my likes:
* I like the idea behind having a web application standard. OWASP has pushed this more then anyone else that I have seen.
* A10 (Insecure Configuration Management) is actually specific, quite nice.

Some of my dislikes:
* The headings and definitions can be confusing
* The more detailed links seem to go off topic and intertwine with each other (i.e. A1, A4 & A6)
* In my opinion they are not ordered by priority (not sure if they are meant to be)
* Some relevant information is lacking (i.e. weak usernames and passwords, user enumeration vulnerabilities)
* When was the last time it was updated or do such generic issues not require change? If so, is this really an effective measure in testing and development?

Comments:
I never really payed much attention to the OWASP Top Ten. However, this is quickly becoming the web application testing standard. To be honest, this scares me. To me, the OTP (OWASP Top Ten) is just not where it should be for the publicity its recieving. It is mostly generic, chunky and confusing. I don’t see how anyone can claim to use the OWASP Top Ten with any degree of accuracy.

Thoughts:
My idea of the OWASP Top Ten include more specifics and less talk. These specifics should be measured with current attack trends. Regular updates are crucial.

Thoughts welcome, the OWASP Top Ten are as follows:

A1 Unvalidated Input
Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack backend components through a web application.

A2 Broken Access Control
Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users’ accounts, view sensitive files, or use unauthorized functions.

A3 Broken Authentication and Session Management
Account credentials and session tokens are not properly protected. Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users’ identities.

A4 Cross Site Scripting
The web application can be used as a mechanism to transport an attack to an end user’s browser. A successful attack can disclose the end user?s session token, attack the local machine, or spoof content to fool the user.

A5 Buffer Overflow
Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. These components can include CGI, libraries, drivers, and web application server components.

A6 Injection Flaws
Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application.

A7 Improper Error Handling
Error conditions that occur during normal operation are not handled properly. If an attacker can cause errors to occur that the web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server.

A8 Insecure Storage
Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection.

A9 Application Denial of Service
Attackers can consume web application resources to a point where other legitimate users can no longer access or use the application. Attackers can also lock users out of their accounts or even cause the entire application to fail.

A10 Insecure Configuration Management
Having a strong server configuration standard is critical to a secure web application. These servers have many configuration options that affect security and are not secure out of the box.

References:
http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Targeted Web Attacks
Part 2 of Social Networks the New Fingerd
Author david.kierznowski_at_gmail.com
http://michaeldaw.org

1. Introduction

I recently released an article titled, “Social networks the New FingerD”. This article gave an example of using LinkedIn in passive username enumeration attacks. This article will discuss using Search engines and OpenPGP key servers as additional enumeration resources. None of these ideas are new, but in my opinion require a bit more light, especially when looking at RSnake’s recent XSS Top Vulnerability post

2. Purpose
At the moment XSS attack scenarios are very broad. XSS to create a botnet or propogate a worm etc etc. There is no real direction toward actual focused XSS exploitation. In theory one could own the continent(s) and then filter out specific targets, but lets face it, this is probably not the smartest thing to do.

3. The How?
My initial thoughts on targeted Web attacks “from the Internet” include some of the following ideas:

Backdooring the Company Homepage
Many users have their browser’s default (or startup) page set to the company website. However, this may not work in some cases as internal users often connect to an Intranet website rather then an Internet website. Another solution to this problem may be to backdoor another website associated with the company (i.e. company webmail, or Citrix Gateway).

Information Gathering Attacks
In most cases, specific exploitation requires fore-knowledge of our target. For example, Jane Daw works at company X as a legal secretary. Once this information is known any number of “specific” attacks can be launched. These attacks can occur via HTTP, Email, social engineering and password brute forcing to name a few.

Over the last month, pdp (architect) and I (was that the right way round, can never remember) have been working on backdooring a number of web technologoies. So far our list includes:
* Web Pages
* Flash
* Quicktime
* PDF
* MP3 (Although this uses Quicktime)

So the question still remains, what web resources do we have available to us to passively enumerate users within an organisation?

We have already discussed using Social Networks such as LinkedIn. Two other possibilities are as follows:
* Public Key Servers
* Search Engines

3.1 Public Key Servers

Public key servers allows a single repository for users to store their public keys on the Internet. This allows users to encrypt email between two parties easily without having to hastle the recipient for their public keys.

This service is an excellent resource to enumerate employee details within an organisation.

Example search for google.com using “http://keyserver.veridis.com:11371“:

--snip--
 Results 1 - 30 of about 41 for google.com. (0.019 seconds)
	Key(s) 	Key ID 	Size 	Creation 	Expiration

*hidden* *hidden*@google.com 	0x4F79C91B 	4096/1024 	2006/06/13 	2011/06/12
*hidden* *hidden*@google.com 	0x8475A4CF 	2048/1024 	2001/05/07 	Never
*hidden* *hidden*@google.com 	0x9038F60E 	2048/1024 	2001/02/20 	Never
*hidden* *hidden*@google.com 	0xE617F27A 	1024 	2005/07/13 	2006/07/13
*hidden* *hidden*@inodes.org 	0xD02F8773 	1024/1024 	2000/03/08 	Never
*hidden* *hidden*@google.com	0x20C9885A 	2048/1024 	2005/10/12 	Never
*hidden* *hidden*@red-bean.com 	0xEC6B5156 	1024/1024 	1998/11/09 	Never
*hidden* *hidden*@google.com 	0x4E844EF3 	1024 	2005/07/27 	2006/07/26
*hidden* *hidden*@google.com 	0x2349D344 	2048/1024 	2005/12/06 	2007/12/06
*hidden* *hidden*@google.com 	0x438046E4 	2048/1024 	2005/12/12 	Never
--snip--

3.2 Search Engine

Search engines when used correctly can yield very sensitive information. For more information on this see: http://johnny.ihackstuff.com/.

4. Tools

I was thinking about writing a tool to automate these checks, however, when bouncing it off pdp (architect), I found he had already done the work.

His tool is a little outdated but provides support for both Google and OpenPGP checks. It can be found at the following URL:
http://www.gnucitizen.org/projects/met/