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.

Response to XKCD - Passwords

Written by Jason Kendall Wednesday, 10 August 2011 14:55

So - Everyone is talking about this:



And I have a problem with what everyone is saying - How XKCD gets "it".

As much as I really appreciate the humor in this comic, the fact that just changing passwords to 3-5 Random words doesn't make it any harder for a computer to brute force the password, actually, it probably makes it easier - Lets think about this.

When you want to brute for a password at most you have 26 Letters (Times 2), 10 Digits, and a smattering of non-letters/numbers (we'll say about 20 or so) this gives you a total of 82 possible items times the length of the password.

Now, lets look at the "solution": Oxford Dictionaries Guesses around 250,000 words in the dictionary - I'm going to say that most people wouldn't know MOST of those words, but we'll work with that number for now.

Possible Normal "passwords" with a length of 8: 2,044,140,858,654,976
Possible Word "Passwords" with a length of 3: 15,625,000,000,000,000

While I would hazard to say that looks impressive - I can't say my self I know 250,000 words to use in my password - I'm willing to bet that number would be a lot lower for the general populace.

I'm going to predict the future here and say most password crackers will start using the already available dictionary lists, and brute forcing passwords by concatenating the words, just like we already brute force letters, numbers and special characters.

One needs to combine the two solutions - Use Multiple words, Subsitute letters and words where available and keep the length: "Gue$$MyP@ssw0rd"

See strings in Binaries using Notepad++

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

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 ;)

Holy Trinity of InfoSec Tools

Written by Jason Kendall Tuesday, 12 July 2011 09:48

So a buddy of mine and myself have been talking a lot about this concept of the Holy Trinity of Infosec. The three main technologies that you should put the most time and effort into making sure they are working as expected, and yet, seems to be the most ignored areas of Infosec because they don't have blinky lights and aren't all that shiny anymore.

Anti-Virus:

We can all agree that AV needs to change - the concept of signature based anti-virus isn't working anymore since every other day a new variant can be built, thus bypassing current detection methods. Heuristics are great, especially if they include some sort of behavioral analysis of the binary - if it's connecting outbound, listening on a port, and changing important files, probably a bad thing. However, the failure in this area is that, you can't clean something found with huristics / behavioral, because you don't know what your cleaning. Of course, given the size of your IS shop, at the very minimum a sample should be taken, an Image of the box if possible (That's the GREM in me talking), and a complete re-image should be done - I'm a firm believer in the re-image only option when malware is detected on a box. Having said all that, AV is still one of the Holy Trinity of Infosec, because that's the first stop in detecting bad things - when implemented correctly.

Vulnerability Assessment:

When talking about Vulnerability assessment, I include not only VA, but Web Application Scanning, Database Scanning, and Configuration Management/Compliance. Given today's tools, there is no reason not to be doing these things - and it should work. This really is the first defense against any attack as it *should* show you where your weakness is. Yes, the argument is that your not going to find 0-Days, or more complex vulnerabilities, but those are always going to be there anyway - You want to protect at the very least the known bad, and low hanging fruit. Let's be realistic, a lot of the attacks that's happened in the past few months have been low hanging fruit - and that's just sad on the part of the companies - I can only hope the IS department for those companies have been screaming about these issues, or the failure of their VA programs. Oh, as a side note here, if your VA takes out a firewall (which you shouldn't be scanning though anyway) that's still a vulnerability and not the fault of the VA systems - that's called a DoS, and should still be fixed by your network team.

IDS/IPS:

The one thing we all take for granted - we all expect the IDS/IPS systems to detect and/or block when someone comes a knocking. The most common problems I see when it comes to IDS: 1) Network changes happen all the time, and there is little to no communication between the IS-OPs team and the Network team to make sure coverage still exists. 2) People are still using something that was implemented 6+ years ago, was good at the time, the vendor failed to keep up with new technologies, and then your team doesn't want to out-lay the money to replace a huge investment. In both cases, it sucks. From an IDS/IPS section, I want to see the following abilities:

• Detect attempts at known vulnerabilities - This should have a high confidence rate - Its great to detect edge cases, but give it a different detection name, this separates the real attacks from the possible false positives.
• Detect Command & Control Traffic - Really, this shouldn't be that hard, IRC, HTTP, and other non-encrypted protocols, there is no excuse. Even encrypted tunnels, if it's going to a known DNS name, detect the DNS request.
• Anomaly Detection - If after 6 months of traffic, all of a sudden something is trying to connect to all other computers on the network, this should toss up red flags - it's just that simple.
• IP based reputations - We have lists of SPAMers, C&Cs, and world wide attackers, there is no reason why an IDS can't pull at least from DShield or some other reputation IP database, given enough customers, the vendor should even be able to use opt-in anonymous information from it's clients to build it's own database - I for one would consider it.

The Center:

In the center of this Triad is broken up into two parts, both are things that really isn't specific to Info Sec; Log Correlation, and Asset Management.

Log Collection and Correlation:

You should have some sort of Log Collection system, even if its a simple box that runs syslog and dumps all the logs to disk - it's hugely important not only for the Info Sec shop so you have something to analyze when things go horribly wrong during an attack, but also the IT department as a way to track issues away from a box. It's a very simple thing to implement, and really, the only outlay of money would be hard drive space. Given higher volumes then a SOHO or SMB moving into an enterprise grade tool bring Correlation to the mix which really increases the proficiency of your log analysis teams, whether it be troubleshooting or investigations.

Asset Management:

If you've listened to the Jump Bag podcast you've heard me talk about the requirement to have a good asset control system. This integrates with so much of the above and is increasing important. The biggest Challenge of any investigation or troubleshooting process is identifying what an asset does, who owns it, who supports it, and where it is. A good asset tool should be able to keep track of all of that as well as the configuration of the device from at the very least the identifying characteristics. These include, not only Asset Identifiers, Serial Numbers, Hostnames, and local IP addresses, but if it's behind a load balancer or NATing device, it should also contain any IPs and DNS names that get redirected to the boxes.

This is something I've been thinking about for a while, and I'd like comments on it - Submit them here, or find my email address and flip me one - I'd like your thoughts on this concept.