While checking on the latest updates in the start-up world from TechCrunch, I came across their article on Mykonos; the important part of their article (at least for me), is this:
Mykonos’s Web Security product uses deception to “detect, confuse, slow down and prevent attackers” in real-time in order to help companies protect their websites and Web apps from malicious hacker and proactively prevent fraud and theft.
A couple of minutes of reading, and my interest was piqued – to say the least. The thing that most interested me was the claim of no false positives, while they do talk about it – I really wanted to see it for myself. Assuming they used their own product to protect their site, I took a few minutes to see what I could find – and find I did.
The first thing I did was a view-source to see what I could learn about their site – mainly to see if there were any obvious signs of using one CMS or another. The first thing that jumps out at me is this from the HTML:
<!-- InstanceBegin template="/Templates/mykonos.dwt.php"
codeOutsideHTMLIsLocked="false" -->
So, this tells us they are using Dreamweaver, and the name of the template. So, the next question is, does that /Templates/ directory exist on the server?
Yup.
So, not only does it exist, they have directory listings turned on – which to me was a real shock. Unfortunately for us though, these files are named with the .php extension and not the .dwt I was hoping for, so we can’t get much useful from them.
So, from looking at the source of the home page, we can see that the css files are stored in a /css/ directory – maybe that’ll be interesting.
It’s there, and like last time, we can see all of the files. While CSS files are of no real interest, the /_notes/ directory is, because it’ll contain a file called dwsync.xml - which can be quite interesting (since we knew they are using Dreamweaver, it’s not too surprising to see this). This file contains data about the last time the site was pushed from Dreamweaver, and will contain one entry per file, and looks like this:
<file name="style.css" server="ftp.belincreative.com/public_html/clients/mykonos/site/" local="129651858311162109" remote="129651936600000000"/>
The most interesting thing there is the server entry, as it tells us a little about the file-system; which if we were really trying to attack the site, knowing that would be handy. The other thing of interest is that when you see one /_notes/ directory, you’ll see lots more, as Dreamweaver likes to put them everywhere.
So, let’s see if there’s one in the root – that should be the most interesting one. Sure enough: /_notes/
This one has a few interesting entries, such as a PHP file that is named with an HTML extension – causing the code not to execute. Viewing the source of that file in the browser exposes the /inc/ directory; potentially interesting, but yields little information. The next file I tried (knowing it would be way too easy if it worked), was the .htaccess file:
<files "webadmin.pl"> AuthUserFile /usr/local/www/public_html/.htpasswd AuthType Basic AuthName "Server Administration" require valid-user </files>
Now, at first glance things look too good to be true – and that’s because they are. Look at the path in AuthUserFile and compare that to the entries from the dwsync.xml files. This .htaccess file is part of the trap, which is all but confirmed if you try to go to the .htpasswd file which shouldn’t work, since the path isn’t what we would expect.
Now, while mucking around looking at the aforementioned files, and others such as robots.txt, I would periodically see this, which I would assume is part of that “no false positive” promise:
I was hoping to run into the firewall (for lack of a better term) – looks like I got my wish; though since I wasn’t using anything automated and was just poking around by hand, it didn’t have any impact. Not terribly exciting, but it did provide some insight into what they are doing.
So far we’ve found a few interesting things, and bumped into their firewall, but that all pales in comparison to the last entry in the dwsync.xml file:
<file name="local-site.zip" server="ftp.belincreative.com/public_html/clients/mykonos/site/" local="129695851046591796" remote="129695888400000000"/>
When I saw the file name I was shocked – could it really be? But I was right. It’s a 59MB file containing everything on the site – all the PHP and everything else. Out of curiosity, I compared the .htaccess to that in the zip file, as expected it’s quite different and more believable:
Options +FollowSymlinks
RewriteEngine on
rewritecond %{http_host} ^mykonossoftware.com [nc]
rewriterule ^(.*)$ http://www.mykonossoftware.com/$1 [r=301,nc]
That confirms what I suspected, the file I saw earlier was just part of the trap.
So what have we learned?
1). Mykonos makes a really cool product, and had I not known what I was up against (and thus less skeptical about everything) it probably would have killed a lot of my time – just as intended.
2). No matter what you put in front or your site or application, human mistakes are still your greatest risk. A second set of eyes and a little paranoia go a long way in securing your systems, and stopping hackers.
3). Mykonos was either lucky or smart in that there was little on their site that shouldn’t be seen by the public. If they were using a CMS with a database back-end instead of simple (mostly-)static pages, this could have been worse. If they had source code or other valuable IP on the server, a mistake like this could be devastating.
4). Mykonos should take some of their new-found cash and hire somebody to finish the audit of their site that I started. 
Note: I notified Mykonos about that zip file before posting this (through a couple of channels), and I’m intentionally not linking to it. While I didn’t see anything in there that would be an issue to be publicly disclosed, I’m sure they don’t want it getting out. Hopefully by the time anybody reads this, they will have taken care of that file.
Update: As expect, they’ve cleaned up the files I mentioned – and a bit more. In a tweet from the company’s CEO, David Koretz, he mentioned that they had left a surprise for me. So I went to my starting point (the /Templates/ directory), and was greeted with this:
Yeah, cool product and cool people. I’m impressed.
While testing ccsrch I noticed a number that looked familiar – my debit card number. Now, being just a little paranoid, I don’t leave such information on my system unencrypted – so seeing it was a real surprise. But, here’s the real kicker: it was on my work PC, where it never should have been. But there it was, plain as day, in clear text. I spent a couple of minutes staring at the log trying to figure out why it would be there.
Once I saw the file name, a sinking feeling set in and the answer became clear:
%LocalAppData%\Google\
So it turns out that it’s Chrome’s sync feature that was saving my information, but why?
It turns out that auto-fill data is synced with your Google account (if you’re signed in and have the feature enable, of course), and all of the computers you’re signed into – and by default, without the benefit of encryption. This file may contain any number of things, from mine I was able to extract the following:
- Full name
- Wife’s full name
- Date of birth
- Wife’s date of birth
- Social Security Number
- Multiple credit card numbers
- Multiple CVVs
- Bank account & routing number
Not to mention quite a few websites I’ve been to, various addresses, employer’s name and other various useful tidbits. All would be quite useful for identity theft or highly targeted spear phishing.
Now am I saying that syncing auto-fill is bad? No, not at all. It’s a very useful time saver, but what takes it from a useful feature to security issue is the fact that by default, this data isn’t encrypted!
What are the risks?
There are three significant risks I see here:
1). Disclosure to less trusted systems:
In my case, I trust my laptop to be secure; between full-disk encryption (via TrueCrypt) and other precautions, I know that I don’t have too much to worry about. On the other hard, my Work PC is on a corporate domain, and at least a couple dozen people have permissions sufficient to access my personal files – thus I don’t trust anything too valuable on it.
Now because of the fact that this feature is insecure by default, that data is exposed to a less trusted system.
It can also go the other way: a number of auto-fill entries on my personal laptop were from forms on internal-only applications that only my Work PC would be able to access. So this means that anything sensitive could be leaked to home networks which are typically less secure than corporate environments. If you routinely handle PCI, HIPAA, or other restricted information – this type of leak could be a major issue.
2). Spear Phishing:
Let’s imagine a scenario:
You work for a defense contractor and I work for a foreign intelligence agency. Through some targeted attacks I manage to penetrate your home network, but have been unable to make it into your corporate network. I grab the sync database file from your home PC and extract one of your credit card numbers. I look up the IIN and find out what bank the card is from. Once I have this, I build a PDF with the latest 0day exploit, and send it with a convincing subject line:
“Important Information about your Bank of America credit card ending in 7850″
Normally you’d dismiss it as spam, but the last four digits are right – so you open it, just in case. The exploit kicks in. I’m in, you’re done.
This is just a simple and quite contrived example, but you get the idea.
3). Google Data Mining:
This is the most paranoid and least likely, but given Google’s issues in controlling their people – I’d say not impossible (see here, here, and here).
Just for a moment, think about the fact that Google has the following:
- Your account data (name, email, etc.)
- Your auto-fill history (see the list of items I found above)
- Tons of data from their other services
- At least parts of your browsing history, if not much of it
- Engineers that truly enjoy data mining
Most other companies I wouldn’t worry about; but knowing the people that Google hires, and the skill they have in manipulating data – you know that some engineer is using his 20% time to do this (or at least is wishing he could).
If nothing else, I know if I worked at Google – playing with this data would be tons of fun.
Want to see your data?
To see what Chrome has saved about you, download SQLite Browser, and open the file I mentioned above. Go to the “Browse Data” tab, and select the “metas” table. What you’re looking for is in the “non_unique_name” column (among other places). You should see something like this:
The entries starting with “autofill_entry” are the ones you are interested in, but you’ll likely find some of the other records interesting as well. If you see the word “encrypted” then your data is already encrypted, and you don’t have to worry about this.
Is this a vulnerability in Chrome?
No, not at all – though it was a mistake. They should encrypt everything by default, and not provide an option to do otherwise. There’s no reason to expose users to a potential security risk when there’s a simple fix. Security isn’t something users should have to opt-in to; and unless there’s a very good reason, they shouldn’t have a way to opt-out.
Google should understand security and the value of the data they hold; they should be more responsible for the data (and faith) people give them.
How do I fix it?
Simple, from the “wrench” menu, select Options -> Personal Stuff -> Sign In -> Advanced… and then under “Encrypted data types” select “Encrypt all synced data” – and that’s it. After a couple of minutes the entries that were visible before will now just display the word “encrypted.”
You can also go a step further, and get rid of this data by disabling auto-fill to ensure that potentially sensitive information isn’t being persisted when it shouldn’t be.
During my employers annual PCI audit, our auditor requested that we perform a search of all of our servers for credit card data. He recommended a tool called “ccsrch” – which like many open source projects had a couple of issues, and hadn’t been updated in years. So, I fixed it.
CCSRCH is a cross-platform, command-line application that reads every file from the starting point passed in, and scans them for what looks like credit card numbers (and using the Luhn algorithm to check each possible result). It’s fairly brute-force, but it gets the scans required for PCI – though I would be careful about using it during production hours, it can have a pretty significant impact on a server’s I/O performance.
I’ve forked the application and setup a new ccsrch project over at github (the original is on SourceForge), and made a few modifications to better suit my needs (from the change log):
- Added option to output the file name, and how many hits were found to the console when using -o (see -c in usage).
- Added option to limit the number of results from a single file before going on to the next file (see -l in usage).
- Added option to exclude certain file types from the scan (see -n in usage).
- Fix for ignoring NULL, CR & LF.
- Ignore dash when scanning.
- Exclude results with the last 8 digits repeating (very unlikely to be a real PAN).
I’ve uploaded a Windows build of the new 1.0.5 release to github, and for *nix systems, you can just download the latest tag.
SOPA, while it’s not likely to be passed as-is, I would be willing to bet money that something SOPA-like will be passed. It may be watered down with many of the most offending parts removed, but for those backing SOPA it’ll still be a real victory. For them getting it on the books, even in a weakened form means it can be tweaked (and extended) later.
There’s been an amazing resistance to SOPA, from the boycott of GoDaddy to public statements from celebrities such as Adam Savage – the public outcry against this horrid piece of legislation has been quite inspiring. But how often will you be able to get so many people to stand up and take action before they start to lose interest? How many times can you raise the troops before the numbers start to dwindle; how long before the celebrities start fearing they’ll be branded in the media as extremist or crazy? How many times can you raise the call of breaking the internet and freedom of speech before the public gets bored and goes to read about the latest Hollywood divorce instead?
Here’s how I see it going:
- Strip many of the worst parts of SOPA and get it through congress. By removing these offending pieces, those backing SOPA will try to make themselves look responsive to the community, and it’ll be played as a victory for the community in the media. All in all, if you aren’t paying attention it’ll look like a victory for the people.
- Next year, introduce a bill to modify SOPA to change the wording here are there, edging it just a little closer to the original. If done carefully, it’ll be easy to dismiss those that try to stir up another outcry as over-reacting or even paranoid.
- In a few years after a series of modifications, we have SOPA, just as broad and dangerous as originally intended – and the vast majority of people who fought SOPA would have no idea.
If you have a financial motivation to get something like this passed, they key to success would be patience. Chip away slowly at DMCA Safe Harbor protections, at what requires a judge instead of an administrative action, at transparency so that any action ends up happening behind closed doors. In enough time you’ve established a law that gives the US Federal Government a massive amount of control of the internet, without oversight – all in a way designed to get offending web sites off the internet as quickly as possible. To say it would be ripe for abuse would be a massive understatement.
Am I being paranoid? I honestly hope so – I really hope that there aren’t people out there looking to limit the freedoms we cherish for their own profit, but the fact that SOPA was introduced in the first place makes that hard to believe.
PCI DSS, the security standard for companies that handle credit cards, defines a number of rules as to how credit cards are handled. One of those rules, 3.3, is defined as follows:
Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed)
So based on this requirement I assumed that the code to do this would be common and widely available; much to my surprise there are rather few samples that do this, and of those I found they only showed the last four (which when you are handling a lot of credit cards, searching for an account by the last four isn’t all that helpful) and were often rather fragile.
So I whipped this up, hopefully it’ll be useful to others.
public static string MaskCreditCard(string value){ const string PATTERN = @"\b(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|" + @"6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|" + @"[68][0-9])[0-9]{11}|(?:2131|1800|35\d{3})\d{11})\b"; var replace = Regex.Replace(value, PATTERN, new MatchEvaluator(match => { var num = match.ToString(); return num.Substring(0, 6) + new string('*', num.Length - 10) + num.Substring(num.Length - 4); })); return replace;}The regex pattern is from Regular-Expressions.info and should detect most major cards.
I was recently given the task of ensuring that a Silverlight+RIA application that could contain private information was secure for deployment to a public web site. So I started searching for automated pen-testing tools that could work against Microsoft’s Binary SOAP protocol (msbin1, a.k.a “application/soap+msbin1“) and found only disappointment. For various reasons, it’s significantly more complex to pen-test a application using msbin1 than traditional SOAP + WSDL.
To properly test the services, I had to make a compromise: temporarily modify the application to expose a SOAP endpoint. While this changes the state of the application and thus reduces the validity of the tests, it does provide a reasonable way of testing the web services to ensure that they are behaving as intended.
The recently released SoapUI Pro 4 adds new security testing tools that makes this a viable (and attractive option). To get this working, there are a few small changes that need to be made to the solution:
First, you’ll need to add a reference to “Microsoft.ServiceModel.DomainServices.Hosting.EndPoints” which is part of the RIA Services Toolkit; this allows you to expose different End Points for the service such as SOAP and OData.
Next, you’ll want to add the following configSections entry to your Web.config:
<configuration>
<configSections>
<sectionGroup name="system.serviceModel">
<section name="domainServices"
type="System.ServiceModel.DomainServices.Hosting.DomainServicesSection,
System.ServiceModel.DomainServices.Hosting,
Version=4.0.0.0,
Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />
</sectionGroup>
</configSections>
...
Finally, to expose the SOAP end point:
<configuration>
...
<system.serviceModel>
...
<domainServices>
<endpoints>
<add name="Soap"
type="Microsoft.ServiceModel.DomainServices.Hosting.SoapXmlEndpointFactory,
Microsoft.ServiceModel.DomainServices.Hosting,
Version=4.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</endpoints>
</domainServices>
...
Finally, just follow the instructions for SoapUI to setup your tests, and you can feel (just a little) more confident in your application. Passing with flying colors obviously doesn’t mean your application is bulletproof, but it helps to confirm that web service code is solid.
Now, while this does provide some insight into your application and should help find common issues, it’s not a replacement for a professional assessment by a qualified auditor. If you are handling credit cards or other highly targeted information, please consult a security specialist before a public deployment.
