A very typical scenario is that by default the Tomcat Servers tend to have a 404 Error page that displays the name of the file that was requested and not found. It seems to me that though display of such pages might be considered as merely an informational item for the purpose of any security test…this definitely presents a risk.
E.g., take this scenario.
1. The attackers has a SQL injection vulnerability in an application
2. The App server and DB can reach each other
3. The DB cannot directly reach the attacker and his system (on any port outbound)
4. The app server issues 404 error messages with the name of the file being disclosed in the 404 error message (e.g., The requested resource indexblah.html was not found).
5. The attacker can see the responses to the injected SQL queries (i.e., the injection is not blind).

Assuming that the DB accesses have been tightly controlled and you can’t get much access to any tables except the current one. This can be exploited as follows:
Invoke a SQL query (in the injection string) on the DB to request a page from the app server based on the contents of the DB such as send me /blahusername, /blahpassword where /blah is a string the attacker’s put in to make sure that such a resource doesn’t actually exist on the app server and username and password are columns or DB names from the DB. These error messages will be reflected in the response to the SQL query to the attacker. This could create an interesting side-channel attack whereby even though the data from the DB doesn’t actually reach the attacker, it can be inferred from the 404 – error messages.

___________       ______________        __________
| Attacker| <===> | App server | <=====>|  DB    |
___________       ______________        __________
      1  ----------> 2  -----------------> 3
                     5  <----------------  4
                     6  -----------------> 7
      10 <---------- 9 <-----------------  8   
1. Attacker sends sql to make the db query the app server for a non-existent page
2. The app server sends this sql query to the DB
3. The DB receives this SQL query and acts on it
4. The HTTP query for a missing resource is sent to the app server
5. App server looks up the resource and can't find it
6. The App server responds with a 404 /blahusername not found
7. The response recd is put in the SQL query response
8. The SQL query response is sent to the app server
9. The App server received the SQL query response (404 /blahusername not found as a line in there)
10. The attacker receives the 404 response with the data from the username in the 404 error message  

An interesting attack vector to say the least!

I wanted to have a list of all the security conferences around the world for a quick reference so I compiled together a list.

I wanted to install Cisco VPN client on BackTrack3. You can get the Cisco VPN client source using the following command:
wget ftp://ftp.cs.cornell.edu/pub/rvr/upload/vpnclient-linux-4.8.00.0490-k9.tar.gz
tar zxvf vpnclient-linux-4.8.00.0490-k9.tar.gz
cd vpnclient/
wget http://tuxx-home.at/projects/cisco-vpnclient/vpnclient-linux-2.6.22.diff
patch < vpnclient-linux-2.6.22.diff
./vpn_install

I got this information from the following blog.
I ran into an error whereby the kernel sources were not found for the VPN client to install. I then got the BackTrack3 kernel sources.
cd /lib/
wget http://www.offensive-security.com/kernel.lzm
mkdir test
lzm2dir kernel.lzm test

Now go into the vpnclient directory and execute the following:
./vpn_install

Accept the defaults (except in my case I selected “No” on automatically start VPN client). When it asks for the sources point it to:
/lib/test/usr/src/linux-2.6.21.5

Then the VPN Client should compile without any issues. Then you just need to place your Cisco VPN client Profile (.pcf) in the /etc/opt/cisco-vpnclient/Profiles directory. You will need to first start the VPN client service first using:

/etc/init.d/vpnclient_init start

Once the service is started just connect using:

vpnclient connect mypcffile user test password <whatever>

Please note that the full name of the Profile file in the above case is mypcffile.pcf but I’ve deliberately excluded the .pcf extension.
This should work.

Web services security has been very much talked about in the recent times. Especially, with the Service Oriented Architecture (SOA) gaining increasing importance. One of the interesting ways to protect these web services encapsulated in SOAP (Simple Object Access Protocol) is using digital client-side authentication certificates. Programmers typically use Java Key Store (.JKS) files to establish connectivity to these applications. However, if we want to create a custom client using some scripting it creates an issue as we tend to use languages such as perl, bash, etc. to create connectivity. So I ran into this excellent tool called KeyTool IUI. This tool helps you import the Java Key Store (Tools -> Keystore Manager -> JKS Keystore) and export it in the PKCS#12, X.509 PEM, and DER formats. You can further use OpenSSL to change the formats as you please or separate out the components of the certificates.
You could even take these certificates in X.509 or PFX formats and convert into JCEKS, JKS formats! Pretty cool huh? 🙂 Nice software!

An interesting thing happened today …I was trying to redirect some input to /dev/null in cygwin…using something like:
some_exec -p params 2>&/dev/null | grep blah
I kept getting an error : bash: Ambiguous redirect.
I then realized that I should probably doing a simple direct and not a re-direct…seemed to solve my problem. Come to think of it…it makes sense, why should I need to redirect when I’m sending it to /dev/null…should simply be able to direct it using:
some_exec -p paraa 2>/dev/null | grep blah

Dell had this program called Dell Vista Express Upgrade as a part of which once you pay for your XP Pro you become eligible for a Vista upgrade. The interesting thing was it was an introductory offer and they would ship the DVDs upon Vista’s release if we activated the upgrade. I did activate the upgrade but I did not receive my DVDs until a few days but when I eventually did it was a “Dell Vista Upgrade Assistant DVD”. What was even more interesting was that this DVD was not even an installation DVD (with no warnings on it that it was not the OS installation itself which I assumed all along). It was just a DVD because Dell likes sending DVDs to users! So I contacted Dell about the OS when I couldn’t boot up the OS and they said that no wonder…this is not the OS. So I asked them where’s the OS and the customer care went “you should have it”! Now if they didn’t ship it and I didn’t receive it (although I paid Dell for it), who should have it! They tell me Microsoft has it. It just seems illogical that the person who I pay for the software would not be the one to ship it out to me. The Dell Resolution specialist called today and said there’s nothing he could do. They have my money, they didn’t ship out the DVD…and so be it! Do what you can! That’s just the worst ever case of customer care I’ve ever seen!

I recently purchased 2x2GB Memory upgrades for my fantastic Dell XPS M1210. To upgrade the memory there were 2 slots one located at the base of the laptop (the black bottom) and the other was located below the keypad. I searched a lot on the Internet but could not find the location of the 2nd slot.
The owner’s manual also did not mention the location of the DIMM B slot (the 2nd memory slot). See the details on the manual about how to remove the keyboard to reach the 2nd memory slot.
The key to reach the 2nd slot is to first remove the hinge cover (the cover that has three button saying Power, “Media Direct”, etc.). The hinge cover is not screwed so you can just lever it up using a thin, flat object and pop-it up, remove the three screws fixing the keyboad, pulling the keyboad out and right in the middle you will see the memory slot.
Hopefully, this post will help someone upgrading memory on their Dell XPS M1210.