Sunday, 21 December 2014

Remote code execution on misconfigured systems using Werkzeug

One of the most popular WSGI utility frameworks for Python is Werkzeug. It simplifies the handling of HTTP connections within your Python application but also provides a powerful debugger that permits one to execute code from within the browser.

While the provided link warns those to not enable the debugger on anything production, it is often ignored or forgotten about and ends up being enabled in the first place. It is possible to search for systems on the Internet that have the debugger enabled and execute Python code remotely.

It should be noted that this affects both the Flask and Django frameworks mainly but could be used elsewhere.

Revealing and using the debugger

Getting the debugger to reveal itself is fairly simple: cause an exception. This can be achieved by writing some faulty code or by simply making it happen yourself such as in this code example using the Flask framework:
from flask import Flask

app = Flask(__name__)

def main():
All you need to do is execute the above as a Python script and the following should be outputted:
$ python
 * Running on
 * Restarting with reloader...
Now view the page via the URL it provides and you'll have access to the debugger as follows:

And as you can see it is pretty straightforward too:
You can view the code by highlighting over the code on the right.

Python code can be executed as if you were running the interpreter locally.

Finding affected hosts

Finding hosts is trivial using a search engine such as Google or a service like Shodan.

At the time of this writing, using Google does not net any results but previously during some research on this matter it did. It appears that any services that are indexed are being taken down fairly quickly.

If you wanted to try a Google search for the future, this search may provide a result:
intitle:"Werkzeug Debugger" "You can execute arbitrary Python code in the stack frames"
However, Shodan makes it easier to find servers that specifically run Werkzeug.

Finding servers that error out is fairly simple.
Some fine-tuning is required to find hosts that can have the code executed but they are there.

It should be noted that the debugger can be activated even without executing the HTTP server internally. Documentation exists that allows one to enable the debugger via Apache if you so dare.

It goes without saying that you should not execute any code if you run across a machine that has the debug mode enabled.

Preventing your application from being vulnerable

If you're developing an application that makes use of Werkzeug, you should avoid hard-coding a debug mode into it.

My suggestion is to try something like this:
import sys
if __name__ == '__main__':
    debug = 'debug' in sys.argv
This should require you to add 'debug' to the command line arguments when running the code, allowing you to just leave it to local development.

Wednesday, 10 December 2014

The 'joke' behind the signed Sony malware

Last night, I tweeted out a series of tweets correcting the stories issued by Kaspersky and ArsTechnica regarding the origin of the signing of the malware that had infected Sony. As a result, it got picked up by a CSO Online sometime after I had gone to bed and in the morning I had a  bunch of people on Twitter asking me questions.

The origin of the story is that a researcher (who wishes to be referred to as "yosposbithc") in an IRC channel I am in had been going through the Sony data and came across some PFX files used for code signing. With luck, he had quickly determined that the password to the file was in fact the filename itself ("spe_csc").

\Cert2\USERS\AMcMillian\Sony\Projects\The Big Picture\Certificates\spe_csc.pfx

In discovering this, we were asked, "what should I sign" by him. I initially suggested just signing 'calc.exe' since that tends to be used for demonstrating any RCE vulnerabilities. However, it was then decided that using a source from Malwr that the actual attacking malware used on Sony would be used instead.

Screenshot from Kaspersky's recent article
It was uploaded to VirusTotal and then tweeted out by myself shortly after. The time between it being signed and then showing up on VirusTotal itself was something like 10 minutes. It has not been used in the wild, I doubt that the researcher executed it at all, and it in its signed form is not available for download.

Kaspersky has since updated their article with the following:

So far, we have not encountered the signed sample in the wild. We've only seen it submitted to online malware scanning services. However, the existence of this sample demonstrated that the private key was in the public domain. At that point we knew we had an extremely serious situation at hand, regardless of who was responsible for signing this malware.
Reports indicate the "researcher" reached out to the certificate authorities to get the certificate revoked after submitting the malware online. The certificate would have been revoked without the creation of new malware. There really was no need to create new malware to prove that the certificate hadn't been revoked yet.
What is said here is true. Having myself previously worked at an anti-virus vendor, I can safely say that Kaspersky more than likely got the sample from VirusTotal as that was the case for when I still worked in their industry.
The certificate was revoked on December 7

However, Kaspersky erroneously reported that the certificate had yet to be revoked at the time of their writing. This was not the case as the researcher had reached out to DigiCert shortly afterwards and it was revoked on the weekend.

There is not much more to this story other than that. I do not have a copy of the certificate myself as I have chosen to not touch the Sony data. The unsigned malware itself is available from the Malwr link I previously supplied and copies of the signed malware are floating about now.

Tuesday, 25 March 2014

