From Security Weekly Wiki
Revision as of 16:25, 2 February 2012 by Pauldotcom (talk | contribs)
Jump to navigationJump to search

Announcements & Shameless Plugs

PaulDotCom Security Weekly - Episode 276 for Thursday February 2nd, 2012.

  • John Strand will be teaching Offensive Countermeasures at SANS Orlando March 23-24th: Check it out here
  • Subscribe to our only non-computer security related show dedicated to Cigar Enthusiasts Stogie Geeks with Paul Asadoorian and Tim "BugBear" Mugherini. Wether you smoke an occasional cigar or daily, this show is for you! Tune in as we review the latest cigars being released and talk "Stogie Tech".

Interview: Joe Stewart

Joe Stewart is the Director of Malware Research for Dell SecureWorks’ Counter Threat Unit℠ research team. As a leading expert on malware and Internet threats, he is a frequent commentator on security issues for leading media outlets such as The New York Times, MSNBC, Washington Post, USA Today and others.


  1. What kind of work does the Counter Threat Unit concentrate on?
  2. Tell us about HTRAN and Shady Rat
  3. How is Shady Rat connected to the RSA breach?
  4. How worried should the average U.S. business be with cyber-espionage?
  5. Is conficker dead? How popular was your conficker eye chart during the height of conficker?

More info [PDF on Shady Rat]

Guest Tech Segment: Jon Oberheide

  1. Tell us about your Do Not Root Robots research and the dangers of "jailbreaking".
  2. How do the Android Market Interactions work?
  3. What are the problems with the web version of the Android Market distribution model?
  4. Can we trust the Android permissions model? Can the permissions be circumvented by an app?
  5. What did your RootStrap app do to make it deserved of the honor of being the first app to be remote-killed/wiped by Google from users’ devices using their GTalkService mechanism?
  6. What about post-rooting self protection? Can an app keep itself persistent?
  7. How is Android different than iOS in terms of your research?
  8. Does Android deserve its reputation for malware or are recent malware outbreaks such as Symantec's recent Android.Counterclank claim of mass infection?
  9. What do you think of Charlie Miller's recent research that caused his being booted out of the Apple Developer's program?
  10. What other research are you looking into at the moment? What's next for Team Joch?

Tech Segment - UPnP Hacking For Penetration Testers

UPnP Discovery With Nmap

In a previous segment I covered how you can use Nmap to enumerate hosts via broadcast protocols, such as UPnP with the following command:

nmap -Pn -n --script=broadcast

It seems the Nmap team has added functionality (or I just have new stuff going on on my network, or both!). So check this out, it detect Dropbox in use:

| broadcast-dropbox-listener: 
| displayname  ip             port   version  host_int  namespaces
|_77339174  17500  1.8      77339174  69385827, 61346060, 82845516, 54162449, 69420146, 6768627, 58215509, 58372182

UPnP Discovery and Control with Backtrack 5 and Miranda

I am still fascinated with what information can be gathered from passive sniffing and broadcast traffic. I decided to take a deeper dive into UPnP, knowing that I have some deviced on my network that are running it (such as my TV, receivers, and Roku players). I found a tool called Miranda, written in 2008 it allows you to enumerate UPnP devices, gater information from them, and even make changes if the device allows that. My mission? From the network be able to mute my TV. Here's how I did it:

Miranda comes pre-installed on Backtrack 5, which is very handy. The first thing to do is fire it up (its located in /pentest/enumeration/miranda). First you need to execute a search for UPnP devices using the msearch command:

upnp> msearc

Entering discovery mode for 'upnp:rootdevice', Ctl+C to stop...

SSDP reply message from
XML file is located at
Device is running Roku UPnP/1.0 MiniUPnPd/1.4

SSDP reply message from
XML file is located at
Device is running Linux/9.0 UPnP/1.0 PROTOTYPE/1.0

SSDP reply message from
XML file is located at
Device is running Linux/9.0 UPnP/1.0 PROTOTYPE/1.0

I've pruned the list for brevity, but you can see one Roku, my receiver and my TV. Turns out the receiver and TV use the same commands. Interesting to think how you could generalize commands and script them on a network. Next you can list out all the hosts dicovered:

