This guy's opinions do not reflect those of his employer. Obviously.
integgroll
(3 comments, 24 posts)
This user hasn't shared any profile information
Posts by integgroll
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.
Knowledge and Sales.
5 months ago
by integgroll
in Security
I would like to start off by saying that I am not a Pen. Tester by trade, I am also not in sales. However the following has been compiled from podcasts, talks, and conversations with people who are.
That being said I have put together a few conclusions
1: The days of walking in, owning a network, saying “your shit sucks”, then collecting a check are over, this has been beaten to death by everyone.
2: Companies are demanding value from an engagement they pay for.
3: The demanded value is more often than we would like, a checkbox.
4: Thank you for voting for Wim Remes for the ISC2 board.
5: Sales people tend to not have conceptual Knowledge about the industry.
I would like to ignore the first four conclusions, and pay attention to number 5.
I have heard from educators, that there are two types of Knowledge, Procedural and Conceptual.
Procedural Knowledge is basically knowing that 2*2 is 4 and 2*3 is 6 2*4 is 8 and so on. I would compare this to the rote memorization of your multiplication tables that you did when you were in elementary school. You could also compare this to how most people know the OSI model for the CISSP. Although I do agree People Don’t Need To See Paula Abdul.
Conceptual Knowledge is different, it is understanding that the reason 2*2 is 4 is because there are 2 sets of 2 individual somethings, and when you add that all together you get 4 individual sometings. It is understanding why each of the OSI layers are different, and that there is a reason for it.
I would like to argue that there is a third kind of Knowledge.
Mythic Knowledge is different than the other two, it is when you don’t care what 2*2 is, so long as someone else can find it out somewhere. You don’t care about any of the OSI layers, you don’t even care that there are layers.
I would argue that the sales people have mythic Knowledge about information security.
The real issue here is that the people selling the product don’t know anything about it. The only reason that they are able to get away with this is because the people they are selling the product to don’t know what the product that they are buying is either, they just know that they need it.
There is a wide field of concepts to get a grasp on in just one of the areas of study in said line of work. We have sales people who are responsible for selling all kinds of things from Vulnerability scans, to penetration tests, to PCI and HIPPA and Ad Nauseam compliance. So this is not entirely their fault, it is a lot to learn, from the complaints I hear it seems aren’t even trying, other than to meet their quotas.
But at the same time it seems that most of us are not trying to help. Which we shouldn’t have to, people selling your products should be willing to get to know the products. But when they are able to sell them without having to learn anything, why should they even bother?
A whole lack of conceptual Knowledge is the reason that the information security industry has such a snake oil salesman reputation.
In saying all of this I am not implying that every sales person should go out and go get a CISSP in order to be able to do business in this field. Because that doesn’t solve the issue, and only pads a budget that is not your companies. Much like Compliance is not Security, Certification is not Knowledge.
At the same time though you should also not just bend over and take it, you need to pull your sales people who you think are lacking in the Knowledge aside, and offer to teach them a few things. Perhaps print out the IPv4 CIDR chart from Wikipedia and stick it on their wall. The next time that your sales guy trys to pass off something ridiculous you have to “nip it in the bud” or else you are going to continue to work those 130 hour or more weeks, which one isn’t healthy, and two is not what your client is paying for.
The moral of the story here I guess is if you can’t get someone to learn a topic conceptually, at the very least beat them out of the mythic Knowledge section as quickly as possible. It really is better off for everyone.
Making Employees Happier Without Increasing Salaries
5 months ago
by integgroll
in Something Else
Earlier today I read an article titled 9 Things That Motivate Employees More Than Money. When I see an article titled like that one is it tells me that the person who wrote it is not your average employee. I can assure you of one thing, your employees are just as motivated by these techniques in the long run as much money that you spent on them. the following are my suggestions on what you can do as management to help make happier employees, and at the same time not increase a persons salary.
1: Remove any sort of formal dress code. Being in the tech industry I am going to be biased on this one, and for good reason, the last time I saw a customer is when I ran into one of them at a Starbucks after hours. That customer did not know who I am, and had no idea who I worked for. Requiring someone like myself to wear a tie, or even slacks and a dress shirt every day does nothing for my professionalism or job doing ability. If you are the sort of person who does have improvement in their productivity with no loss of morale, by all means dress up, but do not make it a requirement for everyone.
2: A good Work From Home Policy is a requirement for a company that is looking for happier employees. I am not saying that you can send all of your employees for 100% work from home without any thought on the matter. But at the same time you should have some sort of offering that shows your employees that you trust them to do their work without Big Brother looking over their shoulder all day long.
3: Removing Ghost Workers is one of the things that will help improve morale more than anything else. Do you remember how two years ago Sally quit, or was fired, or was let go so that someone could “cut costs” and get their bonus? Do you remember handing out all of her tasks to people around the office in the interim? Did you ever end up hiring someone to take those tasks back? Did you ever increase the people’s pay who took over those tasks? In my experience, one of those things never happens, and it should. You cannot expect your employees to take over tasks that they were not hired for, with the same salary as when they were hired; even if the job market has them too scared to leave over it.
4: Fire Incompetent Employees. No one likes that guy in your office who has no idea what they are doing. They don’t like it when they fill out an email chain in order to find out who exactly should be doing what task. They very much don’t like constantly having to fix that person’s problems. Yes it costs money to hire new employees, yes it costs less to “re-purpose” that person and get them on the right track. It also pisses off your employees, especially when you end up promoting this person just to get them out of the development team.
5: Give your employees a share of the company. No, I do not mean give them a twenty dollar gift with the company logo on it every 5 years. My general rule is, if you don’t want it, they don’t either. I mean give them a share of the profits. Yeah that means that I think that your Board of Directors, and C-Levels do not deserve the bonuses that they are getting. Yes, those people make the decisions that make the company happen. No, they do not do the actual work that ends up making that profit. Do I think a janitor deserves the same bonus as a programmer who writes your software? No, I am not completely ignorant, but when the company makes money as a result of your employees, so should your employees.
6: Stop trying to come up with ways to make your employees happy without spending more money.