Pramati IIS Webgate plugin

Most of the times the Application servers are hidden beyond the Webserver/Load Balancers/Reverse Proxy servers, such as Apache and IIS. One of my previous posts talk about Reverse Proxy here In case you are running an apache server, it provides a nice Mod_proxy module to reverse proxy to back end nodes which happen to be Application servers. However, when running IIS, then we are in a fix if you are running the back end nodes as J2EE Application servers . Pramati Server has a nice plugin that helps you to dispatch requests from IIS to Pramati Server. Documentation for the same can be refered here. 

I have seen some issues where the IIS plugin installation shows up red in the IIS configuration window. Restarts of the IIS service/admin service does not seem to fix the problem. Here are 2 quick things that you might need to check if you are seeing this problem.

1. The version of the IIS Webgate plugin and the version of IIS being used. Pramati Server ships various versions of IIS Webgate plugin with different versions of Pramati Server. The ones shipped with 4.1 are compatible only with IIS 4 or IIS5. May be you are trying to use a wrong combination!! For Webgate plugin that works with IIS 5 and above, I recommend that you pick up the latest version of Pramati Server and use its plugin. The latest version of Pramati Server can be downloaded from the site here. 

2. Sometimes, the issue could be with the log file location that you have specified for the Webgate log. The log location tag is present in the iisplugin.props file located in the ${Pramati_install}/add_ons/webgate/iis folder. Change the value to a valid location on the system

LogFileName E:\\fubar.log

These 2 checks should be able to get you running with IIS Webgate plugin in Pramati Server. Inc case you still have problems, you can talk to your designated support contact at Pramati or drop a message in one of their forums here.

Session Stealing-2

Contnuation of the previous posting..

My apologies for the abrupt ending of my previous post. Something important came up due to which I had to end it abruptly.

Session hijacking is generally crafted using the following methodologies:

1. Request-Response Sniffing
2. Cross site scripting

Well, the first one can be prevented when the whole session is handled through https. However, if part of the session is handled through http and is switched over to https, then the sniffer would be able to pick up the session id transferred in the http session. To avoid this Pramati Server uses a special cookie in addition to the sessionid cookie. This pair is validated when trying to access the https pages. As the second cookie is set via https, the sniffer would not be able to view it easily. When the sniffer/hijacker sends a https session without the secret cookie, the server would understand that this is not from the authenticated user and hence will deny the response.

Regarding second, you should check if the server is immune to XSS (cross site scripting) vulnerabilities.

Session stealing

You have heard about username/password, identity stealing. Did you ever hear about session stealing/hijacking? Session stealing is the act of taking control of the user session after having obtained/generated authenticated session id. Following is a bit intro on session and session id.

HTTP is stateless protocol. To maintain the state of the logged in users and identify them, the servers depend on the session ids. Session is a series of interactions between two end points( in this case server and client) that happens during the span of single connection. Session ID is a random alphanumeric string that a web server assigns a specific user for the duration of that visit. Once the user is logged into the web site/application a session is created for that user and the server hands out the session id to the browser when sending the first response. The browser would send this Session ID to the server on all the subsequent requests. As long as the user makes the requests from the same browser without closing and reopening it, the web site would not ask for the login information. This is coz,the server/application validates the session id received from the browser and would check if the user with that session id is logged in.

Now that we know what session and session id is let us move on to how it is transmitted between the server and the browser. One of the most used method is to set the session id as cookie on the browser JSESSIONID in case of J2EE and ASPSESSIONID for .NET servers. If you have any tool such as IEHttpHeaders for IE or LiveHttpHeaders for Firefox, you would be able to see something similar to this in the response from the server.

Status=OK - 200

Date=Wed, 27 Jun 2007 11:13:45 GMT

Content-Type=text/html

Set-Cookie=JSESSIONID=978704440835854248; Path=/

X-Cache=MISS from HYD-MDU-CACHE2

Via=1.0 HYD-MDU-CACHE2:515 (squid/2.6.STABLE12)

Connection=close

What you are seeing here is the Session ID Cookie and the value of the session ID. Anyone sniffing on the network packets between your server and you would be able to easily flick this info. Now once he has that session id, he would send the request to the server with the session id along with the request (You can use Tamperdata extenstion of Firefox to do this)

