What www.hak5.org started was quite commendable and I’m really not sure what the status of the Community Rainbow Tables project is at hak5.
They are generating the rainbow tables with the following configuration:

* NTLM
* mixalpha-numeric-all-space
* [abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%^&*()-_+=~`[]{}|\:;"'<>,.?/ ]
* 26 indexes, 22 files/index
* 572 tables total
* 340.93GB
* 96.07% probability of successful crack

I’m currently generating index 13 and index 26 on this configuration. It would be cool to have multiple people generate it and upload it. I know many people are already doing that as we speak. We should also have SHA1, MD5 project for mixalpha-numberic-all-space configurations.

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!

There has been a lot that’s being said about the use of AI in Cyber Security. This is for good reasons – people have said here and folks in information security (as we have called “cyber security” for decades now) have experienced first-hand. It’s only natural that already stretched InfoSec teams look at AI as the “saviour” to the skills / personnel gap to close it. Then again, there is a lot being said about companies selling products as “AI enabled” too.

But realistically speaking are there some things traditional organizations (“non-AI”) can do to actually do what many of these “AI enabled” products do? I wouldn’t have written this blog post now would I if the answer was anything but yes! 🙂

Let’s look at them:

1. Anomaly Detection – this is age old! Almost all security tools that “alert” us on something are essentially using this. How well? That’s debatable. The kind of anomaly detection that I am talking about is simple (but different). For example, abnormal login attempts on your Internet-facing systems is anomaly detection. So is abnormality of DNS queries. Your Cloudtrail logs (in AWS) showing an inordinate spend on EC2 instances is also anomaly. A abnormally small amount of time spent between a git commit and a production deployment of that commit is also odd! Your SaaS or Okta bill being high or your APIs getting throttled (without any known changes) are all anomalies. The response time for these depends on whether or not you have been able to automate these anomalies. The day you automate these “known” anomalies you are already doing what many of these “AI enabled” products are doing today (after of course charging you an arm and leg!)
2. UBA / User behavior analytics – a lot of products do that but the most simplistic things are reduction of logins / preventing logon from areas where you do not expect your users to originate from. This is “reduction” of attack surface. Is that foolproof? Hell no! Why? Generally, speaking adversaries do not attack systems from their home computers. Adversaries operate by using trampoline servers (sometimes layers of them) to send the attack from the “attacker controlled bots”. But it reduces your area of concentration. And then you can use UBA more effectively since you do know where your users are expected from at a macro level. To improve your “AI-ness” you can then add capabilities which are able to say not at a macro-level but on a per user level where that specific user is expected to originate from. And if it looks abnormal (or anomalous) then ask them to step up. There are numerous vendors in this space as well as products on the cheap which you could do. There are open source libraries that can also help you do that on the cheap. Again, something very expensive “AI enabled” products can do too.

I am sure there are many other things that as an organization one can start doing. Obviously, at the end of the day, every initiative takes resources and by no means are any of these simple but YMMV depending the size of your datasets, users, and organizations.

On the recently concluded PlaidCTF (which was an awesome competition) by PPP there was a problem.  Here it goes:

Question: We managed to get the source code for an encryption service running at 54.234.224.216:4433.

I have listed the python source provided below:

#!/usr/bin/python
import os
import struct
import SocketServer
import zlib
from Crypto.Cipher import AES
from Crypto.Util import Counter

# Not the real keys!
ENCRYPT_KEY = '0000000000000000000000000000000000000000000000000000000000000000'.decode('hex')
# Determine this key.
# Character set: lowercase letters and underscore
PROBLEM_KEY = 'XXXXXXXXXXXXXXXXXXXX'

def encrypt(data, ctr):
    aes = AES.new(ENCRYPT_KEY, AES.MODE_CTR, counter=ctr)
    return aes.encrypt(zlib.compress(data))

class ProblemHandler(SocketServer.StreamRequestHandler):
    def handle(self):
        nonce = os.urandom(8)
        self.wfile.write(nonce)
        ctr = Counter.new(64, prefix=nonce)
        while True:
            data = self.rfile.read(4)
            if not data:
                break

            try:
                length = struct.unpack('I', data)[0]
                if length > (1<<20):
                    break
                data = self.rfile.read(length)
                data += PROBLEM_KEY
                ciphertext = encrypt(data, ctr)
                self.wfile.write(struct.pack('I', len(ciphertext)))
                self.wfile.write(ciphertext)
            except:
                break

class ReusableTCPServer(SocketServer.ForkingMixIn, SocketServer.TCPServer):
    allow_reuse_address = True

if __name__ == '__main__':
    HOST = '0.0.0.0'
    PORT = 4433
    SocketServer.TCPServer.allow_reuse_address = True
    server = ReusableTCPServer((HOST, PORT), ProblemHandler)
    server.serve_forever()

The key on this challenge is to see that the stream encryption is being done on the compressed input. In the source provided, if the user input is similar to the secret value in the PROBLEM_DATA variable then the zlib.compress() function would show a reduced length ciphertext. This is somewhat (and I use the term loosely) similar to the CRIME vulnerability. The AES Counter mode RFC has the implementation details of the cipher. So I wrote the following script.

import socket
import sys
from itertools import *
import struct
def display(msg,numbytes):
	#print >>sys.stderr, 'received "%s"' % msg
	#print >>sys.stderr, 'bytes "%d"' % numbytes
	print >>sys.stderr, 'bytes %d ' % numbytes + msg.encode('hex')
# Create a TCP/IP socket
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# Connect the socket to the port where the server is listening
server_address = ('54.234.224.216', 4433)
print >>sys.stderr, 'connecting to %s port %s' % server_address
sock.connect(server_address)
#mesage len = 20 lowercase and underscore letters
try:
	amount_received = 0
	nonce = sock.recv(8)
	amount_received += len(nonce)
	# Send data
	#strng = 'crime_some'
	#minciphlen = 1000
	#strng = 'crimes_pays'
	#strng = 'so_'
	#strng = 'crime_some_times_pays'
	#strng = 'somet_'
	strng = 'cr'
	minchar = ''
	ciphlen = 1000
	sampleset = 'hijklmnopqrstuvwxyz_abdefgc'
	#while True:
	strng = strng + minchar	
	minciphlen = ciphlen
	minchar = ''
	for s in map("".join,permutations(sampleset,1)):
		#message = nonce +  (strng + s)*10  #'\x00'*11 + s
		message = strng + s
		datalen = struct.pack('I',len(message))  # datalen = '\xe4\x00\x00\x00'
		sock.sendall(datalen)
		#print >>sys.stderr, 'sending '+ message
		sock.sendall(message)
		#print >>sys.stderr, 'message sent'
		amount_received = 0
		# Look for the response
		data = sock.recv(4)
		amount_received += len(data)
		ciphlen = struct.unpack('I', data)[0]
		#print >>sys.stderr, message + ' ' 
		amount_received = 0
		if ciphlen <= minciphlen:
			minciphlen = ciphlen
			minchar = s
			print str(ciphlen) + ' It is ' + strng + minchar
		data = sock.recv(ciphlen)
		#display(data,ciphlen)		
finally:
    print >>sys.stderr, 'closing socket'
    sock.close()

When you connect to the service it provides you the nonce, so I prepended the nonce to the plaintext. The above script shows the plaintext and the length of the cipher text. To start off with this, you start with a string of length 1, and see which is the smallest length response, that gives your first character. Then in the

strng

variable above, you add that character and run again, and the lowest length ciphertext tells you the next character and so on. I noticed that sometimes the output had a few characters with the lowest length. So I tried each of them and ended up with the following flag:

crime_sometimes_pays 

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”!

There was a persistent cross-site scripting (XSS) vulnerability in Apache ActiveMQ console that could be triggered by an anonymous user. The stored XSS issues tend to be worse that reflected ones because they necessarily do not need any social engineering. Especially, in cases where an anonymous user can inject the payloads.
The link to the advisory is here.
Update April 8, 2010:
It turns out that there were many more variables vulnerable to the XSS attacks and not all the issues had been fixed. Dejan Bosanac (the ActiveMQ developer) has now put in more fixes to close out the issue.

This had me stumped but it’s not that tough. The persona website getpersonas.com tends to install personas without any permissions. But you can disable it by typing “about:config” in the Firefox address bar and remove any entry in the following property: lightweightThemes.usedThemes
There it is…you’ve now disabled personas!