Splitinfinity Security Notice: epoch password scripts hackable

[SplitInfinity]

This notice is being posted so you can protect yourself.

ANYONE USING EPOCH'S epoch-add-pass.cgi is vulnerable to hackers.

There are new toos out to scan for sites that use this script and automatically
hack into it and gain root access on your server.

Disclaimer: SplitInfinity Networks has caught several hackers using this exploit.
Although we have caught them both on our network and other networks, we cannot verify that this problem is wide-spread because epoch may have a newer version of their scripts out now. All we will say is that you had better check and
be damn sure, otherwise they *will* use this exploit against you.

A search on google yielded no results. Epoch has been notified of this problem.

Solution: Disable the script and/or modify it to not allow remote commands to be issued. Contact epoch for new updates that fix this security flaw or you may email [email protected] for additional assistance.

[buran]

The first project I was assigned in this industry, in 1997, was setting up add-passwd.cgi. It was a perl script, so I rewrote it in C, removing all the stupid stuff and making it work with my user tables in mysql instead of flatfile.

Shouldn't everyone have a .htaccess with allow lines for Epoch's IP addresses anyway?

[SplitInfinity]

Everyone should scan their error logs for this type of entry:

error_log:ERROR - can't open ;echo;kill -9 `pidof chucu mypt mykmod km3 kmod ptrace psybnc pt bru 0x82-Local.Qp0ppa55d ga raven bindtty gch .gch .bindtty`;exit
error_log:ERROR - can't open ;echo;uname -a;exit
error_log:ERROR - can't open ;echo;chmod -fR 777 /tmp /usr/tmp /var/tmp;rm -rf /tmp/*;rm -rf /tmp/.*;exit
error_log:ERROR - can't open ;echo;echo `gcc`;exit
error_log:ERROR - can't open ;echo;gcc;exit
error_log:ERROR - can't open ;echo;gcc
error_log:ERROR - can't open ;echo;echo c9sppkfp</body></html> at /home/NAMECHANGEDTOHIDEVICTIMSITE/cgi-bin/passes/epoch-pass-add.cgi line 87, <STDIN> line 1.
error_log:ERROR - can't open ;echo;echo c9sppkfp</body></html> at /home/NAMECHANGEDTOHIDEVICTIMSITE/cgi-bin/passes/epoch-pass-add.cgi line 87, <STDIN> line 1.

Here is a list of IP's you might want to block because this is the source
address the hacker used on multiple occasions:

213.194.67.233
211.72.25.14
200.71.51.57
204.30.143.67
63.191.177.96

Those are all ips I saw connected to the port the backdoor was running on. however some could possibly be ftp sites they were trying to download something from or whatnot, not sure

[goBigtime]

How could a user level script vulnerability allow root access unless the server itself was behind in security updates?


Edit:

Err not to take away from the value and importance of your security vulnerability notice.

I just don't see how Epoch's script alone, running at a normal user level would allow privledge escalation (to root) on a well secured/updated server.

[SplitInfinity]

A script is a program and a program running on any computer has access to the files running on the computer it is on. Regardless of security updates for the Operating system itself, there are MANY other security concerns that plague
web servers. Of those concerns, one major one is sloppy programming.

A perl script has the ability to "shell" to system commands and execute them.
If a hacker finds a way to pass system level commands to a perl script which
was programmed sloppy, then the hacker can execute any command that
the web server itself has access to run. Whatever username your web server runs
as is the username that the script is running as.

Many files are accessable by normal non-root users.
Because of this, there are literally thousands of ways to exploit a server
as a regular old user and even possibly gain root access.

WARNING: Just because you updated your Linux or FreeBSD distribution does
not protect you from hackers who exploit shoddy programming. The CGI scripts themselves need to be secured to prevent the script from running any commands that a would-be hacker passes to it.

Here are some url's to look at:
http://www.cert.org/tech_tips/cgi_metacharacters.html#1
http://www.cert.org/vendor_bulletins/VB-98.01.excite
http://www.kb.cert.org/vuls/id/496064

GREAT sites you should frequently read:
http://www.cert.org
http://www.securityfocus.com

Sample Report:

Vulnerability Note VU#496064

ibrow NewsDesk does not securely handle input passed to open()

Overview
A vulnerability in ibrow NewsDesk allows an attacker to view files and execute operating system commands with the privileges of the web server.

I. Description
ibrow NewsDesk is a Perl CGI script that is designed to create and display news articles on a web site. The code for NewsDesk is implemented in the file newsdesk.cgi. This code accepts input from a URL and uses this data in an argument to the Perl open() command. Since NewsDesk does not adequately filter URL input, it is possible to construct a URL containing shell meta-characters such as "../" and "|" (pipe), and these characters will be processed with the privileges of the web server.

II. Impact
By submitting a specially crafted URL, an attacker can execute operating system commands and traverse the file system and read files with the permission of the web server.

III. Solution
The CERT/CC is currently unaware of a practical solution to this problem.

Modify NewsDesk

* Modify newsdesk.cgi to only allow acceptable characters in URL input that is passed to open(). This type of input validation is referred to as "positive" or "whitelist" filtering. See Laundering and Detecting Tainted Data in perlsec for more information.
* Enabling Perl "taint" checking will prevent execution of commands using the pipe character ("|"). See perlsec and the Secure Programming for Linux and Unix HOWTO for more information.
* Rewrite the vulnerable open() calls in newsdesk.cgi to be safer, possibly by using sysopen(). See perlopentut for more information.


Systems Affected
Vendor Status Date Updated
ibrow Vulnerable 2-Apr-2002

[goBigtime]

long post...

but the fact still remains that for privilege escalation from say, the apache user, or the normal user, to root, there needs to be pre-existing vulnerabilities on the webserver itself.

