This guy's opinions do not reflect those of his employer. Obviously.
Archive for January, 2012
WharfWhacker v0.0.1a – Port Knocking in Python
3 months ago
*Update* Alright I removed the threading which was killing pretty much everything I replaced it with the select function, which is MUCH kinder on CPU and my happiness in general.
I missed a weekly blog post last week because I started a new project. That project is of course WharfWhacker, which is a python port knocker module. What I decided to turn WharfWhacker into is in the following feature list.
- Protects a list of ports from access
- Variable number of ports to knock on
- Prevent replay attacks
- Time based ports
- Portable
- Doesn’t piss me off
Let’t go through my list of features here, starting with “Doesn’t piss me off” by that I don’t mean that other port knockers piss me off (Moxie’s KnockKnock for example is awesome!). I mean that my code isn’t so bad that it makes me want to cry, and editing it is so difficult that I want to scream.
For the longest time I have been fascinated by two-factor tokens, how cool are they, you know what I am talking about, don’t lie. Because of this I decided to incorporate something like that into WharfWhacker, it comes along in the ports rotating every 60 seconds, not just the initial port which everyone shares, but the ones that are generated for new connections.
That leads me into preventing replay attacks. By using the ip-address of the connector in the port generation algorithms, WharfWhacker generates separate ports, and orders, for each of the knocks that need to happen for a connection to open up.
Portability is something that should be a prime goal in everything in my mind. I hate nothing more than having to install 12 different packages, and 3 different libraries just to get some small nifty project working. The reason behind this is that half the time it doesn’t work, or they installed it differently than you did, or just their OS does not work the same as yours. Initially WharfWhacker was using Scapy, I pulled that out simply because I wanted to increase portability, and reduce the number of package installs needed to get it running.
By adding in a variable number of ports for the knock sequence, as well as a password it gives all sorts of security customization that helps mask the port sequence needed to open access. Sure if you know the password, and the number of knocks anyone can access your server, but that isn’t what you should hand out unless you want someone to have access.
So with that I present WharfWhacker
http://github.com/integgroll/Wharf-Whacker
Or if you want to use git like you should use the following:
git://github.com/integgroll/Wharf-Whacker.git
From there you need to change the wharf.py to have the correct server ip address in it, and then change the password, please change the password, after that just run it as root. (I know, I know, but please feel free to check the source in wharfwhacker.py if you don’t trust me) From there you are set and good to go. To open ports for the server you need to change the target_ip_address to the target server, the local_ip_address to the ip you want allowed, and the secured ports, as well as the password, and then run whacker.py
Since WharfWhacker is still in it’s early stages please let me know of any issues you have with it, or any suggestions that you have as well, I like to know what I did “wrong”.
Why I support Max Password Length.
4 months ago
by integgroll
in Security
Based on title alone most of you will never read this and think “wow that guy is a moron”. Which is perfectly alright, you are allowed to do that. But don’t fear, after you are done reading it you will think the same thing.
Most websites out there are using some simple hashing algorithm that is quick for their server to calculate, and is “small” and of non variable size in a database. In may cases this is some derivation of MD5. Which that model has a completely different problem that I am not going to cover, Hash Cracking.
That’s right folk’s I am going to talk about the issues with Hash Collision! And now you are closing your tabs, which I don’t blame you for, because lets face it the issue I am talking about is really rare. Mostly you think I should shut up because MD5 has already been ‘proven’ broken (http://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities). I am not denying that their research doesn’t work, or that they can’t create a colliding set of data, they do and they can. But that issue has nothing to do with passwords, particularly when it comes to MD5.
Keyspace, MD5 has a keyspace of 128 bits. The examples in the link above are 1024 bits long, hence why I say they don’t matter in the case of passwords. The assumption that you make with a password hashing algorithm is that the algorithm is 1-1 and onto inside the size of the keyspace. Meaning that passwords that are 128 bits or smaller should never have a collision with another password that is 128 bits or smaller. Which assuming ASCII allows for 18 characters in a password, UTF-8 allows for 16. I am going to work with UTF-8 because lets face it, it’s gained some popularity in the past couple years online (http://googleblog.blogspot.com/2010/01/unicode-nearing-50-of-web.html).
Now if you are still reading you are thinking “Integgroll is an ignoramus passwords only have 95 possible characters that they can use!” And you would be right, there are only 95 of the possible 256 possible characters that appear in UTF-8 that are used for passwords. This means that an amazingly small portion of each character is used, about 37%, which leaves about 63% of the character to never change. If you get where I am going with this, that means there is a HUGE area of the keyspace that is never used by passwords.
Alright now it is time for some imagery to help sooth some of the math that is coming up. Imagine that you are above the Milky Way, and you can somehow throw half football fields at that area. Each of those spots where a half field lands, that is one password. If you were to do this for the 16 UTF-8 characters worth of keyspace that you can use in MD5 you would have 37% of the milky way covered in football fields. Wrap a stadium around THAT Jerry Jones!
If you were to toss another half field at the Milky Way after it had all those fields on it already, there is a 37% chance that it will land in the same place as another field already on the Milky Way. That is your chances of collision with a password that is 16 characters or less in the MD5 keyspace. Most of that 37% is wrapped up in passwords that are of good length. At 11 characters or less there is only about a 1% chance of a collision. When you get down to the shorter lengths, like say 8 or under, you are looking at 0.144% chance.
Yes, the numbers here are tiny, and the chance that a password and an account will match up with a collision that is much shorter than its length is very very rare in the password space. But this is a legitimate reason to limit password length, or at least it will be once you can brute force 11-16 character passwords relatively quickly.
My response to this is to not use a single hashing algorithm for authentication. For example, don’t use MD5 or MD5(SHA(BLOWFISH))) use MD5 and also use SHA store them in different fields in that user database, and only authenticate when the hashed password is matched for both algorithms.
TLDR: Use more than one form of hash algorithm with the results stored in different fields for authentication. Also Integgroll is a scrub.
Top 5 Postdictions for 2011
4 months ago
Every year you see thousands of blogs trying to wrap up what happened in the last year, or even worse predict what will happen over the next year, or worst of all, a top 10 list. Instead of doing anything like that I like to instead make predictions for the previous year, and I like to make over 4 of them and rank them in some sort of order, here they are.
3: Def Con 19 will amass over 15,000 attendees in the new venue, it will be the most chaotic that you have ever seen a Def Con. It will not be chaotic because of all the ‘hackers’ in one place, but instead of all of them that are crammed into a convention area like sardines. Someone will have to ask “How does it feel to outgrow your new venue before the second year in it Def Con?”
5: Anti-Sec movement, there will be an anti security movement in the year 2011, it will be vast and it will be quite cruise like. Most information security professionals will curse these cats in public, and while in earshot of their bosses. However in reality most of these very same professionals will be very happy at the new job security provided.
2: Playstation network will go down, productivity will increase because of it, but only after it goes down as everyone finds ways to complain about the PSN being down first. The network will continue to bounce, and then eventually Sony will finally admit that everyone who has ever spent money on PSN had their credit cards jacked.
4: B-Sides drama will ensue, there will be an errata post about the monetary practices of the lead organizer of B-Sides. Chaos will ensue. Hopefully though most people will just realize that while this might tarnish the name as a whole, B-Sides is still a thing for good in the long run. I love B-Sides events and with a singular exception I wouldn’t prefer to be at any other convention.
1: DerbyCon will arise from the murky depths that is 4th Street Live, and the people will rejoice. The most homey of all security conventions will happen in Louisville, Kentucky. There will be bourbon, there will be beer, and there will be cherry infused vodka. The talks will be pure and entertaining, the training will be informative and in some cases take forever and refuse people sleep. The CTF will even have textual images when flashed at the closing ceremony will make the audience flinch. While they will undersell tickets this year, it will only count toward the feeling of family that will persist across the convention hall. Hackers for Charity will raise more money at this convention than they did at Def Con 19, an impressive feat considering the attendance is a 15th of Def Con 19′s. Most importantly of all, there will be hugs, Oh will there ever be hugs abound, there will even be tickets for the hugs, and those tickets will be forged, and even turned into a charity item for HFC. The only downside to all of DerbyCon is that there will never be enough thanks for all of the effort put forth, and the happiness that is brought because of the event.
Now that I have postdicted the 2011 year you can all await these events becoming true with great happiness and mystery.