Jump to content


 


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.


Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.

Photo

"Coockies" Folder with PHP Scripts


  • Please log in to reply
35 replies to this topic

#1 dave1021

dave1021

  • Members
  • 25 posts
  • OFFLINE
  •  
  • Local time:01:38 AM

Posted 05 September 2013 - 02:03 AM

Hi, all,

 

Not sure where to ask, so if I'm in the wrong place, please point me in the right direction - I do some work with a local non-profit and it's come to our attention that our site is being flagged by Google for being "compromised." I ran the site through Google Webmaster (or whatever it's called - can't remember right now) and when I ran the "Fetch" command, saw evidence of a script that was mentioning "Viagra" and other "prescription" drugs - can't find evidence of that on the actual HTML pages, however. When looking at the site directory on the ISP site, I noticed a folder called "coockies" that had PHP scripts with names of our various webpages with a .php extension, as well as php scripts with names of "prescription" drugs. Has anyone else heard of this? I "googled" the term "coockie" and nothing came up. Our ISP tech contact was nice enough, but no help at all. I've manually deleted the "coockies" folder several times and it just keeps coming back. Any comments that could at least help me identify the source of this problem would be most welcome. Thanks!



BC AdBot (Login to Remove)

 


#2 groovicus

groovicus

  • Security Colleague
  • 9,963 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Centerville, SD
  • Local time:03:38 AM

Posted 05 September 2013 - 07:57 AM

Without actually seeing your codebase, it is hard to say. It could be anything from malicious javascript inserted on the page, to an exploit on the hardware. Impossible to say. Instead of deleting the folder. just delete the contents. See if the contents get restored. If they get restored, try recreating the files as blank text docouments (give them the same filename as the file you deleted).

 

 

Do you have a site url that I could take a look at?



#3 Grinler

Grinler

    Lawrence Abrams


  • Admin
  • 43,667 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:USA
  • Local time:04:38 AM

Posted 05 September 2013 - 09:56 AM

Is this a wordpress site? Sounds similar to some of the wordpress hacks I have seen in the past.

#4 dave1021

dave1021
  • Topic Starter

  • Members
  • 25 posts
  • OFFLINE
  •  
  • Local time:01:38 AM

Posted 05 September 2013 - 11:22 AM

Without actually seeing your codebase, it is hard to say. It could be anything from malicious javascript inserted on the page, to an exploit on the hardware. Impossible to say. Instead of deleting the folder. just delete the contents. See if the contents get restored. If they get restored, try recreating the files as blank text docouments (give them the same filename as the file you deleted).

 

 

Do you have a site url that I could take a look at?

Thank you so much for the offer to look - and for the tips you gave. The website is at www.bvhumane.org. If you notice anything that stands out, please let me know. Thanks again!



#5 dave1021

dave1021
  • Topic Starter

  • Members
  • 25 posts
  • OFFLINE
  •  
  • Local time:01:38 AM

Posted 05 September 2013 - 11:24 AM

Is this a wordpress site? Sounds similar to some of the wordpress hacks I have seen in the past.

It's so funny you mention Wordpress - it's NOT a Wordpress site - it's mostly an ancient HTML site, and the "tech" I discussed this with at our ISP made the same comment about Wordpress. And we've been thinking of switching to Wordpress (for ease of editing by non-tech types).



#6 Grinler

Grinler

    Lawrence Abrams


  • Admin
  • 43,667 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:USA
  • Local time:04:38 AM

Posted 05 September 2013 - 11:46 AM

Is it a pure html site? No programming languages (asp, php, etc).

If its pure html then either your ftp account was hacked or the server itself was hacked.

#7 groovicus

groovicus

  • Security Colleague
  • 9,963 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Centerville, SD
  • Local time:03:38 AM

Posted 05 September 2013 - 02:40 PM

If its pure html then either your ftp account was hacked or the server itself was hacked.

 

That is still what I am thinking. I looked at the source code coming across to the browser, and I do not see any javascript being loaded anywhere, which is usually what you see when something like wordpress has been compromised. Other than improperly formatted HTML, I didn't see anything anwhere that indicates any kind of compromised code at all.

 

Edit: The only javascript on the page is a simple snip to get the year.

 

EDIT2: After some more quick research, this could be an .htaccess exploit/hack. Do you have access to your .htaccess file on the server?

http://blog.aw-snap.info/2011/02/pharmacy-hack.html


Edited by groovicus, 05 September 2013 - 02:48 PM.


#8 Andrew

Andrew

    Bleepin' Night Watchman


  • Moderator
  • 8,260 posts
  • OFFLINE
  •  
  • Gender:Not Telling
  • Location:Right behind you
  • Local time:01:38 AM

Posted 05 September 2013 - 04:54 PM

Compromised code is only returned to clients that use a Googlebot user-agent string.

Here's what I get when I pretend to be Googlebot.

This is what Google sees when it requests your website.

 

I've seen something like this before and it indeed involved a compromised .htaccess file.



#9 groovicus

groovicus

  • Security Colleague
  • 9,963 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Centerville, SD
  • Local time:03:38 AM

Posted 05 September 2013 - 06:42 PM

That's sort of neat. Bad, but neat. I learned something new.

 

Back to the problem at hand, you are probably going to need to have your hosting provider take a look.



#10 Grinler

Grinler

    Lawrence Abrams


  • Admin
  • 43,667 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:USA
  • Local time:04:38 AM

Posted 05 September 2013 - 08:33 PM

Also check htaccess files or httpd.conf for the web site. Either way means the server was most likely compromised.

