To avoid saving the truecrypt password in history files and mounting the Truecrypt partitions on bash the following trick helps:

history -d $((HISTCMD-1)) && sudo truecrypt --mount <PATH_TO_TRUECRYPT_VOL> --non-interactive -p <PASSWORD>

This will avoid saving the password in the .bash_history file and also mount the truecrypt volume from the command line.  Of course, if you use this in a shell script then the shell script will have the password in it, so you must not do that.

This has been a weird one, finding version information on the operating systems.
On Ubuntu, the following gets the version information
  cat /etc/issue
  cat /etc/lsb-release

On Linux, finding the kernel version
  uname -a
  cat /proc/version

On Windows, from Start-> Run -> cmd.exe
  winver
OR
  systeminfo

This is very simple but still there are a few times when memory fails and we’re not able to do the obvious.

To see the information about the hardware mapping :
  lshal

Finding your CPU Information
  cat /proc/cpuinfo

Finding memory information
  cat /proc/meminfo

Maximum number of SYN requests that the host will remember which did not receive an ACK from clients:
  cat /proc/sys/net/ipv4/tcp_max_syn_backlog

Finding data bus-size or bit-size i.e., whether my CPU is 32-bit or 64-bit:
  sudo lshw -C cpu | grep width

I finally got a candidate on the Common Vulnerabilities & Exposures (CVE) list. Apache Tomahawk also released a critical security update due to my disclosure to iDefense. In case, people are wondering I did not get any money for the disclosure to iDefense. It was just a case of responsible disclosure.
The advisory can be found at:
http://seclists.org/fulldisclosure/2007/Jun/0305.html.

The whole day today was spent in analyzing Nutch Source Code with Anshul. It is almost 8:00 pm now and nothing has been done yet! Have received an e-mail from Chris Mattman and Ashish Vaidya giving some pointers. Hopefully, it’s gonna help!
Had problems while compiling the code as well. It’s strange that when I installed j2sdk from Java Sun site I did not get javac in the /usr/java/jre1.5.0_02/bin directory. So since I did not have enough time to look for the files, I simply downloaded Netbeans and got the thing compiled with Daddu’s suggestion!
Will blog later when I can get some success with Nutch.
-Rajat.
Rajat’s Abode

As can be seen from the recent “xz attack” discovery that there nation states have realized that this is likely the “best” vector to impact large-scale systems in big organizations. With the cloud computing providers being the “source of computing” for most large corporations today, we should anticipate that a larger portion of the attacks will fall into this category. Also, just like “sleeper cells” in traditional espionage, such “sleepers” may exist in numerous OSS projects. Does that mean we should stop using open source – hell no. All that means is we just need to be careful. Can we detect these attacks? It’s tough to detect but yes we can detect them by good ol’ school, telemetry and observability.

But that’s not what this blog post is about. I think the most interesting bit from the xz attack for me was that the libraries that get harder to debug and decode are much juicier targets. How does that matter? The ML libraries that are super popular like pytorch and tensorflow and others are quite hard to compile out of bound from scratch. Such libraries can have interesting attack vectors which allow nice pickle compromises. I say “nice” because the family of insecure deserialization has existed in CWE since 2006! It’s older than many other issues and will continue to exist.

My only hope is that maintainers of core ML projects such as PyTorch, Tensorflow, keras and others start showing a slightly higher level of paranoia and build reproducibility so the supply chain attacks can be avoided on such harder to debug libraries.

I had to wipe my existing OS and had to reinstall Nessus on the new BT5R3 image. However, I still wanted all my previous scan data and users to be unaffected in the new OS. So how did I do that? Here’s how:

Take a backup and restore the following folders on the new install:

1. Users Folder (/opt/nessus/var/nessus/users)
2. Master.key (/opt/nessus/var/nessus/master.key)
3. Policies.db (/opt/nessus/var/nessus/policies.db)

If you do get an error after this follow these steps to get rid of errors and just reactivate the nessus feed as follows:

1. service nessusd stop
2. /opt/nessus/sbin/nessus-fix –reset
3. /opt/nessus/bin/nessus-fetch –register [activation code]
4. /opt/nessus/sbin/nessusd -R
5. service nessusd start

It can get interesting to test the security of thick client applications. If you start debugging you could end up losing a lot of time with not too many results. Of course, time is always at a premium when you pen testing in a week long gig. There are a couple of tools that can really help you to gain insight into a thick client (i.e., an application written in a binary format such as an executable, ActiveX control, flash object, etc.) and communicating to a server using the client/server model.
The need for a proxy to hook into the communications is a prime need and EchoMirage can do a great job of hooking into function calls related to win32 sockets, openssl functions. You have to select an active process for Echomirage to inject into or you can even spawn a process from the menu options in EchoMirage itself. It’s a great tool with a built-in editor so you can edit the traffic. However, sometimes you have to be careful because it’s binary data that you are editing so while editing it is easy to mess up a few flags, etc.
Another great tool is actually a plugin for OllyDbg called UHooker that can let you specify which functions you want to place a hook into. You have to configure a binary editor of your choosing and the functions to be hooked into in a .cfg file. The documentation for Uhooker is located here.