xenoterracide's blog

OpenWRT static DHCP

2009-07-06T02:47:00.005-04:00

I use OpenWRT on my Linksys WRT54GL, all shell, no web interface. My basic problem is that both me and my roomate need ports forwarded from the internet to our systems. This means NAT, for nat you need to know the IP address that you're forwarding too. I could just 'static' the IP on our boxes and then set up the NAT. This is not the correct way to do things, as it would be much more difficult to keep track of who uses what IP and make sure that dnsmasq doesn't give out our static-ed IP's. Also when you static an IP on the client side that usually means setting dns, and remembering to unstatic it when you move. So we really want our dhcp server to give out the same IP address to a given mac address. to do this in OpenWRT you need to edit /etc/ethers.local the syntax of that file is basically


mac ip
mac ip

mine currently looks like this.

00:1e:8c:09:e7:13 192.168.1.2
00:21:9b:06:4c:c9 192.168.1.3

These 2 computers will always get the same IP address while any other computer on the network may get a random IP address. After editing this file you need to run /etc/init.d/luci_ethers start which will then generate /etc/ethers which is what is actually used. You could also reboot the router but that is unnecessary.

To pointer, or not to pointer: That is the question

2009-06-27T17:53:00.005-04:00

For a very long time now I've been looking for good explanations of pointers, and how the varying kinds differ.I've finally found a book that does a good job of explaining what they are and how they differ. The book is by Bjarne Stroustrup (the creator of C++) it's called Programming -- Principles and Practice Using C++
The book is supposed to teach you how to program (become a good programmer) using C++ not teach the C++ language. The question that Stroustrup poses is How do we choose between using a reference argument and using a pointer argument? his answer to the question is quite in depth, however I'll reiterate his summary here in the hopes that it's useful for someone.

So, the real answer is: "The choice depends on the nature of the the function":
For tiny objects prefer pass-by-value.
For functions where "no object" (represented by a 0) is a valid argument use a pointer parameter (and remember to test for 0).
Otherwise, use a reference parameter.

Ok, that alone seems a little confusing. I'm just going to use function declarations to denote the differences in code.

According to him, pass by value is the least error prone, but it copies memory and is therefore more expensive. To do this you'd declare a function like int func_name(int x);.

"No object" in my quote is another term for "Null pointer" which he defined previous to this but wasn't in my quote. If no argument to the function is valid you'd use that. It's declared like int func_name(int* x);

The last option is to use a reference pointer. these are declared as int func_name(int& x).

I still have some trouble with the what/why/when to use pointers, but I'll probably just go back through this a few times. Stroustrup's explanation is still the best I've seen. I'd suggest his book to any novice programmer. I'm not sure if it's the best for someone who's never seen any code as it goes quite fast. It doesn't spend hardly any time at all on language constructs, which most books do. I don't think so fast that you couldn't use it as a 'first programming book' but it might be good to have a book that covers the constructs (like for loop) in depth.

iptables browsing samba shares

2009-05-16T00:37:00.004-04:00

NOTE: this assumes that you've read my previous post on basic iptables setup on the desktop

So I just spent the longest time trying to determine what ports I needed to browse and use samba shares. The sad answer is it's just one.


iptables -A INPUT -p udp --sport 137 -j ACCEPT

the catch with all the information I found with google was that most of it was for samba servers. I didn't want that. I just want to be able to browse my roommates network shares, and download from them. None of the information google provided suggested I need to allow the source port on the other end.

Git Presentation

2009-05-11T16:27:00.005-04:00

I'm doing a git presentation and the Lansing Coldfusion User Group tomorrow night. Anyone who wants to is welcome to come Below are the slides for the presentation.

EDIT: I don't know why but google doesn't show all slides formatted right in mini mode. It's cut off some of the text and overlapped some things.

Jeff Atwood fails at password security

2009-05-06T19:10:00.010-04:00

This was originally written for a class assignment and as that has not been modified (much) for the web.

Jeff Atwood's password was compromised, the following includes a summary of how it happened, and how better security policies could have avoided it. This was written for Advanced Report Writing at Baker College.