#11 ChelseaWoolf

ChelseaWoolf

  • Members
  • 58 posts
  • OFFLINE
  •  
  • Local time:01:38 AM

Posted 14 December 2013 - 11:58 PM

Now, how can we delete cookies through VB Scripting in QTP? This one is a very often repeated question on the testing tools forums. I will first provide a hint here.You need to write a custom function to do this. IMHO there is no direct way available.
Write a shell script to reach to the cookies file residing in your corresponding folder.
Delete all the files inside that folder.



#12 Guest_philsmith_dot_com_*

Guest_philsmith_dot_com_*

  • Guests
  • OFFLINE
  •  

Posted 13 January 2014 - 01:43 PM

Hi, all,

 

Not sure where to ask, so if I'm in the wrong place, please point me in the right direction - I do some work with a local non-profit and it's come to our attention that our site is being flagged by Google for being "compromised." I ran the site through Google Webmaster (or whatever it's called - can't remember right now) and when I ran the "Fetch" command, saw evidence of a script that was mentioning "Viagra" and other "prescription" drugs - can't find evidence of that on the actual HTML pages, however. When looking at the site directory on the ISP site, I noticed a folder called "coockies" that had PHP scripts with names of our various webpages with a .php extension, as well as php scripts with names of "prescription" drugs. Has anyone else heard of this? I "googled" the term "coockie" and nothing came up. Our ISP tech contact was nice enough, but no help at all. I've manually deleted the "coockies" folder several times and it just keeps coming back. Any comments that could at least help me identify the source of this problem would be most welcome. Thanks!

Hi!

 

I too run a non-profit web site with the same problem (although Google didn't inform me, I ran across the coockies folder myself - more on this later). I found you by googling "coockies".

 

I've been investigating. It's not easy, they are very clever and all I really have to go on are the httpd access logs. We have several domains hosted at the same site and as it turns out, they're using two of them to obscure what they're doing. I ran across this in one of the logs:

 

89.136.120.205 - - [13/Jan/2014:11:58:48 -0500] "POST //%63%67%69%2D%62%69%6E/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E HTTP/1.1" 404 666 "-" "-"
 

When urldecoded, the POST argument reads:

 

//cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 -d auto_prepend_file=php://input -n HTTP/1.1" 404 666 "-" "-"

 

And indeed, there was a /cgi-bin/php executable. The -d args override the php.ini settings and the auto_prepend_file=php://input causes the stream of POST data to be executed as PHP. Unfortunately, that stream was not logged. Note that this vulnerability only applies the the CGI PHP. mod_php (what apache does) does not have this vulnerability. Remove your CGI PHP file to remove this vulnerability. It may or may not be in the /cgi-bin directory. Look around.

 

89.136.120.205 is somewhere in Romania. I don't know if your hackers are the same as mine, but I believe they were using the CGI PHP to upload the directory coockies and included files. The files I have are base64 encoded, which is why Google didn't pick them up. So they must have been using some other script to base64 decode the files, rename them, and then - well, then what? I can't quite figure why they want to do this. My first thought was that they must be sending spam anonymously by sending from our domain. But we use authentication, so either they know one of our passwords or have found an account with no password. I'm still investigating, and haven't looked into that yet.

 

I'll post again when I have more information. One bit of advice, check your logs frequently for signs of abnormal activity. Also, don't have CGI PHP on your site at all, unless you need it, and if you must have it, use .htaccess to restrict access.

 

-Phil



#13 Andrew

Andrew

    Bleepin' Night Watchman


  • Moderator
  • 8,260 posts
  • OFFLINE
  •  
  • Gender:Not Telling
  • Location:Right behind you

Posted 13 January 2014 - 07:56 PM

The files I have are base64 encoded, which is why Google didn't pick them up. So they must have been using some other script to base64 decode the files, rename them, and then - well, then what?


Just a thought, but Base64-encoded files can be directly embedded in HTML, PHP (you can even directly include a base64 encoded PHP file), CSS, and probably many more common tools and languages.



#14 Guest_philsmith_dot_com_*

Guest_philsmith_dot_com_*

  • Guests
  • OFFLINE
  •  

Posted 13 January 2014 - 08:10 PM

 

The files I have are base64 encoded, which is why Google didn't pick them up. So they must have been using some other script to base64 decode the files, rename them, and then - well, then what?


Just a thought, but Base64-encoded files can be directly embedded in HTML, PHP (you can even directly include a base64 encoded PHP file), CSS, and probably many more common tools and languages.

 

Thanks, I'd forgotten. This could be very useful.



#15 Guest_philsmith_dot_com_*

Guest_philsmith_dot_com_*

  • Guests
  • OFFLINE
  •  

Posted 13 January 2014 - 08:18 PM

 

I'll post again when I have more information. One bit of advice, check your logs frequently for signs of abnormal activity. Also, don't have CGI PHP on your site at all, unless you need it, and if you must have it, use .htaccess to restrict access.

Okay, I have more information. The CGI PHP exploit was used to do two things: create a file called common.php and alter the .htaccess file so that search engine bots were directed to that file. Very clever, using the bots to execute their script. I'm looking at the file right now and it's pretty hard to decipher. I'll post again when I've figured out what it's doing. There's a lot of misdirection.

 

Dave1021, if you're still here, check for a file called common.php and delete it if you find it. Actually, that's optional, what you need to do is check your .htaccess file and if there's a rewriteCondition for the search engines which has a rewriteRule directing them to common.php, remove them.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users