Now you would start thinking. This guy has some random number generated by the server and that is passed between my browser and server. So what? Just to remind you, this session id is not just another alphanumeric string, as far as the application is considered, this your passport to the application unfortunately a passport without photo on it. Any one who has this session id can get the server tricked into believe that it is YOU who is talking to the server. It is equivalent to some one flicking off your passport and presenting himself as you(Remember no photo on it). Now when application believes that some one else is you, then it would allow that person to do what you would be able to do! Let me put it in few steps

1. You open your bank site and go to the login page and login.

2. Once you are successfully logged in, the server would redirect you to your account details and setting a session id cookie in your browser.

3. When you make any request in any of the bank site, the intelligent browser would send the session id to server along with the new request.

4. The server would verify this id and see that you are already logged on. Hence no more login requests.

5. Now lets say there is a guy in the middle who has been sniffing the requests and responses between your machine and the server. He would be able to see the Session ID cookie that’s shared with you. Now he would pick up the same session id and send it over to the server. Since the id is shared between server and only you, the server would be under the impression that you are the one who is talking to server but it is actually not!

6. Now the guy in the middle would make a request for harmless page with your session id sent along to the server.

7. Server would verify the session id and see that you are already logged in and hence would present the harmless page to the guy in between.

8. From here, he would be able to navigate to your account page effortlessly and view details or do what fancies him at that time.

More about this in my next blog.

Analog

How do Business Developers take decisions on what should they be targeting at? Well, I think they too need data. But, data like what? Lets say you have a web site then they would like to know what interests people the most in your site. How do they figure out this? They are not oracles that would look at the crystal ball and say “Look these are the most visited site on our site and hence developing these products/pages further would increase the traffic and your revenue”. Obviously they would like that kind of data from the person who manages the web site.

Whenever there is a hit to your website, the web server that you use silently logs the request and the response it has sent. But what use is it of? I thought you would never ask this question after reading the first paragraph above. Okay, since you have asked this anyway, let me answer that. This would help that poor guy who has to give the demographics of the site to the enthusiast business developers. But any decent web site would have hits to a volume of few thousands a day. How do we get demographics from thousands of requests? This is where web log analyzers come to our rescue. I have been looking at few web log analyzers recently. Being strong supporter of open source software, I have tried to search for few and I came across this tool named Analog. An open source product, you can download from here. What was impressive was that it took me less than 5 minutes to get the whole stats from my web logs. Just under 5 minutes!!

This is what I did:

Downloaded the package from here
Unzipped it to my disk
Got into unzipped directory located analog.cfg fle, opened it and pointed the web log file.
Saved the config file, and ran the analog executable.
That’s it. This created the Report.html file that contained the stats.

Sounds good. But if you have a web site, which has huge traffic, there would whole lot of web logs created in a single day. How do we deal with this? Simple.. Zip up all the logs, point Analog to the zipped up file and run it. Analog will take care of reading the requests from archive file and present the stats for you.

More documentation is available here

Server name in response headers

Was looking through some of the web server vulnerability problems again. Most of the servers do send the server name in the http response. In case you have any livehttpheaders or IEhttpheaders, the response from any of the Application servers can be checked and most of them would contain the server name and probably version as well.

Here is how you can turn it off in some app servers

In Pramati Server, changing value of display-server-name in-header tag to false in web-config.xml would do the trick.

To prevent a WebLogic Server instance from sending its name and version number, disable the Send Server Header attribute in the Administration Console. The attribute is located on the Server —>ServerName —>Configuration —>Protocols —>HTTP tab.

A new environment variable, SERVER_TOKEN_OFF, has been added to
WebSphere Application Server for z/OS v4.0.1 that suppresses Server header in the response

Apache webserver you can turn this off by setting ServerTokens option to prod. This does not eliminate the server name just removes the version of the Apache server.

Webserver vulnerability scanners

Having hit by few problems related to web server vulnerability, I turned to check what open source tools are available for checking my server. I quickly got got to this link. Out of the list, the one that caught my attention was Nikto. This is a based on Whisker/libwhisker for much of its underlying functionality.

So I quickly used my FC5 machine to run this. Its not like other scripts where you have to delve into the documentation to get them working. Nikto just needs a -host and -port parameters. That's nice. It ran 1900+ tests in just less than 8 seconds. hmmm.. this makes me skeptical now(anything that takes very less to complete and gives all positive results always makes me think this way). Well how do I really check what it is doing? Thankfully, Nikto has -verbose option to display all the tests that it has performed and its results. I plan to use its ssl option sometime later and check how it works..

Don't upload just Share
-dekoh