When [Steve] received a notice from Google that a new owner had been added to his Google Search Console account, he knew something was wrong. He hadn’t added anyone to his account. At first he thought it might be a clever phishing tactic. Maybe the email was trying to get him to click a malicious link. Upon further investigation, he discovered that it was legitimate. Some strange email address had been added to his account. How did this happen?
When you want to add a website to Google’s services, they require that you prove that you own the actual website as a security precaution. One method to provide proof is by uploading or creating an HTML file to your website with some specific text inside. In this case, the file needed to be called “google1a74e5bf969ded17.html” and it needed to contain the string “google-site-verification: googlea174e5bf969ded17.html”.
[Steve] logged into his web server and looked in the website directory but he couldn’t find the verification file. Out of curiosity, he tried visiting the web page anyways and was surprised to find that it worked. After some experimentation, [Steve] learned that if he tried to load any web page that looked like “googleNNNNNNN.html”, he would be presented with the corresponding verification code of “google-site-verification: googleNNNNNNNN.html”. Something was automatically generating these pages.
After further investigation, [Steve] found that some malicious PHP code had been added to his website’s index.php page. Unfortunately the code was obfuscated, so he couldn’t determine exactly what was happening. After removing the new code from the index.php file, [Steve] was able to remove the hacker’s email address from [Steve’s] Google account.
This is a very interesting hack, because not only did it allow this one hacker to add himself to [Steve’s] Google account, but it would also have allowed anyone else to do the same thing. This is because each new hacker would have been able to fool Google’s servers into thinking that they had uploaded the verification file thanks to the malicious PHP code. It makes us think that perhaps Google’s verification system should use a separate randomized string inside of the verification file. Perhaps one that can’t be guessed or calculated based on known variables such as the file name.
The real question should be: ‘How was the user able to upload or modify code on the website?’
Yes Google’s site verification system could use an update and be more secure, but it would not have been possible if [Steve]’s site were properly secured.
Whenever I hear php, I instantly think “security flaw”.
http://www.cvedetails.com/vulnerability-list/vendor_id-74/product_id-128/PHP-PHP.html
But when compared to Adobe Flash it is so much more secure, look at all those 10.0 – perfect failure at security, almost as if by design.
http://www.cvedetails.com/vulnerability-list/vendor_id-53/product_id-6761/Adobe-Flash-Player.html
“It’s not as bad as Flash”
“He’s not as bad as Hitler”
There’s a lot of wiggle room there.
http://www.telegraph.co.uk/technology/news/6408927/Internet-rules-and-laws-the-top-10-from-Godwin-to-Poe.html
For everyone that thinks php is a good language: http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ . I know, I’ve made pages and apps in it for several years.
My favorite part of this article is the way whenever it comes up on a programmer forum or whatever, PHP people fall over themselves to attack individual points, totally missing the point of the toolkit analogy at the beginning. 75% of the pro-PHP comments on the article itself are reworded versions of arguments countered in the second damn section.
There’s no excuse for PHP. Having >10-years of development in the language, I understand fully why it’s so broken, and agree with the article.
The one counter-argument I have for the toolkit analogy is the following:
Most carpenters, when faced with such an odd assortment of not-quite-tools, would immediately use them to build a proper set of normal tools to make their lives easier going forward.
Indeed, my first act was to build a common set of libraries for my projects that presented a nice, sane, OO system for everything, leaving the weird busted tools at the bottom of the toolbox, only to be used if there’s no other choice.
Yes, PHP is busted. There’s likely no fixing it, unless they were to drop backwards-compatibility entirely. Yes I feel dirty for defending it sometimes. My reasoning for continued use is that you’re not likely to find a language that is as widely supported on inexpensive shared hosting environments.
Finally, after >10 years, I’m shifting my career to focus on Node.js which is not free from criticism, but I consider it a huge step up.
Quote: “Most carpenters, when faced with such an odd assortment of not-quite-tools, would immediately use them to build a proper set of normal tools to make their lives easier going forward”
And that is exactly what an experienced php programmer does. Build an abstraction that makes sense. All of the common platforms for php are like this to some degree. Or just use a platform that someone else has written.
I’m not defending php. It is what it is. A beginner has no hope of putting something together that is secure. Even some well established platforms based on php have truck sized security holes.
Php looks like and feels like a beginners language but it’s diversity of keywords creates complexity and it takes a long time to understand all the implications of that complexity.
From the article you link to:
” PHP is a community of amateurs. Very few people designing it, working on it, or writing code in it seem to know what they’re doing.”
That is exactly the reason why I stopped using PHP, why I refuse to do much of anything with PHP, and will ask for additional monies if the job involves PHP unless it’s porting the code to a better language.
Whenever I hear “php security flaw” I reflect on the poor quality of many php developers. Granted the language has a lot of legacy functions you’re best advised to avoid, but a secure php app isn’t all that hard these days if you know what you’re doing.
That can be said for ALL languages.
PHP is unusual in the sense in that the developers have quite literally gone out of their way to make, “know what you’re doing,” an overly difficult process by taking the language in different directions on an irregular basis. This isn’t like Brainfuck but more like INTERCAL. Actually, I’m probably wrong about the INTERCAL thing, INTERCAL is a bit more predictable.
As a developer do you really want to expend valuable memory cells on the expansive bullshit that is PHP, or cut straight to the problem you’re trying to solve using nearly any other language?
If you had read his blog he mentions that they logged into his server with his password…. so they found that out somehow. the file was modified about a minute after the suspicious login….
Hence why I suggested that is was a security issue….rather than focusing on how Google’s verification system is antiquated.
If he had better security….it would never would have happened.
I found the vulnerability on his website. It goes by the name “WordPress”
Ha! They always give them compound names like heartbleed, and shellshock. WordPress fits the pattern perfectly.
Yawn. Some guy found his PHP/WordPress web site had been compromised. News at 11.
“This is because each new hacker would have been able to fool Google’s servers into thinking that they had uploaded the verification file thanks to the malicious PHP code. It makes us think that perhaps Google’s verification system should use a separate randomized string inside of the verification file. Perhaps one that can’t be guessed or calculated based on known variables such as the file name.”
Uh no. It is already game over if somebody has managed to alter your site code. There is nothing to stop the attacker from adding code that generates the verification files directly. Adding randomized junk inside the file doesn’t make it more secure.
This is exactly what I was coming here to say.
How could the code the malicious code generate the same randomized code as Google?
It would work in the same way that a human would verify access. The way it currently works is that the Google Dashboard before adding your account as a verified user is that it’ll generate a random verification code that you either insert into a file with same code as its name or you add it as a HTML tag in the header somewhere.
The attacker made modifications to BMoW website so that any attempt to access any file that was called google.html would return those same hex digits as the contents. The HaD article seems to think that having 1 random code for the filename and 1 random code for the contents would make it significantly more secure. It wouldn’t however since the attacker could just upload both randomised verification codes to the site. They already have full access to the website since they’re able to change the site code. The only benefit of doing the suggested HaD change is that it would require slightly more effort by the attacker since it won’t automatically allow anybody to connect the site to their Google dashboard.
Oops. Sorry. Didn’t mean to reply to your comment. What you said is completely valid. Yet another WordPress break in. *yawn*
One thing I should not do is my daily look at my servers’ access_logs. The sheer number of wordpress-vulnerability checks are overwhelming. Now, if each wordpress problem would lead to a security breach elsewhere, shutting off the internet might in fact be the best idea since putting butter on both sides of the toast to trick Murphy.
sorry, plural/singular mistake. Make that “numbers” or make that “is overwhelming” … it’s too hot around here.
Cant fool murphy. It WILL fall butter side down based on the inverse square of ghe need.
It’s a shame there’s not interesting tricks going on here. Why did they encode it repeatedly, what purpose did it serve?
No real reason to encode it beyond the first step. That first step is just obscuring it for very casual inspection anyway. The most likely reason is that it was been done like that multiple times because its been passed through a chain of people who each felt the need to obscure the origins and pretend it is a brand new tool. Vast majority of attackers who use these scripts have no idea how to write them themselves.
“Script Kiddies”, as we used to call them. Is that still a word?
yes I find my self using it daily
As usual people clean up the files they see are changed, as opposed to nuke the machine and import a backup.
It’s a web store, it will receive private data from users, heck it will receive money from users, it is also now running on a machine that was compromised, using an unknown method, affecting who knows what other files apart from the site itself.
This amount of negligence should carry prison sentences, and costumers should sue the company for the breach of data in the database (what you think someone just changed a few files and not got a copy of the DB?), the company should also be responsible for the costs of identity theft protection and credit protection for everyone in the DB, it’s the only way companies will start to take it seriously.
Instead of a serious note about the breach, we get a casual blog about how he “cleaned” the site
Ok and what about if the problem came form something like WordPress and some one got in to my system because of it and got your identity. Is it my fault or the WordPress?
Do you have all the software updated? Did you actually hire someone with actual development and security experience to make the site or just a “web design” firm that used designers to setup the site instead of actual tech people? If you hired a professional team and they screwed up, you should have a contract in which they assume at least part if not all of the blame, depending on the circumstances of the hack, if you just got free software from the internet and got John “once formated a pc” Doe to setup your server, them you get all the responsibility.
Isn’t it a little weird that the name of the file that Google requires is the same as the magic string inside of it? It makes the magic string inside of it entirely redundant and useless. (“Hey, do you have KEY.HTML?” “Yup, sure do, see, it says right here that it’s KEY.HTML”)
Well, the file name starts with google1a7 and the text starts with googlea17. Pretty sure that’s a typo though…
No. There is a reason for it. You can’t just check for the existence of the magic filename. There are loads of sites out there with broken 404 redirections that don’t actually send the correct status code. They just redirect you automatically with a 200 status code to somewhere like the main page. If the Google verification bot didn’t check the contents then anybody would be able to attach those sites to their account.
Just out of curiosity, did this guy have an automatic redirect to index.php (or rather the web root) or did the hacker add an .htaccess file with an appropriate Apache rewrite rule to handle these Google verification file names? If the former, then he was probably targeted specifically for this redirect configuration, if the latter, then he needs to be really careful about scouring every file in his website (and the system as a whole, including databases) for other modifications (not that he shouldn’t already do that or scrap it and start from scratch).
WordPress has that as part of the standard setup. If mod_rewrite is available then it’ll do the redirect. It is so you get nicer looking URLs and for SEO reasons.
Ahh, ok. So this is just another one of those easy WP hacks.
I know I’m late (got a job, finally) but…
Why are password logins even enabled on the server in the first place?
Creating a backdoor by blowing a giant hole in the rear, the NSA would be proud
Flash isn’t a CGI language.. PHP is.. What’s with these retarded comparisons by all these security and engineering experts who obviously make stuff like this guy was using?
PHP is no more insecure than Perl or Python or RubyOnRails or ASP or JSP. Maybe not as optimized though. Anyone who suggests it has more buffer overflows or XSS or CSRF flaws should be asking for security info rather than giving it.. SQL flaws are the faults of coders and DB engineers, PDO actually does a pretty good job wiping butts of lazy web devs which seem to be getting a lot of work these days..
This guy was probably like most ‘experts’ and running default configurations or un-patched CMS.. The code was probably obfuscated with the anti-amateur obsuscators like ioncube..
My basic statement is that fine grained vuln. statistics and comparisons are for people who know sh**t about security.. To even get the comparative statements wrong is even more sad..
So if you want to look at the obfuscated code, there’s http://www.unphp.net/ for example.