Increase in HTTP PUT Requests; DDoS Against Authorize.net; More JPEG Comments
Increase in HTTP PUT requests. A report from Ryan stated that he noticed an increase of HTTP PUT attempts to his public web servers over the past few weeks. After looking at the file names attempting to be uploaded, it appeared that this was an attempt to deface his web site. Some of the file names in his logs included:
PUT /index.html HTTP/1.0
PUT /at4k3r.htm HTTP/1.0
PUT /ka.htm HTTP/1.0
PUT /kateam HTTP/1.0
PUT /scanned HTTP/1.0
PUT /inf.txt HTTP/1.0
PUT /ownz.htm HTTP/1.0
PUT /hdg.htm HTTP/1.0
Johannes Ullrich, the ISC's CTO, checked our web logs and found similar activity. A quick search online revealed several hits on these file names (obviously we didn't bother checking index.html)
Fortunately the attempted defacements were not successful. Both Ryan and the ISC would like to highlight the importance of restricting the authorized HTTP request methods on public web servers. This "hack" (the easiest defacement method of them all) can be effectively denied by not allowing the PUT method and also with appropriate documentroot directory ownership/permissions. Check your web logs for this type of behavior. A simple snort rule to ALERT on PUT statements for sites that do not expect uploads would also be prudent.
DDoS Against Authorize.net. Authorize.net has been enduring an extended denial of service attack. A statement on their web site indicates that as of 1900Z today, they continue to experience intermittent large scale distributed denial of service (DDoS) attacks. These attacks have led to periodic disruptions for some of their merchants.
More JPEG Comments. The ISC received several requests to clarify the comments in Friday's diary concerning JPEG file attachments. Our recommendation is to not waste time blocking JPEG file attachments as a mitigation step while patching the MS04-028 issue. It creates a false sense of security as well as an enormous inconvenience to users, help desks, and system administrators. Here are some additional thoughts on this reasoning.
Internet Explorer and other applications will classify a file as an image based on the file extension, using header information to identify the actual image type. Because of this, an attacker can take a malicious JPEG and rename it to ".gif" before sending it as an attachment. Your filtering system may not correctly identify the file as a JPEG since the extension is ".gif", but your client system will try to render the file as a JPEG, potentially exposing your system. Therefore, if you were to try and filter malicious images by file extension, you'd have to filter out all known image extensions. Test it for yourself - take a .jpg file and rename it as a .gif/png/jpe/bmp/wmf - they all process the file as a JPEG on a WinXP SP2 system.
If you decide to block JPEG attachments in email, then you also need to consider blocking instant messaging, P2P, web surfing, and "allowed" email attachments that could contain JPEG images such as Microsoft Office applications. While it sounds like a easy quick-fix, blocking JPEG attachments is the wrong way to attack this problem. It removes a single vector at a very high cost to your network users and the help desk. Save your energy for security battles that are more worthwhile.
Train your employees to not use their business email for personal use, to turn off any in-line image rendering, to use text (rather than HTML) email for non-digitally signed and encrypted email, and use a good spam filter on your email gateway. These steps are preventative in nature and will defend against multiple attack vectors, not just the JPEG problem. Knee-jerk reactions to specific vulnerabilities rarely work. It is much better to engineer a secure network environment that includes strong policy and lots of user awareness training. "DENY ALL" is the best starting point, then ALLOW only those activities that support your business operations.
As security professionals, we have to be very careful to not become the person who prevents people from getting work done. Focusing on a secure network environment based on business needs and defense in depth will allow you to become an enabler of more efficient business processes while operating a more reliable and secure communications network.
(Thanks to Josh Wright and Johannes Ullrich for the additional thoughts and comments.)
Marcus H. Sachs
Handler on Duty
PUT /index.html HTTP/1.0
PUT /at4k3r.htm HTTP/1.0
PUT /ka.htm HTTP/1.0
PUT /kateam HTTP/1.0
PUT /scanned HTTP/1.0
PUT /inf.txt HTTP/1.0
PUT /ownz.htm HTTP/1.0
PUT /hdg.htm HTTP/1.0
Johannes Ullrich, the ISC's CTO, checked our web logs and found similar activity. A quick search online revealed several hits on these file names (obviously we didn't bother checking index.html)
Fortunately the attempted defacements were not successful. Both Ryan and the ISC would like to highlight the importance of restricting the authorized HTTP request methods on public web servers. This "hack" (the easiest defacement method of them all) can be effectively denied by not allowing the PUT method and also with appropriate documentroot directory ownership/permissions. Check your web logs for this type of behavior. A simple snort rule to ALERT on PUT statements for sites that do not expect uploads would also be prudent.
DDoS Against Authorize.net. Authorize.net has been enduring an extended denial of service attack. A statement on their web site indicates that as of 1900Z today, they continue to experience intermittent large scale distributed denial of service (DDoS) attacks. These attacks have led to periodic disruptions for some of their merchants.
More JPEG Comments. The ISC received several requests to clarify the comments in Friday's diary concerning JPEG file attachments. Our recommendation is to not waste time blocking JPEG file attachments as a mitigation step while patching the MS04-028 issue. It creates a false sense of security as well as an enormous inconvenience to users, help desks, and system administrators. Here are some additional thoughts on this reasoning.
Internet Explorer and other applications will classify a file as an image based on the file extension, using header information to identify the actual image type. Because of this, an attacker can take a malicious JPEG and rename it to ".gif" before sending it as an attachment. Your filtering system may not correctly identify the file as a JPEG since the extension is ".gif", but your client system will try to render the file as a JPEG, potentially exposing your system. Therefore, if you were to try and filter malicious images by file extension, you'd have to filter out all known image extensions. Test it for yourself - take a .jpg file and rename it as a .gif/png/jpe/bmp/wmf - they all process the file as a JPEG on a WinXP SP2 system.
If you decide to block JPEG attachments in email, then you also need to consider blocking instant messaging, P2P, web surfing, and "allowed" email attachments that could contain JPEG images such as Microsoft Office applications. While it sounds like a easy quick-fix, blocking JPEG attachments is the wrong way to attack this problem. It removes a single vector at a very high cost to your network users and the help desk. Save your energy for security battles that are more worthwhile.
Train your employees to not use their business email for personal use, to turn off any in-line image rendering, to use text (rather than HTML) email for non-digitally signed and encrypted email, and use a good spam filter on your email gateway. These steps are preventative in nature and will defend against multiple attack vectors, not just the JPEG problem. Knee-jerk reactions to specific vulnerabilities rarely work. It is much better to engineer a secure network environment that includes strong policy and lots of user awareness training. "DENY ALL" is the best starting point, then ALLOW only those activities that support your business operations.
As security professionals, we have to be very careful to not become the person who prevents people from getting work done. Focusing on a secure network environment based on business needs and defense in depth will allow you to become an enabler of more efficient business processes while operating a more reliable and secure communications network.
(Thanks to Josh Wright and Johannes Ullrich for the additional thoughts and comments.)
Marcus H. Sachs
Handler on Duty
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
Comments