Slashdot Mirror
Fingerprinting Port 80 Attacks
pg writes "I found an interesting article on www.cgisecurity.com that explains
common fingerprints in web server, and web application attacks. It goes to describe how to detect most known, and unknown attacks.
This may come in handy when trying to detect another internet worm."
It makes me angry that everyone decides to beef up security and write analytical articles about how to maintain security AFTER THE FACT. The problem is, that although this seems like a good idea now, fingerprinting probably won't help for the next series of attacks, because they will be different in nature.
__________________________________________
Take comfort in your ignorance.
Grandmaster Plague
I'm sure that the server that the article is posted on is getting a nice "attack" on port 80 right now!
Life is the leading cause of death in America.
isn't that an oxymoron?
isn't the usual fingerprint of an attack that your web server is down, your traffic explodes and all people you know send your their documents to have your advice ?
I don't see much more room for advanced technology there.
Owner of a Mensa membership card.
Will it ever be able to stop DDOS attacks? You can ofcause write software that checks for packages that have some common pattern but then this software is going to take resources and what happens on a distributed site like amazon with huge load?
formmail script exploits. Due to post 25 blocking, spammers are looking for exploitable formmail scripts to send their spam through. I guess the author just wanted to talk about root exploits, but there are other ways to abuse a web server.
No replies made to AC posts. Please log in.
That article doesn't cover too many port 80 exploits. It does cover the most common attacks, but, if you want some more information here is a more complete guide. There are also a lot of language translations of it at the top if you're not the most fluent in english.
Remember, these documenst are written to help server administrators get an idea of what to look out for, not to solve every single port 80 problem out there.
the byproduct of years of oppression by the white man
I think there is some value to this article for new admins - it highlights most of the common things you will see in your log files if someone is poking at your site.
By the same token, most well-written CGIs will block these sorts of attacks (and hopefully if you are writing CGIs you will have enough knowledge (and common sense) to write them in a reasonably secure manner).
At the least it's worth a quick five-minute scan.
/~mikeg
I'd love to see a plugin for apache that allowed a central server fingerprint database for new exploits.
Every hour or so, a web server could access a central fingerprint server and download what the latest exploits look like. If a exploit comes in, the server could deny that IP, or drop those accesses without needing to know what the particular exploit is. A self maintaining web server via the web.
What do you think?
If your using windows (blech!) you can get a program for free that blocks your port 80, as well as tells you the IP number of somebody attempting to get in. The program is called Portblocker, and the company that makes it is analog X. I often bomb the person who tries to access my computer with telnet requests just to irritate them.
Yes, I know I could grep 'em out while viewing, but I think garbage should be kept in a separate place to the real visitors' log entries.
NO TOUCH MONKEY!
Dont Blame the brother... He's one of us. FearLinux.com
Support Texas Troops use TXGoogle
I do have a question for my fellow slashdotters: Why does the author single out TFTP but not FTP? Does TFTP have inherrent weaknesses that would make it the file transfer protocol of choice for an attacker?
"Prepare for the worst - hope for the best."
FearLinux.com
Support Texas Troops use TXGoogle
Hmm, Snort has signatures written for all of these =)
This paper includes very loose regex heuristics for requests that "might be" attacks. These may be interesting for anomaly detection, when coupled with an engine that records incidence rate (if you see an exponential surge in 'weird' requests, then maybe you're seeing a worm's infection growth curve ).
But the result of deploying these (say, matching for "%20" in a URI) as intrusion detection system rules would be a high false positive rate.
You would be better off looking at arachNIDS for rules that are more specific and less likely to drown you in alerts.I didn't see any analytical papers from you detailing how to detect old and/or new attacks. Of course people are going to spend more time on a real problem then a theoretical, or minor one. I mean, duh.
autopr0n is like, down and stuff.
The article comes right out and states that it doesn't cover everything, but it seems to get the most common exploits. Once an admin gets this paper and secures the server against everything in it, it becomes easier to block other kinds of traffic (such as file types ending in exe). I do like the idea one poster had about a central database of port 80 fingerprints.
Who are the correct people, if any to alert in case you see such attacks originating from certain IPs?
GET /cgi-bin/phf?Jserver=a&Qalias=a%0Acat%20/etc/passw d HTTP/1.0
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
One thing that I am surprised is in what ports the webserver can reach out with, and what ports the webserver can be accessed with. If you have access to a firewall.. then the ONLY port that anyone should be able to connect to the webserver is port 80 (or port 443, depending on if you use SSL). Also, you shouldn't let your webserver send any outgoing packets unless they are originating from port 80. This circumvents a lot of common attacks which involve any sort of remote 3rd party or involve any service other than HTTP.
It seems that a great deal of these attacks are based upon the fact that file names are passed as CGI arguments. This is dumb. First of all, it causes your URL's to be unnecessarily ugly. Second, if one uses suffix mapping (e.g. in Apache), the URL is checked by the web server before being sent to a CGI type process. The upshot is that only files that live in the htdocs "sandbox" can be accessed. For example, http://www.davesresume.net/resume.xml points to the "/resume.xml" file in my web root. Go ahead and try "http://www.davesresume.net/../resume.xml" and you get a 404. The .xml extension is mapped to Apache Cocoon, my xml processor of choice, and there is no exploit opportunity unless I explicitly open one up with some other CGI code. Since I don't need any other file context, this type of attack is not a problem.
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
Based on the activity I detected I set the software up to look for a GET using any of the following substrings: SCRIPTS MSADC WINNT ADMIN.DLL _VTI_BIN and _MEM_BIN. If found then the requestor's IP address got added to a list. Anytime the TCP stack saw a SYN request from one of these addresses it just ignored it instead of starting the handshake. So far it has blocked 75 IP addresses and my log files are now pretty pristine.
Most of these attacks are aiming to get the web server to do something it shouldn't be doing in any case. This is a good argument for running it in a solid sandbox. There are many ways of doing this (VM's and chroot'ing are some simple mechanisms, there are numerous more robust mechanisms), so that even if the web server were exploited, it would be unable to perform malicious actions on behalf of the attacker. This is not to say that you shouldn't attempt to write robust server code, but to put all of your security eggs in the basket of your request parser is a dangerous idea.
Just off the top of my head, they forgot exploits involving the '&' character (or its hex encoding). I've seen this one used in much the same way as the ';' (basically, to execute an extra command in UNIX).
"Don't blame me, I voted for Kodos!"
I agree
I would go one step further. I would like an apache module that can recognize requests for certain resources, like
/scripts/root.exe?/c+dir
/c/winnt/system32/cmd.exe?/c+dir
/scripts/..%c0%af../winnt/system32/
etc.
and then just add that ip immediately to 127.0.0.1 without writing anything to access or error logs.
... as long as we're wishing...
I was wondering if you could block the port on TFTP, thus locking it out entirely, so I dug out my copy of Stevens, Volume I and skimmed the chapter on TFTP. The thing is, I see no mention of a port at all in this chapter. Am I just missing it or are ports a TCP concept (while TFTP runs UDP/IP)? Regardless of that, though, how do you defend against the use of TFTP in this manner?
Thanks again.
"Prepare for the worst - hope for the best."
Microsoft has a free tool that uses a text config file that allows for the rejection of http requests based on fingerprints. Check here if you are interested. Works pretty well.
you can't ack before you balls.. you just
Ok, sooooo, maybe we can enlist the aid of The Great Carnac? I'm not certain the writers of worms and perpetrators of DoS attacks are leaving their plans, hermetically sealed, on Funk and Wagnell's front porch.
Part of fighting an attack is certainly building a more attack resistant mechanism, but keep in mind that the ingenuity of the perpetrators is eventually their undoing, as attacks will have to become more and more sophisticated (except where gaping holes like those in a certain monopolies products are left in througn lack of ordinary foresight) as many aspects of the internet, as well as operating systems and applications get stronger.
A feeling of having made the same mistake before: Deja Foobar
From the title, I had sort of expected it to be a list of ways to recognize the major worms. My server log is full of NNNNNNNNNNNN and XXXXXXXXXXX and similar; it would be sort of cool to be able to go through and say, 'Oh, yes, that's Code Red, this one's Nimda, there's a Code Red ]['. Instead, the document basically says, 'Well, if your Web server is incredibly badly implemented, it might randomly execute commands that people pass in as query strings, and that would be bad; and buffer overflows happen too but they're beyond the scope.' Snore. Tell me something I don't already know, and show me how to recognize the attacks I'm actually being hit with hundreds of times per day. The attacks in this document are neither common, nor plausibly threatening.
I have been getting a ton of port 80 scans on my Linux box ( I don't use a webserver like Apache), but it seems that half the infected boxes on the planet are probing mine. I run Portsentry for protection so all the port 80 scans are blocked by the script and logged in my syslog. I have even written a few of the ISP's where their clients with infected boxes were scanning. Some even responded politely *grin*
My two bits
Clive DaSilva Email: clive.dasilva@gmail.com Ubuntu 18.10 Kernel 4.18
SetEnvIf Request_URI "cmd\.exe" ATTACK /www/logs/access_log
common env=!ATTACK
/www/logs/attack_log common env=ATTACK
SetEnvIf Request_URI "root\.exe" ATTACK
CustomLog
CustomLog
<Location />
Order Allow,Deny
Allow from all
Deny from env=ATTACK
ErrorDocument 403 "
</Location>
And then optionally for individual bad directories:
<Location /scripts/>
Deny from all
ErrorDocument 403 "
</Location>
At this point requests for cgi.exe are not being logged in access_log but only attack_log (leave out the attack_log line if you don't want even that much). They'll still show in error_log (but with a shorter error statement). The ErrorDocument line instructs Apache to send back nothing and just drop the connection - not as nasty as a tar pit, but at least you don't waste outgoing bandwidth, generally tighter than incoming for a Webserver. Also, Apache doesn't waste any time checking the file system on these requests, since the rules preclude that.
"with their freedom lost all virtue lose" - Milton
Among the utilites mentioned like snort, no one has hit on the actual fingerprinting utilities out there like nmap, nbtscan and something like portsentry.
/ect/hosts.deny and rereads hosts.deny and passes the address off to nmap or nbtscan to figure out what the box is running.
I forget off the top of my head if portsentry has scriptable events, if it does then the possibility of having a "guarddog" type box would be interesting.
For instance, if attack is detected portsentry and it does its thing by putting the offending adderss in
Nothing beats calling up an ISP and saying "you have a windows/linux/whatever box probing for webservers/mailservers/(insert service) and is attempting to execute a vulnerability of that service".
Nmap and Nbtscan are excellent utilities, but from using them and playing around, nmap is more of a discovery tool, nbtscan is more of a retalitory tool. Or, at the very least they both can be used as such.
I know from personal experience that nbtscan's default setting (normal, aggressive, insane) is enough to knock a box off of a network.
I scanned my cable modem...had to power down to get back up and knocked my boss off even with his knowledge...only a complete power down would bring the box back on the network.
If you can have a "honeypot" why not a "watchdog" box for computer security?
Has the "security/watchdog" been done before?
If it is not on fire, it is a software problem.
This paper on general web server vulnerabilities is quite good for those of you who would like to know the basics of what to look for in an attack on your web server. Covers the fundamentals well enough to give anyone an idea of how to detect if someone's trying to compromise your web server. If you're just reading (or writing) comments here and you haven't read it yet, go back now and do so!!
how about this... a 'virtual machine' as cracker bait...
set up a cgi program that fakes being a vulnerable system just to see what sort of attacks you get... call it 'perl', 'sh', or something especially enticing... and set up a fake file system for the hacker to explore, fake log files for them to modify, etc
this would be kind of like writing a text adventure game. you could put several fake encrypted files that are just random strings of characters..
There are 10 types of people in this world, those who can count in binary and those who can't.
That article doesn't cover too many port 80 exploits.
Nor does yours.
This discussion is about fingerprinting exploits. The article you reference discusses fingerprinting servers. Big difference.
Its about time for something like this. Just check dshield.org... port 80 attacks are #1 ever since Code Red 1
TFTP is udp based. Yes there are ports.
It runs on udp port 69.
And, you hit the nail on the head.. embedded systems.
tftp is 'trivial' so it can be used for bootstrapping systems. The protocol is as simple as it could possibly be (but not fast nor efficient network wise).
It was designed so it could be implemented with very little code in order to bootstrap systems.
Given that.. it really has no reason to be enabled at all in most modern systems.
The only uses I've used it for recently are:
booting diskless clients
cisco router configuration files
embeded systems work
As an admin.. I often DONT CARE. I don't want a report every time someone tries some IIS exploit against my apache server. I dont' want to waste my own resources tracking and logging this.
Sure, more information is better.. but.. I'm just not at risk.
You make your servers secure, and then you forget about it. You keep on top of new vulnerabilities.... but seriously folks.
Why should I care one bit whether some code-red worm tried to exploit apache thinking it was IIS? I'm immune, it's not relevant to me.
Now.. knowing what goes on in a network in general, yes, that's important. Run snort or something.. keep an eye on traffic coming in/out of your net
But get real. There are better, more productive things to spend time on.
Leonid Mamtchenkov
like nomoreRed kind of does, to prevent access if they hit a particular fingerprint?
A lot of people here have been asking what people should do after they are attacked. Here is an article/guideline for procedures on recovering after an attack. These steps include information on saving logs, documenting everything that you do after the attack, the type of evidence needed to prosecute, and who to contact (FBI, local police, etc) But as always..the best policy is to secure the system so that attacks don't happen.
_______________________________
"I'm not Conceited...I'm just a realist..."
Pardon my cynicism, but can you really trust someone who thinks that
cat access_log| grep -i ".."
will find anything useful in the log? And why -i ???
The article does not take IIS into account, that shows because Unicode is missing, the article also miss another point: Error codes!
/scripts/ directory and IIS wouldn't know what to do with an apache exploit. This will create tonnes of errors, making lame so called "cgi-scans" easy to spot.
Say user Foo runs cgi-scanner X against one system, without proper fingerprinting (as most lame script kiddies dont do), most scans will trigger an error because apache doesn't come with a
Apart from that, most network/security people should read the article; this is basic intrusion detection skills that should be mastered by you people, that include those apes (and that's an insult to primates!) who have those lame ass certifications.