Hi guys
Just did a routine check of my server and wham I was hacked and have been exploited
The one immediate one is mempodipper , its invested my tmp dir

Please need some tips to keep the ^&&@##* out of my server

and what do I do with my current system . Upgrade kernel , format redo

What ever it takes

LAwrence

Hi,

Quick-n-dirty : back up the user data and re-install, but...that may not be an option.

It's an exploit, so, some "one" needs root access, I'd boot the thing up from a live CD (no infected stuff running) and manually edit the password file, possibly, one of the accounts has root privzz...

Secondly, this thing gets started up somehow, that means a look-see in the startup and cron scripts.

Is it a public server? Get it off-line for maints. Host something neutral (maintenance notice) if need be. Check the web stuff, that could (upon invocation of the HTML GET request, eg when someone calls up the infected page) start something without the hacker needing to be around...suspect PHP files calling CGI comes to mind. Real clever, but a bitch to find if there's quite some stuff around. Be suspicious of anything. A JPG file may nog even be a picture (learned that from an other GURU), that's the tripwire the "other one" dies on all the time, remember...

And, dont kill/shoot me for NOT being a Slacker , I use Arch Linux...I learned THAT kinda stuff from Arch...so...

Good luck!

Thor

AFAIK, 13.37 comes with 2.6.38, which is not affected by mempodipper exploits. It only affected Linux Kernel 2.6.39 and above up to the version that it has been patched (it was 3.2.2)

@willysr

I am running the standard kernel

I wen t to the developer of the exploits site he just updates the source
And seem to work on

Timeline :
Vulnerability discovered by zx2c4 (Jason A. Donenfeld)
Public release of the vulnerability the 2012-01-18
Exploit provided the 2012-01-23

PoC provided by:
zx2c4 (Jason A. Donenfeld)

Reference(s) :
CVE-2012-0056
EBD-ID-18411

Affected versions :
All Linux kernel's above or equal to 2.6.39 (32 bit or 64 bit).

uname -r
2.6.37.6

I found this in /tmp

mempodipper.c
and a executable mempodipper

/*
* Mempodipper
* by zx2c4
*
* Linux Local Root Exploit
*
* Rather than put my write up here, per usual, this time I've put it
* in a rather lengthy blog post: http://blog.zx2c4.com/749
*
* Enjoy.
*
* - zx2c4
* Jan 21, 2012
*
* CVE-2012-0056
*/

Regards
Lawrence

PART 2

A client password was cracked , I think that is how they got the file in the /tmp directory

I found that in my logs .. but now

Can someone help and maybe just let me know if that was possible , and do I have to format and start over

Or can I try and tighten it all up ( A bit late for me )

Regrds
Lawrence

I recommend doing so, because else you will never be sure that everything is set to the original status.

I also recommend using grsecurity and RBAC. It's very easy to set up with Slackware. It logs every attempt doing things on the machine which are not "normal" behaviour, and depending on what is tried it also reacts to this. It will for sure take some time to understand how this system works and it cannot guarantee 100% security (like everything else except going offline, which is not an option) and recompiling some stuff, but the idea behind grsecurity is very interesting (at least it was for me).


Some stuff for reading:

http://grsecurity.net/
http://forums.grsecurity.net/viewtopic.php?f=7&t=2939 (blog entry on CVE-2012-0056 )

I'd go for the format. Let's review some stuff. You may only have to rework the file system (OS space) partition, as your user spaces are in an other partition, that should not be a problem...however...

That could pose a big problem. You'll have to fine-tooth-comb out the user spaces...good luck with that one.

There is something I dont get (possibly still somewhat noob on that point, sorry) how can a cracked USER account gain ROOT access, unles a) security was set too weak (symlinks where there should be none, ect) or b) ... (even worse) the cracked account had Root access...
In my universe, any account with anything remotely Root-ish can only log on from the keyboard hooked to the box. Not tru the net cable...

Hmm...

Well, with an exploit for vulnerable software... for example downloaded from the Exploit database. This is probably the easiest part after user access to the box was gained. Since most of the exploits aim for root (uid/gid 0), it is essential to make the root account itself useless unless root takes up the admin role in a role based access control.

1 members found this post helpful.

Thanks for the replies ..

Going for the allnighter to redo the box

But what the heck learned a lesson ( make sure a user cant change his password to john ) WTF do these users think


Anyway thanks

Lawrence

if you have a mempodipper file, it doesn't mean that your system is hacked through that exploit. You must try to compile it and execute it by yourself to see if it's really working. AFAIK, the default kernel should not be exploited by those script, since it only affects 2.6.39 and above as i mentioned before

And if it's not working, you can trace the IP and login time of the account you think got hacked from the wtmp or btmp logfile (don't remember now which) with

If everything is normal, you maybe need to talk to this user If the box got hacked, this logfile probably isn't a trusted source of information anymore. As long as a box isn't hacked, such information could also be retrieved from process accounting (pacct) you could see what the user did at what time from which IP. Downside of pacct is that on a busy box it creates tons of information in the logfile.

A humble tip? You hand out the passwords...that way you're sure about the complexity.
Or maybe a tweak in /etc/pam.d/passwd (if memory serves) to enforce passwords that meet "certain standards"...

Good luck

Thor

Slackware doesn't include PAM Thor. However the passwd command from shadow won't let the user set it to 'john' anyway as it's too short, so I'd be interested to know how he managed to set it so in this case.

1 members found this post helpful.

What is the evidence that your system has been hacked?

You claim to be running the stock kernel, which is not vulnerable to the mempodipper exploit. Finding files in /tmp just means that some user has downloaded and attempted the exploit.

You claim a weak password problem was the route, but the password problem cannot have occurred.

I strongly advise some calm and clear thinking before taking drastic action.