Forum Moderators: open

Message Too Old, No Replies

adminer crack script

         

csdude55

8:50 pm on Oct 10, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



I recently had a major issue come my way, so I wanted to alert others.

I have a Perl script on my site that allows users to upload photos. The process sends the photos to a /cache/ directory. I wrote it about 7 years ago and thought it was tightly written, but a few days ago I had a cracker upload 8 scripts that were titled something like:

adminer-4.2.3.jpg.php

That's when I discovered a seemingly minor oversight in my script. I was checking that they had uploaded an image using:

if ($picID !~ /\.(jpg|jpeg|bmp|png)/i) {
[show error];
exit;
}

Obvious to the experienced coder... I left off the $ at the end of the pattern, so I was just checking that it contained .jpg or whatever, not that it ended with it.

This back door gave them access to all of my PHP scripts, MySQL, and God-only-knows what else. In MySQL, I found that several entries had been modified to include an Adsense code, obviously trying to divert my Adsense earnings to their account instead of mine :-O

Now I get to some questions.

I found these in my /cache/ directory:

.htaccess

Options +ExecCGI
AddHandler cgi-script .b'aqb'


php.ini

disbale_functions=none


error_log

I'm pretty sure that I can safely delete these, unless you guys and gals think they may have modified something else that now relies on them?

These are my bigger concern:

/bt/
/BT/

In /bt/ is an .htaccess file:

 Options all 
DirectoryIndex Sux.html
AddType text/plain .php
AddHandler server-parsed .php
AddType text/plain .html
AddHandler txt .html
Require None
Satisfy Any

and a symlink to /root/. When FTPed in to the account I can follow that symlink, but when I try to read anything it says "permission denied". So I THINK it's OK? The only files at /root/ that have been modified since this upload are aquota.group, aquota.user, quota.group (all with filesize of 0) and quota.user.

The /BT/ directory has the same .htaccess file, but it has 514 symlinks to other accounts on the server (located at /home/[account]/) and what appear to be attempts to read files. For example, there are 5 sets of symlinks for about 100 files, each ending with the following:

.. wp-config.php
.. Settings.php
.. configuration.php
.. config.php
.. conf_global.php

So some of the symlinks are "root .. config.php", "sshd .. conf_global.php", etc.

Again, though, when I try to access them via FTP, permission is denied. So I don't THINK they were able to actually do anything.

My questions are:

1. Do you think that I can safely delete those files and directories?

2. Can you suggest a way to find any file on the server that MAY have been modified on or near that date? I'm running CentOS 6, so I guess I'd need a Linux command to scan the entire server?

csdude55

10:06 pm on Oct 10, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



2. Can you suggest a way to find any file on the server that MAY have been modified on or near that date? I'm running CentOS 6, so I guess I'd need a Linux command to scan the entire server?

Trying to answer my own question, I found this online:

touch --date "2020-10-04" /tmp/start
touch --date "2020-10-10" /tmp/end

find /home -type f -newer /tmp/start -not -newer /tmp/end > output.txt

This should write filenames of anything in the /home/ directory to output.txt that's been modified between 10/4/20 and 10/10/20. I haven't tried it yet, though, I'm going to wait until the server load is down (probably 2am).

I also plan to run this one, trying to find anywhere else that the hacker may have inserted his Adsense ID, but I suspect it will be slooooooow:

grep -rnw '/home/' -e '[ID]' > output.txt

If you have any thoughts on either of those scripts, though, please let me know before I mess something up! LOL

While we're poking around, any suggestions on how to scan ALL MySQL entries for that same ID?

lucy24

11:53 pm on Oct 10, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Options all 
...
Require None
Satisfy Any
Urk. Are you sure you want to say Options all? It seems safer to specify only the options you're certain you want for this directory.
:: quick look at docs ::
“Options all” doesn’t include MultiViews, which is fine because it can only be enabled in a <Directory> section of config, and you said this is htaccess. But it does include Indexes, which generally you wouldn't want. AFAIK all Options are inherited, so you really don't need to say anything about them in htaccess unless you specifically want something different from server defaults.

What does “Require None” (as a free-standing directive) mean? It would seem to be contradicted by “Satisfy any”.

I think it would be better to look at it from the other side: What is in this /bt/ directory, and what special requirements does it have? Once you've figured out the ways this directory needs to differ from the others, then you work out exactly what lines have to be present in its directory-specific htaccess. And if you yourself don't know what the directory is for and what its files are supposed to do ... Well, either find out or delete it, depending on who controls the server.

csdude55

4:24 am on Oct 11, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



No no, the cracker's adminer script is the one that created that .htaccess, not me. But since there was no "Sux.html" anywhere, I'm not sure what the purpose of that was supposed to be. But there are several misspellings, so I think it's obvious that the cracker doesn't speak English well, and was borrowing from someone else's work.

What is in this /bt/ directory, and what special requirements does it have?

Keep in mind that /bt/ and /BT/ were both created by the adminer script. From the symlinks inside of it, I suspect that it was an ATTEMPT (hopefully failed) to read all of those files.

lucy24

3:55 pm on Oct 11, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Got it. The good news, or at least the less-bad news, is that htaccess can never affect anything outside the directory it lives in, so once the directory is gone, everything is gone.

Were there really two separate directories, /bt/ and /BT/? That does sound like a one-size-fits-all script for malign robots, designed to work on both case-sensitive and case-insensitive servers.

csdude55

7:46 pm on Oct 11, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Were there really two separate directories, /bt/ and /BT/?

Yep. Lowercase had a symlink to /root/, and uppercase had 514 symlinks that were trying to find files that may or may not exist. As far as I can tell, though, none of them actually worked.

I didn't try to find the modified files last night (no one had confirmed or denied whether it would work, so I chickened out), but as far as I can tell the only thing they successfully did was inject their Adsense link in my MySQL. I don't see any change in my earnings, though (it's still WAY low), so I'm 90% sure that didn't work, either.

not2easy

7:50 pm on Oct 11, 2020 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



I don't see any change in my earnings, though (it's still WAY low), so I'm 90% sure that didn't work, either.
Sounds like a silly amateur attempt. Wouldn't their ID need to be added to your ads.txt file? Scary though.

csdude55

8:24 pm on Oct 11, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



It would, yes. And I checked... it wasn't :-) But let's be honest, crackers like this usually aren't the brightest people.

iamlost

1:26 am on Oct 12, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



If you were/are running the adminer db admin tool v4.6.2 or lower and especially if also running Magento your db may well have been compromised as well as all data extracted.

I recommend doing a scan for javascript in db fields as this is a known method for stealing visitors PII including CC and password info.

Note: while most script kiddies are a pita real crackers have been known to hide their real attack under the ‘obvious’ attack attempt.

If you haven’t/don’t use adminer admin then this is likely just a surface cleanup. If you have/do then I recommend a search on adminer attacks/vulnerabilities and do a deep search and destroy clean if a backup reversion is impractical impossible.

csdude55

7:34 am on Oct 13, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



I've scanned everything I can think of for "<script" and for the Adsense ID that they tried to plug in... I'm not finding anything, so I think I'm all clear!

Famous last words, I know :-O

I renamed .htaccess, php.ini, /bt/, and /BT/ a few days go, and haven't noticed any problem. Am I right to assume it's OK to go ahead and delete them? With /bt/ and /BT/ having symlinks to real files it makes me nervous, but surely deleting the symlink wouldn't affect the original files... right?