Like any software product, a web server goes through a refinement process when it is first released. At this time many security holes are found along with many other miscellaneous software "bugs". Products that constantly add new features are usually more prone to security holes. Products that "never" update arcane features are prone to several initial security holes. Web server security holes that are commonly exploited are either due to a vulnerability in an added feature or a vulnerability in a base RFC feature implementation. IIS 1. The most common security holes that affect Microsoft's IIS deal with added features. For example ISAPI's and multilingual support. ISAPI ----------------------------------- .htr: HTR buffer overlows .printer: Printer buffer overflow .ida: Indexing buffer overflow .asp: ASP buffer overflow .htr: HTR file disclosure .asp: ASP file disclosure .stm: Server Side include ISAPI buffer overflow Multilingual support ----------------------------------- Unicode directory traversal attack "Double Decode" directory traversal attacks IDS evasion Apache 2. Apache vulnerabilities are similar. These days they are usually in added features or "modules". Modules --------------- ssl - multiple vulnerabilities php - multiple vulnerabilities rewrite, virtual hosting,publishing..etc. ... Sun ONE/iPlanet/Netscape Enterprise 3. iPlanet vulnerabilities, are also, very similar. They occur usually in added features. Various vulnerabilities in Search functionality, publishing, default scripts and file extension mappings. On a further note when a vulnerability is discovered in a core feature, such as caching or chunking, these are very severe and will usually affect several if not all server implementations. This is due to the code reuse tendency between software products. The developers read the RFC and code as they go, if not directly copy, paste and try and "make the compiler errors go away." In the last decade most of the RFC base implementation features have been audited severely, yielding numerous security holes in almost every implementation. They are more difficult to see using current techniques and using current mindsets. Some vulnerabilities in this class are: chunking integer overflow, authorization buffer overflows, header/method/uri processing vulnerabilities, and path mapping vulnerabilities. Vulnerabilities existing in RFC extensions are also very severe. There don't affect as many products as core RFC based vulnerabilities, but never the less they should be considered seriously. Vulnerabilities in this category might be WEBDAV vulnerabilities or vulnerabilities in added authentication support, browser negotiation, content expiration/caching..etc Nothing will ever be truly %100 secure. The goal is to minimize risk and meet the fine line between security and usability so that you can protect your assets while providing an enjoyable and sought after service. If you want to secure your webserver. Configure it just as you would a firewall. Disable everything and enable only what your target audience need. 1. Disable all features that you do not plan on using in the mere future. This includes modules/ISAPI's/plugins/extension mappings and DAV/Publishing, . 2. Remove default scripts and directories that you do not plan on using in the mere feature. 3. If possible filter content to reduce risk, this can be done using an application firewall or normalization engine, or anything else for that matter that will severely reduce the probability of successful penetration using unknown attacks or techniques. If you are unfamiliar with the general operation of a webserver or security concepts behind protecting a web server from intrusion. Review these documents for directions: http://nsa1.www.conxion.com/support/download.htm They were created and maintained by the guys and gals at SNAC, USAF and the NSA. These documents contain a wealth of information and provide the most comprehensive process to secure a variety of webservers currently available. After following their direction also look into application firewalls, normalization engines, or any other solution that will severely reduce the probability of successful penetration using unknown techniques or attacks. When pen-testing a software application, realize that it's very difficult to provide a valid service in a day, week, or even a month. To do a full audit of a single product, or it's implementation is a living project with no end. Proving to a company that they are insecure is only selling fear. Prove to them that they can feel more secure and prosperity becomes a goal of the past. Last but not least, never rely on one security solution to protect you. Never rely on your firewall, your AV solution, your buffer overflow protection system, or the ability of your security administrator to keep everything "up to date." If you have an IDS, turn it into a file server, or accept the fact that it's merely there for post-attack forensics or serving as a moron alarm. -R Riley Hassell Security Research Associate eEye Digital Security http://www.eeye.com/ Sleep when you're dead and only giveup when you can't give anymore... otherwise get the hell out of the kitchen because it's gonna get hot in here. ----- Original Message ----- From: "Cox, Michael" <mscoxat_private> To: <swalker7799at_private>; "Pen-Test Security Focus" <pen-testat_private> Sent: Tuesday, September 17, 2002 6:33 AM Subject: RE: Application & Iplanet/Apache web server vulnerability and penetration testing > 2) The NIST has a doc here http://csrc.nist.gov/publications/drafts.html > called "Special Publication 800-44, Guidelines on Securing Public Web > Servers." The NSA has guides on iPlanet and Apache here > http://nsa1.www.conxion.com/support/download.htm. > > 3) There's a guide due out in October from these good people > http://www.owasp.org/. There are a couple of recent books that look good, > but I've just received them so I can't comment in detail - _Hacking Web > Applications Exposed_ and _Web Hacking: Attacks and Defense_. > > Regards, > Michael > > > > -----Original Message----- > > From: Steven Walker [mailto:swalker7799at_private] > > Sent: Monday, September 16, 2002 12:05 PM > > To: Pen-Test Security Focus > > Subject: Application & Iplanet/Apache web server vulnerability and > > penetration testing > > Importance: High > > > > > > Dear Group, > > > > I have been given a project to perform web application > > vulnerability testing > > on iPlanet and Apache web servers. The servers run on > > NT/2000, Solaris > > 2.7-8, (iPlanet) and Linux, Solaris (Apache). > > > > In house tools are Wisker, WHArenal, NMAP, NESSUS. I have > > only used NMAP > > and NESSUS so far for firewall and internal network testing. > > > > I am at a loss at where to start the process and am trying to > > determine if > > additional tools are needed. > > > > 1. I would obviously harden the web server OS's by closing unnecessary > > ports, ensuring proper patch levels, getting rid of rhost and > > equiv files, > > enforcing password policies, limiting accounts, use ssh for > > administration, > > etc. > > > > 2. I don't know what to do on the web servers other than > > delete example > > scripts and ensure default passwords are changed to stronger > > ones. Are > > there any links that you know of that would provide a > > checklist of iPlanet > > and Apache vulnerability checks. Are there any recommended > > tools that can > > automate this process? Any suggestions on iPlanet and Apache > > security? > > > > 3. Regarding web applications, I will be expected to test applications > > before they go into production. I know to test for buffer > > overflows buy > > inputting non expected characters into fields. Beyond that > > what advice > > could you give or methodology could you direct me too. Jobs > > are tough to > > find out there, I could use your help in keeping this one. > > Thanks for all > > of you who will help me. > > > > Sincerely > > > > Steven M. Walker CISSP, GSEC, ABCP > > Security Specialist > > 44 W. Douglas Dr. > > Saint Peters, MO 63376 > > Office: 636.279.2206 > > Home: 636.278.8004 > > > > > > > > > > -------------------------------------------------------------- > > -------------- > > This list is provided by the SecurityFocus Security > > Intelligence Alert (SIA) > > Service. For more information on SecurityFocus' SIA service which > > automatically alerts you to the latest security > > vulnerabilities please see: > > https://alerts.securityfocus.com/ > > > > -------------------------------------------------------------------------- -- > This list is provided by the SecurityFocus Security Intelligence Alert (SIA) > Service. For more information on SecurityFocus' SIA service which > automatically alerts you to the latest security vulnerabilities please see: > https://alerts.securityfocus.com/ > > ---------------------------------------------------------------------------- This list is provided by the SecurityFocus Security Intelligence Alert (SIA) Service. For more information on SecurityFocus' SIA service which automatically alerts you to the latest security vulnerabilities please see: https://alerts.securityfocus.com/
This archive was generated by hypermail 2b30 : Thu Sep 19 2002 - 14:20:54 PDT