Summary of Article

On May 3, 2009, Jeff Atwood reports that his Stack Overflow password was compromised an that he received an email explaining the details. The following is an excerpt of that email, that was posted in his blog post.

How? Well, there were two pieces of the puzzle, the password and the openid provider. I had a possible password; today your blog post revealed the openid provider. I logged in, freaked out that it actually worked, then logged out. The only reason I had the password is because your password is totally inadequate for someone running a site like StackOverflow. I don't want to go into any more detail than that, but man - dictionary password! -A friend of the site (Atwood, 2009)

Jeff confirmed that the authentication logs for Stack Overflow did include a valid login from an unrecognized IP address. Although Jeff defends that his password was not a dictionary password. He also states that this particular OpenID account is for low security transactions online, and not particularly valuable. He digresses that because this account is a Stack Overflow moderation account, with special privileges, that he should have used a more secure login.

Jeff goes on to explain, the various ways which the account could have been compromised. The first method he describes is the "educated guess". An educated guess basically uses what you know about someone to guess there password. The second is "Brute force dictionary attack". Jeff describes this as an attack vulnerable to non-rate limited logins where the password is a word out of the dictionary. The third method described is "interception". This method is basically where the password was captured at some point between the user and its destination, this could be kelogger, packet sniffing, and/or simple lack of encryption. The final method was "Impersonation" where a site pretends to be a different site, and prompts you for credentials, this is also known as phishing.

Jeff presents that none of these methods were used to compromise his account.

I guess I can tell you, so you don't fall into this trap again. There's a site I help out with that doesn't salt their passwords. They're MD5 encrypted, but if you've got a dictionary password, it's very easy to use a reverse-MD5 site to get the original. I was able to figure out you were a user on the site some time back, and realized I could do this, if only I knew your openid provider... (Atwood, 2009)

Jeff then re-iterates that he is to blame, and this is a problem with programmers at large. He then suggests that programmers should get out of the business of storing credentials, if they don't want to take responsibility for it.

Evaluation of the Article

Jeff Atwood, is a fairly famous ~~full time blogger~~ entrepreneur, software developer and blogger, and often seen as an authority in the community. He is self admittedly not an expert and these articles truly show this. Jeff's articles will undoubtedly lead many programmers to be confused and ignorant about the types of attacks possible and the type of attack that actually took place. One good thing does come from these articles however. It increases developer awareness (and hopefully user) awareness of just how easy it is to compromise a password and how inadequate there own authentication systems may be.

Jeff seems to not understand the basics of all the attacks he's described so I will elaborate on what they really are.

1. Educated Guess: Jeff mostly has this right, however, in the article he calls this in with social engineering. It is in no way shape or form social engineering. Social Engineering generally requires convincing someone to give you information. An educated guess requires that you use information you already have to break the password. In a sense this was used to gain the login name, although it was not a guess, it was known. I once used an educated guess to break into the account of someone based on there age, gender, race, and password hint, none of which I had to gain any additional information on. note: my cracking of this account was 100% legal as it was authorized by the computer owner.

2. Brute Force: This is combined with 'dictionary attack' and although the two are often combined they are separate attacks. A brute force attack is simply generating account credentials (username password typically) with an automated computer program and sending them to the system you are attacking until it lets you in, until you are permanently blocked, or until you give up. A brute force attack is 100% successful unless somehow stopped as it will eventually try all combinations. The exception to this is when the password could be changed to a password already tried during the attack. This only works on a live system however, if the attacker manages to gain a copy of the password db they can attack at their leisure and may instead get a stale password. It can mostly be prevented by locking users out after a certain number of failed attempts.

