We’ve got a lot of new research in our hands but so far only one got disclosed to the public.
I’m talking about the LeapFrog LeapPad Ultimate research. It got a few hits on the media (CNET, The Telegraph, ZDNET, BleepingComputer, Threatpost, Fortune, …) and I’m very proud of this work specially because it keeps children more secure.
You can see a small PoC video here and the full research at the Checkmarx blog.
In these last couple of weeks Checkmarx Security Research Team disclosed some of our research:
These hard work from our team got a few attention from the media:
My team has been working hard and we release more juicy stuff:
– Common Security Mistakes when Developing Swift Applications – Part I
– Meet NFCdrip – a New Security Concern for Air-Gapped Systems
– What’s in Your Website? Lurking Risk from Third-party Resources
– How Secure Are the Browser Extensions You Create?
Pedro Umbelino also gave a talk in hack.lu – Mind The (Air)Gap, so this last weeks have been amazing.
Some of our work was published and I would like to share it here:
More coming soon in a web near you 🙂
The team who loves hacking and learning new things have published more stuff:
CSRT latest work and news:
More to come really soon… 🙂 Having fun hacking!
Just to give a small update on my work… I’ve been more active on my Twitter account so follow me to get the latest updates on my security work 🙂
Also here are some work I’ve done:
Regarding conferences I’ve been on Join 2016 @Braga presenting the talk “Hacking from Black to White”.
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.
“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:
https://www.google.com/app/setup.bat?callback=calc
[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:
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 🙂
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?
Luis Grangeia and I talked to portuguese media Tek Sapo about Anonymous and terrorism. Worth taking a look into the article. [portuguese only]