RE: Has anyone ever exploited these Websphere (WAS) Weaknesses, If so How ? Can anyone Elaborate ?

["Brass, Phil (ISS Atlanta)" <PBrass () iss net>]

I've exploited the latter issue (servlets by classname) on Websphere,
where it was also configured to serve any servlet in the classpath, and
the classpath included some old Websphere sample servlets, and one of
these had a vulnerability that allowed java code execution, and you
could run OS commands from Java.

And I think the first one may be a good idea as well, depending on how
authentication is passed through by the application - for example, if
every "web" user accesses the bean as the same "bean" user, then this
might not be very useful, but if authentication is passed through from
login form to session to bean, then configuring bean (or other
middleware object) security can be useful protection against, for
example, a java code execution attack (such as server side include vulns
or other problems) - if the bean runs in the context of the
authenticated web user, then executing java code on the app server might
not compromise the bean layer.

Even if the beans run with the permissions of the web server, you might
be able to partition the application so that internal administrators run
the app from one server that is not visible to the internet, while
external users use a different web server, and grant different
permissions to each.

Phil

> -----Original Message-----
> From: bob [mailto:bobhome () dslextreme com] 
> Sent: Tuesday, September 21, 2004 12:01 AM
> To: Ring-of-Fire () yahoogroups com; 
> webappsec () securityfocus com; secprog () securityfocus com
> Subject: Has anyone ever exploited these Websphere (WAS) 
> Weaknesses, If so How ? Can anyone Elaborate ?
>
>
>
>
>
> 9. Secure Every Layer of the Application All too often, Web 
> applications are deployed with some degree of security 
> (home-grown or WAS-based) at the servlet layer, but other 
> layers of the application are left unsecured. This is usually 
> due to the false assumption that only servlets need to be 
> secured because they're the front door to the application.
>
> For example, developers often assume that EJBs don't need to 
> be secured, but this assumption is dangerously wrong. An 
> intruder can bypass the servlet interfaces and go directly to 
> the EJB layer and wreak havoc if you have no security 
> enforcement at that layer. This is easy to do with available 
> Java IDEs that can introspect running EJBs, obtain their 
> metadata, and dynamically create test clients. WebSphere 
> Studio is capable of this, and developers see this 
> functionality every day when they use the integrated test client.
>
> Often, the first reaction to this problem is to secure EJBs 
> via some trivial means - perhaps by marking them accessible 
> to all authenticated users.
> But,
> depending on the registry, "all authenticated users" might be 
> every employee in a company. Some administrators take this a 
> step further and restrict access to members of a certain 
> group that means roughly "anyone that can access this 
> application." That's better, but it's usually not sufficient, 
> as everyone that can access the application shouldn't 
> necessarily be able to perform all the operations in the application.
>
>
>
> 4. Don't Serve Servlets by Class Name
> Servlets can be served by class name or via a normal URL alias.
> Normally,
> applications choose the latter. That is, developers define a 
> precise mapping from each URL to each servlet class in the 
> web.xml file by hand or using one of the various WAS 
> development tools.
>
> However, WAS also lets you serve servlets by class name. 
> Instead of defining a mapping for each servlet, a single 
> generic URL (such as /servlet) serves all servlets. The 
> component of the path after the base is assumed by WAS to be 
> the class name for the servlet. For example, 
> /servlet/com.ibm.sample.MyServlet refers to the servlet class 
> com.ibm.sample.MyServlet.
>
> Serving servlets by class name is accomplished by setting the 
> serveServletsByClassnameEnabled property to true in the 
> ibm-web-ext.xmi file or by using the Application Assembly 
> Tool (AAT) and checking "Serve servlets by classname" on the 
> IBM Extensions tab of the WAR view. Do not enable this WAS 
> feature. This feature makes it possible for anyone who knows 
> the name of any servlet to invoke it directly. Even if your 
> servlet URLs are secured, an attacker may be able to bypass 
> the normal WAS URL-based security.
> Further,
> depending on the classloader structure, an attacker may be 
> able to invoke servlets outside of your Web application.