0

PlaidCTF 2013 – Crypto 250 Compression Writeup

-

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 
0

The historical evolution of Cross-Site Request Forgery

-

Having been in application security for more than 2 decades now and officially completing my 18th year now of being meaningfully employed in that space there is just a lot of crud that I have gathered in my brain. Most of that is history of how things came about to be. That stuff is likely not interesting to most but I find it intriguing as to how some seemingly minor decisions of one software vendor can have massive impact to the web application security industry.

Oh the dreaded IE…
Internet Explorer 4, 5 and 6 that started in the Windows XP days (or even earlier, can’t recall) had a setting – the cookie jar was not shared – i.e., if you opened a new window to a site, you would have to log in again unless you used “Ctrl+N” key to open a new window from an existing session. Each new process would have its own cookie jar. For the uninitiated, the “cookie jar” is the internal browser storage of cookies. Cookies are random looking strings that indicate a “trust token” that a web server places in the browser. Since HTTP is a connectionless protocol, this cookie is what preserves the “state” and this is exactly what authorization decisions in HTTP context are typically based on. These cookies are stored in a web browser data storage called cookie jar where each cookie gets stored with the name, value, domain, path (and today, there are few other attributes but that wasn’t the case back in 2004-2005). The browser gets all these parameters from the HTTP response header Set-Cookie. Microsoft, the vendor for Internet Explorer, made a decision that each new window of IE should have its own set of stored cookies that were not shared. Mozilla Firefox and Google Chrome always had a shared cookie jar if I recall correctly.

Along came a Cross-Site Request Forgery (CSRF)…

Jesse Burns from iSecPartners (an NYC-based security consultancy that was acquired by NCC group) back then wrote a paper which I think was the seminal paper on Cross-Site Request Forgery. They called it “XSRF” back then because “XSS” was already in parlance back-then. Thereafter, there were presentations in 2006 about the same by Microsoft. The whole attack was simple. The victim has a browser tab open in which they are logged into a site that has issued that session a cookie value. Due to the browser same-origin policy (a concept that Netscape designed in 1995) that cookie would be resent by the browser in the request as a Cookie HTTP request header whenever an HTTP request was sent to the same domain, protocol (“scheme”) and port. There were few idiosyncracies of IE (which made it infamous back then) such as if the port number did not match IE did not complain and would think that access was allowed per the Same-Origin Policy (SOP). What does that mean? http://example.com and http://example.com:81 would be treated as the same origin! Weird right? It wasn’t the case with other browsers. This was also documented in Michal Zalewski’s book Tangled Web in 2011. Where am I going with this? So while IE did some weird things, it did one good thing – isolate cookie jars. So if you opened up a new window where the attacker ran a payload that sent a request to the site which had handed you a cookie, the new IE window would have no interesting cookies to share with that site – inadvertently protecting the user from being a victim to a CSRF issue. Yes, the hated IE protected the users from being victim to CSRF! Who would have thought? That’s how weird 2005 was 🙂

Fast forward…

Since all browser vendor today have concept of shared cookie jars because who doesn’t like opening new tabs of their favorite cloud consoles without having to re-login right? So what did we the people do? We came up with another attribute that could be added to a Set-Cookie HTTP response header – SameSite attribute which restricted the cookie from being sent unless the request originated from a page on the same site as the cookie issuer.

So there you have it… the history of SameSite and how one of the most hated browsers of the day (IE) did one good thing for users – protect them from CSRF! 🙂

10

List of Security Conferences

-

I wanted to have a list of all the security conferences around the world for a quick reference so I compiled together a list.