Which would usually exist due to lack of security updates on the webserver itself.

9 out of 10 times anyone with a virtual or shared hosting account could pop shell access even if they aren't supposed to. HOWEVER, what they are able to do from that shell greatly depends on how well the hosting company has kept that servers security updated.

That's all I'm trying to say.


If you want to stop people from popping shells when they aren't supposed to, use a CGI wrapper & call it a day.


The only reason I responded is because your original post made it sound like Epoch's bug would be solely responsible for allowing a root exploit to happen - which is a bit misleading.

However, MAJOR DAMAGE (editing, deletion) could be done to alll of the users files on the server that were writeable by the apache user (or the normal user if running suexec) due to a bug that would allow an unauthorized remote user to get a shell.... but getting root access is a different story.

[SplitInfinity]

By the way, I should tell everyone as well......

You should type these commands on your linux servers
just to do a quick check....

locate adore
locate torn
locate t0rn
locate linsniff

If you get results on those, better check them out because they are all not
supposed to be there.

By the way, I should mention SplitInfinity Networks does Security work as well as hosting and dedicated boxes/etc.....

:-)
Shameless Plug.

[SplitInfinity]

Security updates are not the all-in-one soluton to the problem for many reasons.

First off all, the developers must first know of an exploit to make a update about it. In most cases, when an exploit is discovered, the hacker-group keeps it a secret within their "circle of hackers". They use it as much as possible before claiming fame to it and publishing the exploit on the web. Its a fact that most people do not update their servers often enough the benefit from the protection
offered by the patches/updates. This is especially true for web servers. Desktop users tend to be notified by their OS that there are updates available and unix users tend to not have that setup (although it can be setup and should be).

Redhat's up2date is a good feature of RedHat Linux.

Everyone who has a RedHat server should go to:
http://www.redhat.com/errata
and do all the security and bug fix updates to their servers.

Rootkits allow any local user to become root.
So if you are a local user, yes, you can escalate to root if you know of
an exploit (and there are thousands) that the server owner failed to
update/fix/secure.

Also, regardless of root access, even if they are stuck in regular user mode....
They can:
Download your password files for your web site and run crack on them which
will decode them so they can post them to their password trading sites....
Download other text based files like databases, email lists and the like.
Credit card files if you have them in web-space....
Etc.....

Of course epocs problem isn't the sole problem in the world of hackers....
Epoch's shoddy programming *is* the problem for this particular incident
of a user doing what he or she is not supposed to do............ run commands
on your system.

Running a cgi-wrapper is a good idea for everyone. Sudo the scripts etc...
Even that has its failures though.

All I can say is update, use a firewall or iptables/ipchains to close restricted ports
and use by all means SSH not telnet and sftp not FTP.

-Chris

[SplitInfinity]

More good reading on this subject:

At the root of rootkits
http://quickenexcite.net.com/webbuil...32-8-4561014-1

Know Your Enemy: III
http://project.honeynet.org/papers/enemy3/

[Rand]

Epoch's current CGI scripts are not vulnerable.

We became aware of this problem several years ago and updated our script at that time. The problem only occurs if you continue to use the old script and you disable the I.P. check. We have attempted to contact all our clients to ensure that they no longer run this script.

However, if you are an Epoch client and are unsure whether you are running Epoch's current CGI script, please contact Epoch's technical support department ([email protected]). Our technical support staff will help you ensure that you have our current CGI script.

[goBigtime]

Very informative posts you are making (really),

and your skills of evasion are that of a true master...



But you are still not conceeding to the point that your original post blaming Epoch for a root exploit was a little misleading.

It's a bad bad hole. Should be fixed no doubt. But not a root exploit. However it is possibly a root exploit if your hosting company sucks & has left your server behind on security updates.

In most cases, when an exploit is discovered, the hacker-group keeps it a secret within their "circle of hackers". They use it as much as possible before claiming fame to it and publishing the exploit on the web.

But these "blackhat" exploits and vulnerabilities account for the lowest number of hacks out there - BECAUSE of the fact that they try to keep the exploits private for as long as possible (by not using them, because every attempt might lead to public discovery) .

Probably the best way to avoid blackhat attacks is to stay off of their shit lists.



Which leaves the rest of the (public) vulnerabilities.....

Its a fact that most people do not update their servers often enough the benefit from the protection offered by the patches/updates. This is especially true for web servers (hosting companies).

^ That is what I'm trying to say, and is BY FAR the most common reason for privledge escalation to root.

Most, if not all hosting companies have servers on their networks mildly to greatly behind on their server security.


Unfortunately most customers don't care about security until they are hacked... and then the finger pointing starts.



I would drop a shameless plug for our security consulting... but I've already done market tests - nobody cares. Well, they care (espeically when you are telling them whats vulnerable) but they don't want to pay to stay updated (via managed services).

[SplitInfinity]

w00h00! I'll drink to that.

In my experience, you are 100% right about the customer
not wanting to pay for it and they seem to not care until it happens
to them.

I *do* apologize for any un-intentional negativity toward epoch.
I like epoch and I already figured they had fixed the problem,
however I had to play devils advocate and give heed to the
potential problem "just in case".

Things web hosting customers dont like to do:

0. Back up their data locally
1. Pay for backup services
2. Pay for security work on their un-managed servers.
3. Pay for system updates on their un-managed servers.
4. Pay quality programmers to program clean and secure code.

Thanks to our managed servers, the security work is done for them.
But those who co-locate or want to manage their own servers
just don't seem to want to secure things as they are the boxes
hacked into normally.

I should start a new company for people who just got hacked.....
Perhaps.........

fuckmeIjustgothacked.com
justgothacked.com
helpImDrowning.com

lol

-Chris