upnp> host list


Use the host get command to read the entire tree of UPnP commands. This needs to be successful if you are to be able to send commands to the device:

 upnp> host get 5

Requesting device and service info for (this could take a few seconds)...

Host data enumeration complete!  

Now review some information about the device using the host summary command:

 upnp> host summary 5

XML File:
	manufacturerURL: http://www.onkyo.com
	modelName: TX-NR509
	modelNumber: TX-NR509
	friendlyName: TX-NR509
	fullName: urn:schemas-upnp-org:device:MediaRenderer:1
	modelDescription: AV Receiver
	UDN: uuid:aeb01704-c117-04b9-db1e-0409c1b9c871
	modelURL: http://www.onkyo.com
	manufacturer: ONKYO 

The host info command gives you some further data:

upnp> host info 5

xmlFile :
name :
proto : http://
serverType : MediabolicMWEB/1.8.225
upnpServer : Linux/2.6.33-rc4 UPnP/1.0 MediabolicUPnP/1.8.225
dataComplete : True
deviceList : {}

You can save all of this data to disk with the following commands:

upnp> save data onkyo

Host data saved to 'struct_onkyo.mir'

upnp> save info 5 onkyo

Host info for '' saved to 'info_onkyo.mir'

Inside the file info_onkyo is all the commands for reference:

Device information:
        Device Name: MediaRenderer
                Service Name: AVTransport
                        controlURL: /upnp_control_2
                        eventSubURL: /upnp_event_2
                        serviceId: urn:upnp-org:serviceId:AVTransport
                        SCPDURL: /scpd/AVTransport_1
                        fullName: urn:schemas-upnp-org:service:AVTransport:1
                                                        dataType: ui4
                                                        sendEvents: N/A
                                                        allowedValueList: []
                                                direction: in 

Next we execute the command, pasing is the serviceID, tag, and command:

 upnp>  host send 5 MediaRenderer RenderingControl GetMute

Required argument:
	Argument Name:  InstanceID
	Data Type:      ui4
	Allowed Values: []
	Set InstanceID value to: 0

Required argument:
	Argument Name:  Channel
	Data Type:      string
	Allowed Values: ['Master', 'LF', 'RF']
	Set Channel value to: Master

CurrentMute : 0

We can see above the TV or receiver is not muted. Next, we can chenge the value:

upnp>  host send 5 MediaRenderer RenderingControl SetMute

Required argument:
	Argument Name:  InstanceID
	Data Type:      ui4
	Allowed Values: []
	Set InstanceID value to: 0

Required argument:
	Argument Name:  DesiredMute
	Data Type:      boolean
	Allowed Values: []
	Set DesiredMute value to: 1

Required argument:
	Argument Name:  Channel
	Data Type:      string
	Allowed Values: ['Master', 'LF', 'RF']
	Set Channel value to: Master 

It was pretty neat to be able to mute the TV over the network. This is a documented "feature", but should require some sort of authentication. Think about the devices on your nework that have this enabled, or could have this enabled. Good Lord, I hope there are no SCADA devices implementing this protocol, however if a control channel is left open without authentication, this is where things can go wrong.

I should note, that in order to get this to work, I had to modify the source code. When commands were being sent to the device, it was not building the POST request correctly, and ignoring one of the directories. So I changed the following lines:

if self.ENUM_HOSTS[index]['proto'] in service['SCPDURL']:
		-xmlFile = service['SCPDURL']
		+xmlFile = 'dmr/' + service['SCPDURL']
		-xmlFile += service['SCPDURL']
		+xmlFile += 'dmr/' + service['SCPDURL']

Yea, its a "wicked hack" and the logic needs to be changed to modify the path on the fly of the POST request.

UPnP Inspector

This tool does not come with Backtrack 5, however use the following two commands to install it:

# apt-get install python-setuptools

# easy_install UPnP-Inspector

Once installed it gives you a GUI to discover, browse, and send commands to devices. The neat part about this program is that you can browse files over UPnP if its configured to do so! Below are some screenshots:


Paul's Stories

Darren's Stories

Larry's Stories

Jack's Stories