Interestingly enough, I found last week that the new Nessus 4.2.0 works by default as a web interface. Gone are the days of using the NessusClient and connecting to TCP port 1241 and using it to connect to the nessusd. Connecting to local TCP port 8834 (https://localhost:8834) brings you to a web interface that you can use to connect to the new Nessus daemon. The nesssusd listener does not even listen on port 1241 by default.
I’ll shortly get used to it but I know the transition would be slow for me …. after it takes getting used to when you completely change the architecture after maintaining it for at least a good 7 years or so!

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.

I will be speaking in Prof. Sengupta’s class at John Jay College of Criminal Justice at the City University of New York on Oct 28, 2010.  The topic of discussion will where does Digital Forensics fit in the big picture of organizations.  The talk will introduce the students to a variety of topics including choosing a career as a digital forensics investigator, their duties as an investigator, being successful as an investigator, case studies and real-life problems faced by the computer forensic investigators.

I think Nmap is by far the best portscanner around if you want to do some serious port-scanning. Nmap performs a DNS resolution by default. This is good for obtaining the fully qualified domain names (FQDN), however, in some cases when you are scanning huge networks spanning several class Bs, it can have a significant effect on the duration of the scan.
Although using the -n parameter can completely stop nmap from performing any resolutions, but sometimes there’s that fine granularity that you need, i.e., you want to perform name resolutions but not if it exceeds a certain amount of time. I have to say that I wouldn’t have even craved for such an idiosyncratic feature, had it not been for nmap. Fyodor has been awesome enough to provide fine-grained control over port-scanning to your heart’s content.
So I opened up the nmap code, trying to figure out if I could fine tune that feature myself and I was not at all surprised that there were several comments in the code that would give you the impression that the authors of nmap have been considering this feature.
At this time it seems that the timeouts for the DNS servers are being read out of an arrayname:
static int read_timeouts[][] in nmap_dns.cc.
The way the code works is, this array has retransmission timeouts. Each row of this array represents what retransmission timeouts that nmap will follow depending on the number of DNS servers provided.

In nmap 4.76, therefore, if you specify one DNS server (or only one entry exists in /etc/resolv.conf) nmap will wait 4000ms, then another 4000ms followed by 5000ms before giving up. But if you do specify two DNS servers, then for the first DNS server the timeouts are 2500ms followed by 4000ms and then the same is tried for the 2nd entry in the DNS servers. Therefore, it seems that nmap will wait 13 seconds at max before giving up on the DNS resolution of a host. Imagine scanning a class B and having to wait 13 seconds for each of the hosts to resolve. It would be a significant overhead.

Of course, one can find other things to do if the IP address space is not DHCP, e.g., starting a separate list scan (-sL) and a portscan (with -n) simultaneously so that the DNS resolution timeouts do not result in a major impact as far as the portscanning itself is concerned.
There could be pros and cons to this as well which I may have failed to consider. But at this time it seems that it might be the most judicious approach.

I’ve been a Batman fan since the time my father took me to watch the first Batman movie starring Michael Keaton. The latest addition to the Batman series is Christopher Nolan’s Batman Begins. The film is an excellent depiction of Batman and his rise as the caped crusader in Gotham City. The story is a prequel to the Batman movies which we have seen in the past.
The remaining cast is also well studded with some of the best actors of Hollywood like Michael Caine (Alfred) and Morgan Freeman. Katie Holmes also has done a good job of acting. But I still think that Michelle Pfeiffer is yet to be beaten in looks in the entire Batman series.
Overall, the movie is excellent with everything about Batman being explained and I think it’s a must watch for any Batman fan!

I recently started blogging for InfoSec Pals. It was started by Palan Annamalai who was my colleague at Ernst & Young’s Advanced Security Center where I worked for a year and a half. Other people who are active bloggers on the site apart from Palan and I are : Sri Vasudevan, Jay Kelath and Felipe Moreno. Let’s see if I can maintain the technical content of both the blogs and keep the goodies coming.

I was just browsing away when I stumbled upon Johnny Long’s GooScan. He says that this is a Linux only tool but it seems to compile (not without problems though) on cygwin.
I kept getting the following errors:

L:\tools\gooscan-v1.0.9>gcc gooscan.c
gooscan.c: In function `inet_send':
gooscan.c:575: error: `MSG_WAITALL' undeclared (first 
                       use in this function)
gooscan.c:575: error: (Each undeclared identifier is 
                       reported only once
gooscan.c:575: error: for each function it appears in.)

Then I read somewhere that MSG_WAITALL is not defined for Cygwin and that instead of that zero would work. There are many neater solutions to this…but I’m a hacker and I’ll do the stuff that’s easiest and hassle-free.
Some people say that the following will work:
#ifdef __CYGWIN__
#define MSG_WAITALL 0

So in order to compile this bad boy, you need to goto line 574 in your favorite editor.
It looks like this:
recv(sock, recvbuf, sizeof(recvbuf), MSG_WAITALL);

You need to make it look like this:
recv(sock, recvbuf, sizeof(recvbuf), 0);//MSG_WAITALL);

You are all set:
gcc gooscan.c -o gooscan.exe

Compilation works! But then I observed that the results were not coming well. However, if you run it through a local proxy such as burp it still works…I bet it has something to do with socket establishment and receiving and being incompatible with the MSG_WAITALL flag.
But as long as you can get the results … who cares? If someone figures out exactly how to make this work, please post it as a comment.