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.
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.
Earlier today, the hacker collective Lulz Security released a batch of 62,156 email/password combinations from unknown sites; I decided to take a look at the data and see if there was anything to be learned from it.
@LulzSec
The Lulz BoatAnd as always, LulzSec delivers: http://t.co/yQlcu5x 62,000+ emails/passwords just for you. Enjoy.
FavoriteRetweet
So, let’s take a look at a few stats:
Total Domains: ~5,230
Top 15 Domains:
There are over 50,000 unique passwords, but even with this many passwords, there’s still a few quite common – and very bad passwords in use:
While this is a fairly small release, the LulzSec twitter stream has a number of entries like these:
http://twitter.com/#!/Murraaayyy/status/81483793927643137
@LulzSec
The Lulz BoatThere is some very angry level 85 WoW player cutting his wrists right now, thanks to @MiracleJoe and LulzSec. Let it flow…
FavoriteRetweet
There are several tweets about people accessing Facebook, Twitter, and even Amazon accounts – what’s so unfortunate here is that service providers could easily restrict accounts on lists like this to protect the users and greatly reduce the impact of these breaches.
Until people learn that password reuse is dangerous, this will keep happening.
Ralph Langner recently spoke at TED about his team’s findings on Stuxnet; it’s a clear (and somewhat scary) insight into the wars of the future. Instead of sending fighters and bombers to take out Iran’s nuclear program, as was done in 1981 to eliminate Iraq’s program, a carefully crafted virus slowly and methodologically damaged or destroyed vital equipment.
How long until this is used as a standard part of ‘softening’ a target by taking out key infrastructure (flight systems, power plants, telephone & internet, etc.) before the bombs start to fly?
For those of us that have a professional interest in security, understanding the threats both present and future is simply a necessity.
This is a must watch.
Update: If you want to dig into some technical detail, Mark Russinovich has a good write-up on it.
