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.

hey, we need to check that your connection works, torrent this file and md5 it

http://services.2014.shallweplayaga.me/hackertool.torrent_fe3b8b75e9639d35e8ac1d9809726ee2

The torrent file when loaded into Vuze showed that the file name was every_ip_address.txt. So I downloaded some of the file and observed the format. The format of the file was “0.0.0.1\n0.0.0.2\n…. “.

So I wrote a quick python script to calculate the md5:

#!/bin/python
import hashlib
m = hashlib.md5()
fsize = 0
a = ''
for i in xrange(256):
    for j in xrange(256):
        for k in xrange(256):
            for l in xrange(256):
                a = str(i)+'.'+str(j)+'.'+str(k)+'.'+str(l)+'\n'
                fsize += len(a)
                m.update( a )
print m.hexdigest()

The flag was “1a97f624cc74e4944350c04f5ae1fe8d”.

An interesting incident happened this past week to a friend – he had his identity stolen. More specifically, someone got a hold of his social security number (SSN), his date of birth (apparently) and his address. What the scammers or their “mules” (a term used to describe criminals who act on behalf of the actual criminal at their behest) did was that they went to the bank and requested to wire a huge sum of money to an account. The neat trick they played was before actually going to the bank they called the Verizon helpdesk and suspended my friend’s phone service. When they reached the bank and showed the bank agent the ID (some sort of a non-standard / fake ID) and gave the SSN to the bank agent, he/she grew suspicious and tried to contact my friend. However, due to Verizon suspending his phone service, the bank agent couldn’t get a hold of my friend. Luckily, the bank agent also sent my friend an email to which he responded promptly. The culprits were arrested and the investigation is still on.
What was quite interesting was, the modus operandi where the criminals know that banks rely on calling the customers if they suspect fraud and they had this covered. Quite intelligent.
So, you know what you need to do if your phone suddenly stops working – check if ID thieves have had a run on you, change all your passwords including email, change your credit card accounts and bank accounts and PINs and place a hold on your credit history with the credit reporting agencies such as Experian, Equifax and TransUnion.

Yesterday, while searching for Web Services on the Internet I came across an old, popular web service called “Amazon’s mechanical turk” based on the mechanical turk trick from old magic days.
The gist is, you (“The requestor”) put in a HIT (Human Interaction Task) in amazon’s lingo so that some one on the Internet can solve it for you (“the worker”). Most of what I saw on the website seemed like random tasks being used by researchers, online yellowpages-like directories, marketing, classification of goods, etc.
What might also be an interesting application, and I’m sure it’s probably being used for is, captcha-solving for spammers.
Also, the Amazon Mechanical Turk terms of service don’t help and say the following (verbatim):
Amazon Mechanical Turk provides a venue for third-party Requesters and third-party Providers to enter into and complete transactions. Amazon Mechanical Turk and its Affiliates are not involved in the transactions between Requesters and Providers. As a result, we have no control over the quality, safety or legality of the Services, the ability of Providers to provide the Services to Requesters’ satisfaction, or the ability of Requesters to pay for Services. We are not responsible for the actions of any Requester or Provider. We do not conduct any screening or other verification with respect to Requesters or Providers, nor do we provide any recommendations. As a Requester or a Provider, you use the Site at your own risk.

Given this, and the rates prevalent (about a penny or so per task), I think spammers might have a free-run on this service. Of course, amazon has a conveniently available web service available at http://mechanicalturk.amazonaws.com/AWSMechanicalTurk/AWSMechanicalTurkRequester.wsdl.
Now, the key question is, suppose a spammer uses this service, who’s to blame…I wouldn’t imagine the solvers know what the intent of the act is, amazon (possibly) can’t be liable because the ToS is required to be accepted before use, and since the requestor is somewhere on the Internet, he/she possibly can’t be traced.
Of course, I’m not saying that Mechanical Turk is all bad, but like all walks of life there’s a positive or a negative use to everything.
As someone once said: “Every tool is a weapon if you hold it right”!

I encountered various errors when compiling wepattack. This download does not come with a makefile that is compatible with the ubuntu distro that backtrack uses. First of all make sure that the wlan directory that you get when untarring the .tar.gz archive has execute permissions set to it.

$ cd WepAttack-0.1.3/src
$ chmod +x wlan

Once this is done “permission denied” errors should go.

