| |
Complete Shell Access to Your Server
|
|
This is one of the most dangerous security problems.
The chief danger of this problem is that
too few people are willing to believe that it's possible.
"Unless someone gets root access, everything is secure."
How wrong they are!
Therefore, so that you know it is possible - regardless of what
your server admin or billing company assures you - we're publishing
precise instructions below. If you find one of these scripts on any
server, you have the entire run of the server, just as if you
had your own telnet login on that server. (In fact, it's better.)
- Numerous companies leave the master password of their "admin"
scripts in plain text. If you can read files on the server, you can read
up the passwords - and the hackers do precisely that.
- Use add-passwd.cgi and a host of other scripts to execute
ANY unix command ANYWHERE on your server. Remember all of those secret
keywords stored in plain text? The billing companies will assure
you that if your file permissions are correct, those secrets are safe.
That is simply not true! These and the other "shell exploit"
scripts allow any hacker to read any file on your server. (If you hide
personal info on your server, such as ftp logins or your ATM card number,
you might consider removing it NOW.) To execute the unix 'ls' command, for
example, send the following POST info to the script's URL:
Censored by request! This stuff is just too sensitive. Your billing company just doesn't want this information getting out. Funny thing is... the hackers don't want it getting out either!
- Hackers edit billing scripts to leave permanent backdoors. Check the
message board thread "HACKED, PLEASE READ!"
at Glo-Bill. The entire glocation.cgi script is posted, and not one person in
the entire thread noticed that the first three lines of the script are a login
shell giving hackers access to the entire server. Several companies leave
"where am I" scripts laying around after installation, which then
become back doors for hackers.
This is not by any means a complete list of "shell access" scripts.
Just the above is all you need to tear the guts out of thousands of servers.
If that doesn't make your hair stand on end, I don't know what will.
|
|
| |
Shell "Ethics"
|
|
This area is so sensitive that the Paysite Hackers have a lot to say
about keeping the Shell Exploits alive. Here is a sample tutorial.
Not to say i'm too expirienced with this, although i did use some shells, upped them and enjoyed them before.
Here's my P.O.V.
Before uploading a shell you should do the next things:
- Do you know how to do it? - you don't want the web admin to see you trying to open new folders/putting in new files ect and getting errors.
- Check dates - often I see people who upped shells that dated Jun 1,2003 when all the other files are dated March 4th 2000 - I don't think such a thing is hard for anyone to spot.
- Its exciting to get your own shell access and i'm sure you'll use "myname=isbest" when you do. but please... please... don't go and share it with 1000's of people, cause not only it'll die in 1.3 seconds... it can also cause a complete change of security from the web admin's view.
- Search the server for awhile before you upload a shell.. you'll see at some servers (usually that have add-passwd.cgi exploit available) a bit too many shells posted on it. Really there is no point in putting in another one, unless there's only 1 and you really want a backup.
- shells are great and i can't thank enough to those who first found that method of exploiting, but root is better.
I just want to bring attention that shells are lately being abused as much as the beloved add-passwd has been.
people are uploading too many and share them instead of keeping them as backups...
I just think its wrong... I uploaded 3 shells all together... and you'll never find them... cause their mine to use.
|
|