Namespro has seemingly poor password storage methods

Somehow I managed to lose the password to my account, which I had setup at one point for managing a number of my domains. It was likely that my password manager had an incorrect entry at some point or some other silliness resulted in my inability to log in. Needless to say I needed to reset the password and so I tried…

Why am I limited to between 4 and 16 characters for my password? What logic dictated this? There are a multitude of reasons on a technical level for this sort of behaviour, so I decided to ask them to get clarification.
I noticed that you enforce a 4-16 character limitation on passwords. Could you please answer the following:
- Is this limit purely a limitation created by the forms?
- How are they being stored in your database? Is it in plaintext or some sort of cryptographic algorithm?
Very straightforward questions and something that does deserve some level of technical explanation–no? Wrong. Here’s what they sent back:
Although you have not specified, we believe you are referring to the password of your account. To answer your questions:

1) The password requirement is validated by server-side algorithm.
2) Passwords are encrypted before being stored in our systems
We hope the above information is helpful to you. Please do not hesitate to contact us if you have any other questions. We will be glad to answer them for you.
“Server-side algorithm” and “passwords are encrypted” don’t tell me much. A “server-side algorithm” is what is providing the SSL connection between you and my server, but without you looking at the certificate that is fairly vague no? I decided to press a bit further:
Thanks for having gotten back to me. Could you please elaborate on this?

1) When you mean “server-side algorithm”, do you mean that the password length is limited by it? Can you elaborate on what this “algorithm” is? Is it what limits you from storing the passwords beyond 16 characters? Are there any starting characters that are not permissible?
2) What method of encryption do you use for storing the password? DES, 3DES, MD5, BCrypt, ROT13? Is it something else? Do you employ a per-user salt or a global salt?
These two questions are once again pretty straightforward–although throwing “ROT13″ into the mix might seem snarky. Why did your engineers decide that four to sixteen characters is an acceptable length and what do you use to ensure that the passwords are stored correctly? Sadly Namespro didn’t want to give up that information but instead tried to go this route:
Unfortunately, we cannot disclose the actual process on how we protect our data and passwords. However, we can say that the 16 characters limit was a decision by our engineers and all front end implementations are simply an extension of that decision. You can also use any letters, numbers and characters you wish and in any combinations. Please be assured in our 10+ years of operation, there has not been any security compromise on our client’s accounts. This may be one of the reasons why clients such as:
use our services.
Let’s extract what we’ve learnt from Namespro based on the conversation so far:
  • Passwords are stored within the server using a “server-side algorithm” that “encrypts the passwords” but for whatever reason the developers of the back-end saw it fit to limit user to a password length of anywhere between four and sixteen characters.
  • Namespro believes that giving any details about itself and its storing of passwords could lead to a potential compromise even though the choice of algorithm provided if done correctly would unlikely lead to it and if in the event there is a compromise that the knowledge of the password storage mechanism probably wouldn’t really matter anyway.
  • That its impeccable record of not getting breached and having clients like the RCMP being used to endorse their services should be enough to calm my fears.
Here’s my opinion on what I think based on the conversation thus far:
  • Passwords are limited from 4-16 characters either due to a limitation in their database, the cryptographic storage method used, or some sort of silliness in their code; whatever that may be.
  • They’re afraid to admit that they have inadequate password storage and would rather tell me to leave than to address the issue at hand. They hide behind the statement that informing me of their storage method would lead to compromise, but lots of organisations have informed their users in the past.
  • Namespro believes that they have “police-grade security” thanks to clients like the RCMP being in their list.
After having discussed further with Namespro, I got the following:
Thank you for your comments. We appreciate them and have forwarded them to our management team for review. However, at this time, we do not believe there is any further information we can provide. We fully understand some user’s concern about security and our response is again that we have never had a security incident with our accounts. Our goal is indeed to continue to strengthen our security as we go along but the manner and time frame on how this is achieved is the sole responsibility of our management team and engineering team.
Not having an incident ever does not excuse poor password management. Having an account with another registrar, I decided to ask them what they do to store passwords. Their response? While not ideal, they told me that they were using SHA256 with a per-user salt and no real limits on password length. This is far better than what I am getting from Namespro.

So I tossed this response back:
Please let your management know that I have spoken with another registrar that I conduct business with and they were more than happy to let me know how they store their passwords. If you’re concerned about sharing this information with the public then it is apparent that you do not have these details stored securely.
And got this back:
We regret to hear about your point of view, although drawing such conclusion about our password security is premature in our opinion. Again, password policy is not 100% based on security alone, there are other operation consideration. If you require any assist with domain transfers, we will be more than glad to assist. Once again, we apologize it does not work out, and are prepared to serve you again in the future if you change your decision. Have a nice day.
Needless to say, Namespro is telling me that they don’t care. If you’re a customer with Namespro: leave.