DefCon http://www.defcon.org
BlackHat http://www.blackhat.com/
shmoocon http://www.shmoocon.org/
ToorCon http://www.toorcon.org/
you sh0t the sheriff http://www.ysts.org/
Hack.lu http://hack.lu
WOOTCon http://www.usenix.org/event/woot08/
Source Conferences http://www.sourceconference.com/
InfoSecurity Europe http://www.infosec.co.uk/
SyScan http://www.syscan.org
CONFidence http://confidence.org.pl/
CEICConference http://www.ceicconference.com/
RSA Conference http://www.rsaconference.com/
CanSecWest http://cansecwest.com/
EUSecWest http://eusecwest.com/
PACSec http://pacsec.jp/
BA-Con http://ba-con.com.ar/
Hack in the box http://www.hackinthebox.org/
Clubhack http://clubhack.com/
Xcon http://xcon.xfocus.net/
T2 Conference http://www.t2.fi
LayerOne http://layerone.info/
Owasp Conference http://www.owasp.org
DeepSec Conference https://deepsec.net/
FrHack conference http://www.frhack.org/
Shakacon http://www.shakacon.org/
Secrypt conference http://www.secrypt.org/
HackerHalted Conference
SecTor Conference http://www.sector.ca/
Microsoft Bluehat http://www.microsoft.com/technet/security/bluehat/default.mspx
ReCon http://recon.cx/
Hacker space festival http://www.hackerspace.net
RAID Conference http://www.raid-symposium.org/
Sec-T Conference http://www.sec-t.org/
BruCon http://www.brucon.org
DIMVA Conference http://www.dimva.org
SeaCure Conference http://seacure.it/
ColSec http://www.univ-orleans.fr/lifo/Manifestations/COLSEC
Auscert http://conference.auscert.org.au
RuxCon http://www.ruxcon.org.au/
uCon http://www.ucon-conference.org/
Chaos Communications Congress http://www.ccc.de/
Bellua Cyber Security http://www.bellua.com/bcs/
CISIS Conference http://www.cisis-conference.eu/
ATC Conference http://www.ux.uis.no/
NDSS Conference http://www.isoc.org/isoc/conferences/
EkoParty Conference http://www.ekoparty.com.ar/
No Con Name http://www.noconname.org/
KiwiCon http://www.kiwicon.org/
VNSecon http://conf.vnsecurity.net
EC2nd Conference http://www.ec2nd.org/
IMF Conference http://www.imf-conference.org/
BugCon http://www.bugcon.org/
Cyber Warfare http://www.ccdcoe.org
POC Conference http://www.powerofcommunity.net/
QuahogCon http://quahogcon.org/
NotaCon http://www.notacon.org
PhreakNic http://www.phreaknic.info
PlumberCon http://plumbercon.org/
Internet Security Operations and Intelligence http://isotf.org/isoi7.html
0

Machine Learning Security in the age of Supply Chain Attacks

-

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.

0

Reverse tunnels

-

SSH is an excellent piece of software which can help you do a lot of things such as have encrypted shells etc. But what makes SSH incredibly flexible is having tunnels.

A typical ssh tunnel works from the client to the ssh server and it forwards a local port on the client to the server seamlessly.

client ----> ssh_conn ----> ssh_server
client --> tunneled_port --> ssh_server
ssh -L 10000:localhost:10000 username@ssh_server

This connection creates a tunneled port on client:10000 i.e., anything sent to this port appears as if it’s automatically sent to ssh_server on port 10000. The localhost here is confusing, but think of it as….”what is localhost for ssh_server?”. It would be the ssh_server itself, right?
If you do a netstat on the client, you see a listener on the port 10000/tcp.

Now comes the more interesting reverse tunnel. The reverse tunnel is different in that, you have a tunnel being initiated by the client that says to the ssh server, “Hey, I’m initiating this connection that will allow you to automatically access a port on *me* after *I* initiate the connection?” (confused!!?!)

client ---> ssh_connection ---> server  ---+
                                           |
client <-- tunneled_port  <----- server ---+
ssh -NR 10000:localhost:10000 user@ssh_server

Here the meaning of localhost is slightly different, though.  The “localhost” means what is localhost for the client (and not on the server as in the previous case)!   So what you’re saying is, “Hey SSH server, I’m initiating this connection to you but if you connect to your port 10000 you will get a tunnel to *my* port 10000.”  If you do a netstat on the server you see a listener on port 10000. Isn’t it great that you can make the server listen to a port which acts as a tunnel to you…so anyone on the server can seamlessly connect to you even though technically you were the client!

0

Pass the hash

-

In a pen test, it’s always the race to the finish. Either you get to the domain admin or r00t or you die tryin’! 🙂 But thanks to some real l33t fu by Hernan Ochoa this has only been made easy for you.
The key to pass-the-hash attacks is that Windows NTLM authentication relies on the passing of the right hash to identify you. As long as the right hash is stored in the authenticated session you are who you say you are.
Hernan Ochoa’s Pass-the-hash toolkit (http://oss.coresecurity.com/projects/pshtoolkit.htm) is precisely the tool for that. Once you gain local admin rights on a box, just run the whosthere.exe utility on the box. Mind you, in differing versions of Windows you need some right addresses to pass as parameters. So the first thing to do is goto C:\WINDOWS\system32 and copy the lsasrv.dll file onto your local machine. The pass-the-hash src tar ball, has an IDA Pro script passthehash.idc that you need to run after opening the file in IDA Pro. This will give you the right addresses to pass to whosthere.exe:
whosthere.exe -a -o outputfile.txt

Once you have the hash you could either use iam.exe or winexe (http://eol.ovh.org/winexe/) with pass-the-hash patch from jo-mo-kun (http://www.foofus.net/jmk/tools/winexe), or samba with jomo kun’s pass the hash patch.
Just set the Environment variable SMBHASH to the hash value such as

export SMBHASH="92D887C9910492C3254E2DF489A880E4:7A2EDE4F51B94203984C6BA21239CF63"

Then run winexe as

./winexe -U "Domain\\Username" //192.168.0.1 "cmd.exe"

Of course, you can also expend some time in cracking the LM hashes to get the actual passwords but it isn’t really necessary.

1

CVE-2010-0684

-

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.