0

Relaxation unleashed!

-

Days of hard work seem to be over…or not quite…may be…
Graduation was wonderful and so were the trips with daddu and bhabhi to San Diego, Las Vegas and Grand Canyon and not to forget the shopping sprees at Barstow (I-40 exit at Lenwood Blvd.) and Citadel mall, Los Angeles.
Then came the trip to New York City which was as always very welcome!
Met up with Ankush at NYC working at Citigroup office at Long Island City. Now comes the time to unleash my sloth-like wrath towards summer!

0

InfoSec Pals

-

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.

0

Disabling Personas in FireFox

-

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!

8

Installing Firewalk on KUbuntu

-

Installing Firewalk turned out to be more complicated than I thought it would be. There were some compilation issues and some library errors.
The chief amongst them was:


checking for arp_get in -ldnet... no
configure: error: No libdnet? http://libdnet.sourceforge.net.

I did install libdnet using aptitude but it did not do the trick. Thereafer, searching a few forums got me this information. The “Libdnet” that Firewalk looks for is libdumbnet1 in the ubuntu language.
So I got the Debian packages from the following links:
libdnet1
libdnet-dev
I continued to get that error and no wonder because there was nothing in /usr/lib.
So I executed the following commands :


$ cd /usr/lib
$ sudo ln -s libdumbnet.so libdnet.so
$ cd /usr/include
$ sudo ln -s dumbnet.h dnet.h

Then there was a compilation error:


firewalk.c: In function ‘firewalk’:
firewalk.c:193: error: label at end of compound statement
make[1]: *** [firewalk.o] Error 1
make[1]: Leaving directory `/home/trance/Desktop/Firewalk/src'
make: *** [all-recursive] Error 1

So then opening the firewalk.c file in vim (and following up on line 193) showed that the “break;” statement was missing after default: switch statement.
So then I added the the following characters (without quotes) “break;” at a line above the comment as shown below:


default:
break;
/* empty */


$ ./configure
$ make
$ sudo make install
$ sudo cp man/firewalk.8 /usr/local/man/man8

Now firewalk was installed and ready to use!

0

Nessus Migrating Users to a new install

-

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
0

Application Security and the Incident Response Process

-

Application or software security is a field of infinite complexity. All of us know that where there is complexity, security issues lurk around in those dark corners. This post is about my ramblings on how I believe Application Security and Incident Response need to come together to handle incidents. As usual, I make references to the cloud because that’s what I do for my day job but the argument is remarkably similar even for on-premises companies that are not in the cloud.

First came the test….

When software fails, before it is deployed, it is typically deemed to be a “safe” failure i.e., someone who is looking can do something about it. In the cloud, what makes software development easy is that the cloud makes it easy for people to look. In AWS, for example, you have Cloudwatch and you also have things like liveness checks in Load balancers which can “trigger” events and you can create “operational handlers” for those trigger events via technologies like AWS Lambda and AWS Eventbridge. This is not new to security people. For as long as I can remember, Security operations and IT Ops teams (from the pre “cyber” days), always had runbooks on what to do when something did not work as expected. Today, this happens a lot as the complexity of software has increased. The software engineers need to ensure that they have “eyes” in their test environment even more than they have in production because, quite frankly, they can have as much instrumentation as they want in the test environments because who cares if there is a minor performance impact. It’s important to re-architect so that there is no impact due to observability but you can still go to town as long as the means justify the ends. Keeping a close eye on test failures, helps avoid failures in production – this is all captain obvious advice. So in the cloud, what does that translate to? In the cloud, you can tag resources and you can have separate dashboards for those tags. Ensuring that you pay a close attention to “thresholds” on when to alert and what to do when certain measures / thresholds hit. You can also get creative in using anomaly detection tooling or “Machine Learning” (there … I said it!). The core point being – the more you are observing your test environment, the less failures you see in production. And when you see less failures in production you can do what I am going to talk about next.

Then came the failure…

When software fails in production, assuming you have been diligent in your testing and have encountered “exception handlers” either in code or in operations, it is categorized as an incident. While operational incidents are just as important and may have as much impact as security incidents, I will restrict this discussion to security incidents (because that’s what I do). What sets apart organizations such as AWS and other mature software shops from the rest of them is their rigor and approach of blameless post-mortems on security incidents. Everyone, loves to say “there will be no finger pointing” but in reality that’s really, really difficult to implement and that’s where the culture of fact-finding has a big impact on “getting to the bottom of it”. A security incident *never* happens without an error on someone’s part – this is critical to recognize. For a security incident to happen, someone had to make a mistake but its important to realize that in the security world, there is no exact science so mistakes are inevitable – what “security maturity” means is how you don’t make a knee-jerk reaction (aka scorched earth mentality) and recover from it stronger. The more maturity companies show in diving into whether the security incident involved a requirements error, design error, implementation error or deployment error tells application development teams where they can improve their development process and also tells their Application security engineers where they can improve their pre-deployment checkers or integration tests as well as areas where tooling is developed to detect deviations from security expectations (or “security invariants”). This also tells the development teams, where they can improve their developer tooling so the misses don’t recur. Also, the operations teams should determine where their checkers can do better and how the response times can be reduced to say half of what it took. Asking the question “why?” repeatedly on reasoning about the events during an incident can give a unique insight on how to improve.

Then came the win!

The situation where the AppSec, AppDev, SecOps, IT Ops teams collaborate to ensure they can help each other to do such blameless post-mortems end up having better telemetry, better tooling process, better detection when something goes wrong (“alerts”) and also a healthier environment of positive feedback. No one is blameless, recognize it, improve from it and help each other for better organizational security.

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