It was pointed out to me that I didn’t differentiate between them hashing or encrypting passwords. This was on purpose as I assume that based on their responses they’re not hashing at all but using some sort of two-way method.

Friday, 14 March 2014

Tracking users via wireless networking at BSides Vancouver

BSides Vancouver 2014 has come and gone and it went off really well. I gave a presentation on Canary and had a good time overall. One thing I did do this year was keep track of the users who were sitting in the presentation room using Wi-Fi and Bluetooth.

"Scroll of Sheep" was created based on the idea borrowed from DEFCON's very own Wall of Sheep, but instead of harvesting passwords and the like from Wi-Fi networks, it scanned for enabled Wi-Fi and Bluetooth devices within one section of the conference.

It would listen in on 100 packets via Wi-Fi and do a sweep via Bluetooth every three seconds and keep track of it via a SQL database. All that was stored was the device MAC, a time stamp, and an SSID if found.

Reception of it was well-received and now I have some statistics and other data to share!

Hardware and software

Some fairly off the shelf hardware was used:

  • Laptop computer

  • LCD monitior

  • Alfa-based USB Wi-Fi adapter

  • Yagi antenna mounted on camera tripod

In addition to the above, a standard point-of-sale receipt printer was added and connected via parallel cable. Inside of the printer it had about 70 metres of receipt paper. Each day, a new roll was added to allow for proper measuring of how much paper was used--more on this later.

Even Bobby Tables showed up

The software that powered it was mostly through the use of Airmon-ng with Scapy providing the interface. You may wish to check out the source code of the software I wrote as it also incorporated a web-based display for statistics in addition to printing the data on to a receipt printer.


Here are the requirements for how things were tracked:

  • New access points were added and then ignored for the rest of the day.

  • Probes from client devices were only counted as new if they had not shown up in the last five minutes.

  • Bluetooth devices fell into the same category.

It should be noted that not much in the way of Bluetooth data was acquired (we're talking less than a handful both days) so the data has since been discarded.

Most of the activity was really in the early part of the morning due to it being the start of the conference. As the days wore on, the number of new client devices continued to drop.

The above graph shows that while Apple devices were most popular, they were outnumbered overall. I was not keeping track of operating systems, but it was surprising to see Blackberry devices this high. With better OUI data, I am sure I could have gotten far better results.

Something that should be kept in mind is that while this antenna was aimed directly at the main conference hall, data from devices not belonging to conference goers was likely in the mix--attendance was no more than 200, but 330 devices were counted on average each day. Having said that, we did have command of the entirety of the hotel's conference space and it was likely that some people had more than one device. I'd wager that 80% of the data was likely the conference attendees.


As mentioned earlier, a receipt printer was used and each day it had available about 70 metres of paper. The idea behind the printer was borrowed from Chaos Computer Congress, where a receipt printer like the one I am using was used to print out tweets that discussed the conference.

While the "paper out" light was on, there was indeed paper inside. Nobody managed to get it to spit out control characters to make it cut the paper or go into a continuous spool--this was completely possible as I had not done any filtering via the interface. Bobby Tables made an appearance on here as well too.

My girlfriend was on hand on the second day and decided to figure out how much paper had been spat out. Her approach was to just outright measure it whereas mine was to figure it out by weighing what has been printed.

Her answer was that 25 metres had been printed on day 1, but did not measure for day 2 as it was still spooling.

However, weighing the paper proved to be problematic as while I do have a scale, it's meant to measure things in pounds and kilograms, and we're likely dealing with less than a pound here--a kitchen scale would work much better. But there was one way, determine how many lines were printed.

Here's what I figured out and what I already knew:

  • Day 1 had 143 access points, 6 Bluetooth devices, and 670 client entries.

  • Day 2 had 102 access points, 5 Bluetooth devices, and 711 client entries.

  • Two lines maximum for access points, three lines for clients and Bluetooth.

  • Five lines of space between each new entry.

What this means is that on day 1, 6,397 lines were spat out and on day 2, it was 6,442. At this point, I can measure the length of each line (4 mm) and then tell you that 25.59 metres of paper was used on the first day and then 25.77 on the second. Even if I had gone and kept a single roll, I would have not ran out. One interesting fact is that the fastest a garden snail has gone at is 0.0034 m/s, which means that the printer was spitting out paper at around a third faster than that.

I guess I should have ran with my girlfriend's answer all along as I had assumed more--something like 30 metres on each day.


Next year I plan to keep track of AP encryption and get the OUI data a bit more polished. It would be nice to know if those who are tethering at the conference are bothering to encrypt their links.

A little bit more about what else was found in the data set may be written later.