While compiling socat-2.0.0-b5 on cygwin (Windows) I got a few errors and here’s how I fixed it:
xioopts.c: In function 'applyopts_single':
xioopts.c:3998: error: 'struct single' has no member named 'fd1'
xioopts.c:4000: error: 'struct single' has no member named 'fd1'
make[1]: *** [xioopts.o] Error 1
Edit the file xioopts.c in your favorite editor and replace ‘fd1’ by ‘rfd’ in both lines (3998 & 4000). That fixed this error but then I got my next error.

xio-ip.c:480: error: structure has no member named `ipi_spec_dst'
Edit xio-ip.c and comment out the entire snprintf statement in xio-ip.c line 480.

Continue compilation and it should now work fine.

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

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.

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 recently purchased a Proxmark3 from GeZhi Electronics. The proxmark3 client wouldn’t work. In fact the `dmesg` output did not even show the /dev/ttyACM0 device as was said all across the forum. i tried flashing the firmware but kept getting this error:

~/proxmark3/client# ./flasher -b ../bootrom/obj/bootrom.elf 
Loading ELF file '../bootrom/obj/bootrom.elf'...
Loading usable ELF segments:
0: V 0x00100000 P 0x00100000 (0x00000200->0x00000200) [R X] @0x94
1: V 0x00200000 P 0x00100200 (0x00000b38->0x00000b38) [RWX] @0x298
Attempted to write bootloader but bootloader writes are not enabled
Error while loading ../bootrom/obj/bootrom.elf

Also this is what showed up in the dmesg:

[ 7953.991935] usb 2-1.4: new full-speed USB device number 40 using ehci_hcd
[ 7959.078302] usb 2-1.4: New USB device found, idVendor=9ac4, idProduct=4b8f
[ 7959.078314] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 7959.078321] usb 2-1.4: Product: ProxMark-3 RFID Instrument
[ 7959.078326] usb 2-1.4: Manufacturer: J. Westhues
[ 7959.078331] usb 2-1.4: SerialNumber: ChangeMe
[ 7959.080485] hid-generic 0003:9AC4:4B8F.0014: hiddev0,hidraw0: USB HID v1.00 Device [J. Westhues ProxMark-3 RFID Instrument] on usb-0000:00:1d.0-1.4/input0

Note that in the above the device doesn’t show up as a /dev/ttyACM0 device which is what we need for the proxmark3 client application to work.
So it seemed like there was an issue with the Proxmark3 not being recognized as a CDC device. So I went through the googlecode repository and went to a version of firmware where CDC was not being used. It also seemed that the flasher was the issue. So I used an old flasher to flash with the latest firmware and boom it worked! Remember to keep the button on the Proxmark3 pressed when you plug it in, and keep holding it down until the firmware update has finished.
Here are the commands:

# svn checkout http://proxmark3.googlecode.com/svn/trunk/ proxmark3
# export DEVKITPRO=$HOME/proxmark3/
# export DEVKITARM=$DEVKITPRO/devkitARM
# export PATH=${PATH}:${DEVKITARM}/bin
# cd proxmark3
# make all
# cd ..
# svn checkout -r 629 http://proxmark3.googlecode.com/svn/trunk/ ~/proxmark3-old-3
# cd proxmark3-old-3/
# make all
# cd client
# ./flasher -b ../../proxmark3/bootrom/obj/bootrom.elf ../../proxmark3/armsrc/obj/osimage.elf ../../proxmark3/armsrc/obj/fpgaimage.elf

And boom! There you … all flashed and now the device is recognized as a /dev/ttyACM0 device.

I recently came back from the ToorConX in San Diego, CA. It was a great conference with some really cool talks. Especially RFD (Remote file download using blind sql injection), reversing malware using browser hooking, cracking crypt() hashes using Ps3, grey box peach fuzz xml generation tool (nunchaku), voip eavesdropping, bypassing browser memory protection.
These were some really cool talks but I still don’t have access to any presentation slides yet for the con. May be those will be posted some time.

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