Geek Life....
photography, programming, site design, networking, computers, linux, windows, mac os x, application reviews...
May
14
Why the FTC need to raise the bar on their hiring standards.
bandwagon, complaint, dropbox, encryption, ftc, hbgary, privacy, Security, wired
Wired recently published an article on a new FTC complaint filed by Christopher Soghoian. Soghoian is a PHD as well as having been the first real cyber-ninja to be employed by the FTC’s Division of Privacy and Identity Protection. That being said, it discourages me that the information presented was at such a low level of expertise.
After reading through the Wired article and following up with the link to Soghoian’s blog post; I’ve come to only one surprising conclusion. It takes a few years and a PHD to figure out that Dropbox isn’t secure???
Over two years ago I spent 5 minutes evaluating Dropbox as a solution to a small client’s backup problem. I had quickly knocked Dropbox off the list due to two defining facts.
1) Dropbox is not Pro grade for business. It’s consumer-grade, targeted towards the same user base that upload drunk photos of themselves to Facebook then cry about privacy. There are plenty of other services that offered business grade services. (i.e. Jungledisk.)
2) Dropbox’s ‘share’ feature meant that the company’s claim of being secure had to be completely false. If Dropbox has the ability to allow a completely unrelated user access to my files, then they obviously have the encryption keys.
No PHD, no affiliation with a national commission. This isn’t rocket science. I don’t like the fact that Dropbox isn’t holding true to their claims but if you’re going to fight them over it, please do a little better than flashing your badge and offering zero data to support your findings.
Soghoian’s claim seems to revolve around one interesting fact. Fellow FTC cyber warrior Ashkan Soltani, “was able to verify”, that uploading the same file to two accounts results in the second copy taking up considerably less bandwidth and time to upload. He states that this took only a few minutes with a packet sniffer to determine that a 6.4MB file used only 16k of network traffic to upload to the second account after being uploaded to the first.
Why was a packet sniffer used? Why wouldn’t you simply upload a 10MB file (even number) and see if the second upload completes almost instantly. This is rather unscientific but the test is only a couple of minutes and will easily confirm the theory right then and there. What was in the 16k of traffic? A scientific mind would want to know. Why was it a 6.4MB file? Sounds like it was a file just sitting on the desktop and thrown into a ‘scientific’ test environment in which zero controls were put in place. Where is the data collected? If you go all out and test with a packet sniffer you could at least present the captured data without any filters applied. This way we can make our own conclusions.
With Soghoian’s level of expertise then, It’s no surprise that he suggests that law enforcement or copyright ‘trolls’ could upload sample files and based on the short-upload time, determine whether someone on Dropbox has the files. It does not occur to him that despite being a nice idea and all, that it is negated by simply adding or modifying any part of a file, or that several variation of each file are available across various areas of the Interwebs. Law enforcement or copyright ‘trolls’ (I hate that term) only require filenames and a court order to have Dropbox hand over a list of users with the file.
Perhaps one of the worst parts of Soghoian’s blog post is where he states that, “Dropbox is likely calculating hashes of users’ files before they are transmitted to the company’s servers.”
If you are making an assumption and stating that something is ‘likely’ to be the case, it would be nice to at least verify your claim. A simple test of this theory would be to drop a 500MB file into Dropbox and watch the network for activity. If the Dropbox client software is computing hashes before sending the data to Dropbox then it should take a few seconds at least to compute a hash for a 500MB file. My own test proved this to be false… the 500MB file started uploading instantly after being dropped into the folder. Hashing is not performed on the client side.
In closing, I’m not defending Dropbox at all; I’m simply annoyed that I see incompetence at all levels. Recently during the whole HBGary incident, it became apparent to me that even in support structures for Government and big banks, idiots seem to hold key positions. This scares me.
Apr
04
During two of my recent projects I’ve had to generate on-the-fly PDF’s. In the past I’ve used a few HTML->PDF tools and found that support for modern HTML is rather limited.
This newer tool is Linux based but can be used via the PHP Exec functionality to achieve full integration. The best part of it is that it is WEBKIT based, and almost every page I’ve thrown at it seems to have rendered perfectly in the PDF page :)
wkhtmltopdf.
From the site:
Simple shell utility to convert html to pdf using the webkit rendering engine, and qt.
Apr
04
I recently just completed the migration of our hosting infrastructure to the cloud. This project was a roller-coaster with typical hurdles as is found in the wild. I decided to write about this project but with only basic details instead of the step-by-step of how and when to do things. I simply don’t have time for such an endeavor.
The original fiber-fed network had four linux based servers. Two dedicated name servers and two web servers. Problems with network design/implementation, and poorly configured servers led to the need to move to the cloud or rebuild everything from scratch. We decided on a VPS hosted at 151Front.
The web servers were VHCS2 based. This is an older web-hosting control panel which, in its day was quite capable. Today though, it is a widely exploitable invitation to lose one’s business. The VHCS project ended ages ago and no security patches have been issued in months. To add to this, the boxes were not hardened in the least, even SSH allowed root to log on remotely!!! (argh!)
My first objective during my first month or two was to stabilize the web servers. Configured logging for apache/mysql/and various services, log rotation, ntpd, set up a proper back up script etc etc. Basically extended the robustness of what we had long enough to make things a little easier till we migrate.
The target VPS is WHM-cPanel based. There are no automated tools for migrating from VHCS, so everything needed to be done by hand. This is where a good solid understanding of Linux and operating systems in general really helped.
My first milestone was an easy but extensive one. I gathered all configuration details such as httpd configs, dns zones, mailboxes, aliases, filters etc, etc. Once collected from the four servers, I was able to correlate data in Excel in order to get the big picture of the hosting environment (and the mess!). This allowed me to gain insight as to just how large this project would end up being. It also allowed me to provide a list to management in order for them to define what hosting was actually still relevant and what had expired long ago… seems that the previous admin never found the Delete key.
Once I had proper documentation of what we have currently, without all of the expired accounts etc, I considered this my second milestone being reached. This allowed me to start setting up the accounts on the new server. Once the accounts were set up, it was time to get really dirty and start writing code to create mailboxes, filters, dns zones etc etc etc. This was a long haul but completed with relative ease. The hardest part was keeping track of everything.
With the VPS now configured to support what we have, it was time to actually move data into place. We chose not to migrate email to the new box, as most users were originally set up with POP3 access and of course, no one ever turned off Outlook’s “leave a copy on the server forever!” checkbox. I still had to pull over all of the web sites, FTP data etc etc. Easy peasy, this milestone was a no-brainer!
Perhaps the hardest part of the migration project was testing. The server was operating properly, and the accounts were perfect. What wasn’t perfect (to say the least) was the web site coding. Many of the sites required fixes to operate under PHP5, this was pretty tough. On a good note though I did get them ALL working after lots of blood and sweat. There were two exceptions to this, it seems the person whom designed the network (and quit after I started asking why things were the way they were) decided that he would remove all newline characters from the two websites that he had built. The files were all tampered with the same day I got the root password to the server… really sank my heart when I found this. I was able to locate parts of the code in which the lack of newline chars and javascript/php comments broke the sites and brought the sites up in a functional but having partially broken layouts. This is the best I can do with these two sites until I get a chance to finish my current development projects and loop around to pick up the pieces.
Fun times. More on this stuff later (if I get a chance.) Sorry I left out the bulk of the details, I intended only to hint at what is all involved and perhaps map it all out in the future.
kc/
Apr
03
My old boss pointed out to me a long time ago, that VI was something I should really get down and dirty with. I was an EMACS user at that time and I really had no interest in learning something new when I had lots of work piling up already.
That being said though, he added a very good point. VI is on all Linux distributions by default and being proficient with it means I can sit at pretty much any terminal and get the job done.
And so I learned VI.
Recently I’ve noticed a new fad evolving around the Interwebs. It would seem that pimping out VIM with plug-ins is the latest trend for aspiring developers whom believe the tools and add-ons they use make them more elite than those whom do not. But while some do argue what editor is best, I’m getting work done in trusty old VI. Could you imagine having to explain to a new boss or client that you can’t do work on their machines until you download and install a hoard of plug-ins? Could you imagine a junior employee fumbling with installing things on to a production machine?
There are many full-fledged IDE packages for your workstation available these days, which allow for live editing of files across ftp, ssh and the likes. This way you can have all of your toys installed there and not have to worry about tainting your clients servers :)
:wq