3. Dictionary Attack: A Dictionary attack, although it does reference words from an actual dictionary, such as Webster's, it is not limited to just those words or even words. Dictionary attacks consist of lists of words which may come from any language, including fictional ones like Star Trek's Klingon, slang, names and pop culture references. Because of modern security standards they will often append, and prepend numbers to the words, and even change case around. Dictionary attacks may also include coded words such as 1337 also know as leet or l337 or l33t, etc. 1337 is a substitution cipher popularized online which substitutes letters for numbers that slightly resemble letters. A dictionary attack is usually run before a brute force as it is much faster, and has a high probability of success compared to time used. It can be mostly prevented by forcing users passwords to be compared against known dictionaries (such as cracklib) and making sure their password isn't in them, and forcing them to pick something else if it is.

4. Interception: Interception is another name for "the Man in the Middle" attack, which is
what it more commonly goes by. Jeff seems to be under the assumption that "Man in the Middle" requires the attacker to get the credentials verbatim. "Man in the Middle" basically means getting the data after the user enters it and before it reaches it's destination, this include keyloggers, screen scrapers, and packet sniffers. it may include other methods I'm forgetting. "Man in the Middle" is easily prevented by user strong 'stream encryption' in which all data sent between the client and the host is encrypted, SSL is commonly used for this on websites, note the 'lock' icon, in your browser. This is different from hash encryption which is how the password is (should be) stored as it encrypts all data being transferred including the username and password hash.

5. Impersonation: Or Phishing is a form of social engineering in which you pretend to be something you aren't and attempt to get people to give you sensitive data such as account credentials. It is most commonly done by creating a website which closely resembles the site for which you are trying to get credentials for, and then sending out emails to try to get people to log in.

6. Social Engineering: Social Engineering is simply misrepresenting yourself to get information. It can go as far as full blown fraud, or as simply as talking a person into giving me what they may not even believe is sensitive data. One could for example talk to someone, get there name, mention that they knew a woman who married a man with that last name and ask for a mother maiden name, pretending like they knew her. A mothers maiden name is a highly common question to prove identity in account verification and password resets online. People have also dressed up and walked into nuclear power plants with clipboards making themselves look like they belonged there, and were never stopped. An IT guy asking for your password may also be social engineering, as you think you should trust him. Social Engineering may be used to get account credentials or to formulate an educated guess.

7. Rainbow Tables: Rainbow Tables are databases of all possible straight password hashes up to a certain number of characters, and there corresponding passwords, these hashes may or may not be included with a dictionary attack, they typically include the full contents of a brute force. The largest Rainbow tables includes all possible combinations up to 8 characters for md5 hashes. These make reversing a hash from a password instant and easy. It still requires the attacker get the hash in the first place, this is usually done by "man in the middle", SQL Injection, or compromising the database server. This can generally be avoided by salt-ing the hash making it more difficult for the attacker to get the original password.

Jeff's Password was lost due to a combination of attacks. Firstly was public information, his 'user' credentials (OpenID) were publicly available (this isn't actually an attack), the second was "Man in the Middle", as obviously no one published the hash, so it had to be gotten somehow enroute (unless the db was cracked). The third was "Rainbow Tables" which allowed the attacker to reverse the hash into a real password. I don't believe that Atwood truly understands the attack vector's, and I don't think that people should read these articles for learning purposes. It is good though that he accepts some responsibility for lack of proper security practices on a sensitive account.

In my opinion this is what's wrong with programmers, they think they know better and instead of learning how to do it correctly and all the things that could go wrong, they just go ahead and do.

Atwood, J. (2009). I Just Logged In As You. Retrieved
May 6 2009, from Coding Horror
Web site: www.codinghorror.com/blog/archives/001262.html

Atwood, J. (2009). I Just Logged In As You: How it happened. Retrieved
May 6 2009, from Coding Horror
Web site: www.codinghorror.com/blog/archives/001263.html

EDIT: Sincerest apologies for originally spelling Atwood as Attwood and spreading misinformation about about his profession. Thanks to Stu for pointing this out. For some reason I thought those were both true, and did not check them, since I've been reading Coding Horror for at least a year.

@Grade I'll post it next week when I get it

@Spelling errors, I had reinstalled my system the morning of writing and apparently had forgotten to configure it. They should be corrected now.

@Assignment the assignment was not an essay but the evaluation of an article, and its content. It didn't require me to cite any sources for why I agree or disagree with the article.