Jason Kendall - God Department

Wikid Auth Server Behind MikroTik Reverse Proxy

Written by Jason Kendall Tuesday, 10 January 2012 13:25

Pre-Amble:

I've worked with Nick for a few years and played with the Wikid Auth 2-Factor system for a while. I really wanted to get it working on my own network again. Unfortunately, I only have one IP address and a few sites that run on port 80 - Of course, the clients for Wikid all use port 80 as well (don't assume this is bad!)

What is Wikid Auth:

What Is MikroTik RouterBoard:

Mikrotik develops high performance routers and wireless ISP systems, providing both hardware and software for most countries around the world.

Steps:

Previously, I had already setup my routerboard to act as a reverse proxy - You can follow these instructions to get that working: http://wiki.mikrotik.com/wiki/Multiple_Web_Servers

From here I needed to re-direct the Wikid Authentication requests to my new server.

Originally, I attempted to use the normal domain setup - by using the external IP address that the clients would use - however, this failed to work with the reverse proxy since it would have no domain name to look up in the local DNS system.

Fortunately, Wikid provides (for enterprise licences) a domain key server using [custom domain].wikidsystems.net - that custom key would be entered into the client and be mapped via DNS to the IP address as required. This domain is also used in the client HOST code for the web request. Thus, we can now use our reverse proxy in the routerboard router.

Step 1 - Request your custom domain key from the Wikid Staff - You should already be an enterprise customer - http://www.wikidsystems.com/company/company/contact-us

Step 2 - Ensure your Reverse proxy is configured (See above link)

Step 3 - Because the Client caches the IP address, if you move between internal dns and external DNS alot, you need to make sure the routerboard doesn't accept the incoming port 80 request (Firewall rule) - I don't use the web console, and I have a default deny all, so this is covered by that. YMMV.

Step 4 - Set the proxy to allow connections to the Domain Key address assigned by the Wikid team - We're adding a path of "/wikid/*" so that only the client communications is accepted.

/ip proxy access

add action=allow disabled=no dst-host=[Domain Key].wikidsystems.net dst-port=80 path=/wikid/*

Step 5 - Make an internal DNS record for the Domain Key address to point to your internal Wikid Server IP address

/ip dns static

add address=[Internal IP] disabled=no name=[Domain Key].wikidsystems.net ttl=1d

Step 6 - Enjoy.

You'll probably have some got-cha's if you use your routerboard as DNS server for your network - especially if the wikid client caches the internal IP address and move to an external area.

Using DNS Hash to validate Binary Files

Written by Jason Kendall Thursday, 02 June 2011 14:03

So I was having an interesting conversation with Eric Cowperthwaite (e_cowperthwaite) on twitter around the concept of OS on hardware and the topic turned to a concept that failed a number of years ago - thin clients. The concept is you have a small footprint box at the desktop, which is hardware only - it then connects to some back end system which handles all the compute power and displays the results back on the thin client. We talked about a project called CoreBoot which originally was LinuxBios with a goal of putting Linux on BIOS chips. They since have moved into making any OS available on the BIOS chip, but that's neither here nor there of this post.

The problem was noted that how does one verify any binary blobs which extent whats on the bios - Think TFTP server holding a CramFS based operating structure. If the attacker was able to modify that file, they would be able to p0wn all the boxes that used that image.

I jokingly suggested using DNS to return the hash of the image. I say jokingly because originally, I hadn't thought the concept though, and was more pointing out how often we take DNS and bend it to do things it was never intended. But lets look at this and play it out:

1. Coreboot initializes a kernel - for simplicity, we'll say it's Linux
2. Once it boots the kernel, it will require some sort of base file system, so it will go out and acquire a config file based on MAC address (think VoIP phones)
3. It will validate the config file by doing a DNS TXT query on an internal DNS system which will return a predefined HASH of the file
4. The config file will then point coreboot to the actual image it should download (in case there is multiple images available)
5. Once it downloads, and before it boots, it again uses DNS TXT queries to validate the image.

Why do this? Well:

1. Most companies already have this infrastructure
2. Would reduce the surface areas available to attackers
3. If the TFTP server and DNS systems are separate, requires the attacker compromise multiple systems

I'm sure there is caveat, and I'm sure someone will point them all out, like DNS/DHCP spoofing and other network issues, but I think this is an option that could be built upon and expanded.

[ Disclaimer - This posting does not provide my permission to use this idea in a commercial product. ]

See strings in Binaries using Notepad++

Written by Jason Kendall Wednesday, 27 July 2011 14:39

User Rating: / 1
PoorBest 

So here is a little trick I use constantly to see what strings are in a sample I'm working with. I find that sometimes it's easier to see the strings in this context rather then doing just a "strings" command.

Step 1: Open you sample in Notepad++



Step 2: Use TextFX -> TextFX Characters -> Zap all non printable characters to #



Step 3: Once all the non-printable characters are # (hash) you can remove them by doing a replace





Step 4: Profit

PHP Zip Encryption

Written by Jason Kendall Thursday, 14 July 2011 16:15

This is going to be 2 things:

1. A note pad for my notes on implementing PKWARE Zip Encryption in PHP
2. Once I get it working - a note and link to my ostlabs.com project page for the work.

So begins the notes:

1. A few twitter responses suggested Chilkat http://www.chilkatsoft.com/php.asp (Thx @hrbrmstr and @jwgoerlich)
2. Base ZIPing of a file can be found here: http://www.devco.net/code/zipfile.inc.txt
3. ZIP format details can be found here: http://www.pkware.com/documents/casestudies/APPNOTE.TXT

The following data:

In the file header section there is a "general purpose bit flag: (2 bytes)" - Bit 0 set will be encryption

Encryption details are in the same file as note 3 above - Heading: "VII. Traditional PKWARE Encryption"

Looks like the hardest part to implement will be:

Where crc32(old_crc,char) is a routine that given a CRC value and a
character, returns an updated CRC value after applying the CRC-32
algorithm described elsewhere in this document.

Sigh.

Update (July 15):

Realized that 7-Zip is open source ;) Found the code here: http://shurl.ca/a9 Files: CPP/7Zip/Crypto/ZipCrypto.cpp/.h

One of the hurdles above was the CRC32 stream update used in the PKWARE Crypto algo - A good friend of mine (@ircmaxell) took the code from 7-Zip and made the following: https://github.com/ircmaxell/PHP-CryptLib/blob/master/lib/CryptLib/Hash/CRC32.php#L100

Next stop - Crypto ;)