/Desktop/WepAttack-0.1.3/src$ make
gcc -fno-for-scope -c -D__LINUX_WLAN__ -D__I386__ -o wepattack.o wepattack.c
cc1: warning: command line option "-fno-for-scope" is valid for C++/ObjC++ but not for C
wepattack.c: In function ‘loop_packets’:
wepattack.c:141: warning: incompatible implicit declaration of built-in function ‘strlen’
wepattack.c:146: warning: incompatible implicit declaration of built-in function ‘strlen’
wepattack.c:151: warning: incompatible implicit declaration of built-in function ‘strlen’
wepattack.c:156: warning: incompatible implicit declaration of built-in function ‘strlen’
wepattack.c: In function ‘clean_up’:
wepattack.c:184: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long int’
wepattack.c: In function ‘main’:
wepattack.c:309: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘long int’
gcc -fno-for-scope -c -D__LINUX_WLAN__ -D__I386__ -o rc4.o rc4.c
cc1: warning: command line option "-fno-for-scope" is valid for C++/ObjC++ but not for C
gcc -fno-for-scope -c -D__LINUX_WLAN__ -D__I386__ -o wepfilter.o wepfilter.c
cc1: warning: command line option "-fno-for-scope" is valid for C++/ObjC++ but not for C
gcc -fno-for-scope -c -D__LINUX_WLAN__ -D__I386__ -o log.o log.c
cc1: warning: command line option "-fno-for-scope" is valid for C++/ObjC++ but not for C
gcc -fno-for-scope -c -D__LINUX_WLAN__ -D__I386__ -o modes.o modes.c
cc1: warning: command line option "-fno-for-scope" is valid for C++/ObjC++ but not for C
modes.c:25:30: error: wlan/wlan_compat.h: Permission denied
modes.c:26:28: error: wlan/p80211hdr.h: Permission denied
modes.c: In function ‘generate_rc4_key’:
modes.c:51: warning: incompatible implicit declaration of built-in function ‘memcpy’
modes.c: In function ‘process_rc4_key’:
modes.c:68: warning: incompatible implicit declaration of built-in function ‘memcpy’
modes.c: In function ‘mode_keygen’:
modes.c:125: warning: incompatible implicit declaration of built-in function ‘memcpy’
modes.c:127: warning: incompatible implicit declaration of built-in function ‘strcpy’
modes.c: In function ‘mode_wep’:
modes.c:145: warning: incompatible implicit declaration of built-in function ‘memcpy’
make: *** [modes.o] Error 1

The following patch file will take care of most errors and you should be able to get Wepattack compiled properly:

diff -aur WepAttack-0.1.3/src/Makefile WepAttack-patched/src/Makefile
--- WepAttack-0.1.3/src/Makefile 2002-10-23 09:11:36.000000000 -0400
+++ WepAttack-patched/src/Makefile 2010-09-26 04:54:20.000000000 -0400
@@ -6,23 +6,23 @@
LD=gcc
#
# CFLAGS
-CFLAGS=-fno-for-scope -c -D__LINUX_WLAN__ -D__I386__
+CFLAGS= -c -D__LINUX_WLAN__ -D__I386__
#
#
# LDFLAGS
-#LDFLAGS=
+LDFLAGS=-L../run
#
#
# Libraries to link against
-LIBS= -lpcap -lz -lcrypto
+LIBS= -lpcap -lz -lcrypto
#
#
# Install path for wepattack
INSTDIR=/usr/bin

// main loop to process key in modes on every packet

Copy the above patch in to a file called wepattack.patch. Copy wepattack.patch into the WepAttack-0.1.3 directory and patch it as follows:

$ patch -p1 <wepattack.patch
$ cd src
make
sudo make install

You should be able to get wepattack installed!

This was my first hope conference (The Next HOPE Conference)despite being in New York City for more than half a decade. Always it seemed that work would send me out of town just before the con. However, this time around I had the good fortune of being in the city during the conference.
There were a few good talks some of which were not so technical but kindled the questions for privacy fanatics.
The talks I attended included Alessio Pennasilico’s talk about DDoS attack on Bakeca.it, Modern Crimeware and Tools talk by Alexander Heid, Steven Rambam’s talk on Privacy is Dead, Blaze Mouse Cheswick et. al’s talk which was abstract but awesome. I did attend a few more talks and it was fun. All in all a great conference.

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!