Tuesday, November 3, 2015

Virtualbox Guest Additions on Kali 2.0

Yello peeps.

Having problems with your Kali 2.0's screen size and needs a fix from the Virtualbox additions to get it right yet it's not installing properly? Don't fret. Try this:

Kali 2.0 not installing Virtualbox Additions properly >:|
Like many of the folks over teh internet, I had problems installing virtualbox additions in the new Kali 2.0. 
What didn't work: 
- Initially I was using the 32-bit version. Got error messages such as  "Building the VirtualBox Guest Additions kernel modules...failed". So I re-downloaded the Kali 2.0 but the amd64 version. Still got the same error messages. >:| 

What works for me:
- Initially I was using Virtualbox 4.3.10. Reading the comments, Felix emphasized that he used 4.3.30 which I suspected was the case. This is Felix's guide.

What I did - Uninstall Old VirtualBox and Install VirtualBox 4.3.32:
1) On my host machine (I'm on Ubuntu 14.02 Trusty): 
$ sudo apt-get purge virtualbox
// So that essentially uninstalled my virtualbox 4.3.10 on my ubuntu host machine
// If you're on windows, uninstall your old virtualbox. Your virtual machines should still be intact. I'm not using windows, so careful with the wizard prompts.

2) Downloaded the Virtualbox 4.3.32 from main site. If you are using older linux like mine (14.02 Trusty), you may want to use this link:

3) After installation, your virtual machines WILL crash as you're still on the old extensions. Within the virtualbox  GUI, click HELP -> CHECK FOR UPDATES. Mine returned a "network operation failed..unknown reason", so I closed the update window but got a pop up instead, asking if I would like to install the new extensions to replace the 4.3.10 old ones. So I agreed and re-downloaded and installed the extensions via the GUI.

4) Reboot the machine (may not be necessary but I wasn't able to unload and reload the vboxdrv so what the heck, i restarted my host machine.)

5) Boot back into my Kali 2.0 amd64 and tried the new VBoxLinuxAdditions. VIOLA! =D Happy me.

So what was the problem initially?
Just old version of Virtualbox didn't work. Felix said 4.3.30 works for him. I installed 4.3.32, works for me. :) 

Still having problems?
Try reinstalling your dkms on your linux host machine:
$ sudo apt-get install --reinstall dkms
And reboot your machine.

Hope this helps.

Peace out,

1. Felix's guide on install Virtualbox Guest Additions on the Kali 2.0
2. Virtualbox download links for older machines:

Thursday, October 29, 2015

2 LOWs can make 1 HIGH

Hello Peter, what's happening?

I have a day job that requires me to risk rate security vulnerabilities pretty much all the damn time. :D The risk rating portion isn't too bad but it's not hard to get challenged for the certain rating you give. Anyway, the main point of this post is: LOW doesn't mean OK-LETS-NOT-GIVE-A-SHIT. A combination of two LOW-rated vulnerability items could bring about a serious security breach.

For example, two LOW-rated issues:
Vulnerability ONE: Information disclosed in Perfdump file
For Oracle iPlanet Webservers, sysadmin can choose to dump out system performance information on a file named '.perf' in the webroot using the PerfDump functionality of the webserver.

According to Oracle's guide [1]:
"perfdump is a Server Application Function (SAF) built into Web Server that collects various pieces of performance data from the Web Server internal statistics and displays them in ASCII text. The perfdump output does not display all the statistics available through the command-line statistics or the Admin Console, but it can still be a useful tool. For example, you can still use perfdump even if the Administration Server is not running. You can view the perfdump output through the CLI, which is enabled by default, or you can view the perfdump output through a URI, which you have to enable. If you enable the URI, you must control access to the perfdump URI, otherwise it can be visible to users."

You'll get information displayed in ASCII text in the file.

webservd pid: 29133

Oracle iPlanet Web Server 7.0.9 B07/04/2010 02:06 (SunOS DOMESTIC)

Server started Fri Jul 14 14:34:15 2006
Process 29133 started Fri Jul 14 14:34:17 2006

Current/Peak/Limit Queue Length            2/237/1352
Total Connections Queued                   67364017
Average Queue Length (1, 5, 15 minutes)    4.52, 4.73, 4.85
Average Queueing Delay                     13.63 milliseconds

ListenSocket ls1:
Acceptor Threads          1
Default Virtual Server    https-test


You can also obtain the following information:
Process  Status    Client     Age  VS          Method URI                                      Function

29133    response  115  https-test  GET   /qa_webapp/CheckNetwork.class             service-j2ee
29133    response  8    https-test  GET   /qa_webapp/CheckNetwork.class             service-j2ee
29133    response  4    https-test  GET   /qa_webapp/CheckNetwork.class             service-j2ee
29133    response  4    https-test  GET   /perf                                     service-dump
From the above, you would obtain information such as IP addresses, HTTP Methods and the URLs&Parameters information on the clients that are connecting to the web server (or simply, people using/browsing the application hosted on the webserver). How helpful :) but no, no serious problems...yet.

Now let's introduce another vulnerability:
Vulnerability TWO: JSESSIONID disclosure in the URI
In my career, I've seen this issue a couple of times. Well, no sweat, no debate and everyone would agree it's a LOW or maybe (with MUCH arguing) at max a MEDIUM risk as there is no direct impact. But what happens if the session ID gets exposed on..say.. a Perfdump file? 

An example on what could be exposed in the PerfDump file:
Process  Status    Client     Age  VS          Method URI                                      Function

29132    response  115  mahapplication  GET   /admin/index.jsp?jsessionid=1A530637288A03B07119A44E8D532428             admin-portal

Ok. Ermm. Houston, we have a problem. 

Vulnerability ONE and TWO on their own wouldn't pose much of a security threat, however, putting them together could be a 'PWN' rated issue. If the webserver is in production serving web contents to the internet, any one on the internet would be able to gain access to[NOT-REAL]/.perf to obtain the application session ID of a authenticated user (or in this case, possibly the web administrator) by repeatedly requesting this PerfDump file over a period of time. When the user performs a request, the 'jsessionid' would be exposed and be reflected on the PerfDump file. The attacker could then harvest the 'jsessionid' from his requested-over-time PerfDump recon logs to hijack the session.

How to prevent this from happening, you asked? 
Do not ignore your LOWs and FIX. EVERY. SINGLE. DAMN. THING. :)
I use to suggest "You know what, this isn't a big of an issue. Meh, you can let it slide." After that day, I would say: "This isn't a big of an issue. But you know what, fix it anyway."

And ladies and gentlemen, this is my 2-cent contribution to the LOW2PWN community. Thank you very much.


1. Perfdump -
2. OWASP on Session Management -