Been busy but I still wanted to post something quick.
If you didn't know, F-Secure's yearly reverse engineering challenge, Khallenge, is about to start. It works by using levels - you download a binary, figure out how to reverse it and get the password to the next level. I've done it in years past and have gotten to the last level but not beyond. Maybe I'll try this year. It starts August 1, 2008 at midnight (EEST) which should be about 5PM July 31, 2008 EST. It lasts only two days so get out there and reversing! http://www.khallenge.com/
There are many excellent blogs out there which have alot of great information on reverse engineering and malware analysis. However, I want to call out one which I consistently find excellent information on new threats and how to perform malware analysys: The Websense Security Labs Blog.
I'll be the first to admit that when I think of Websense I think of content filtering and not malware analysis. (Actually I think of some poor fool who has to visit every site that gets submitted to categorize it.) However, they have some really smart people working for them who do alot of great malware analysis work. They constantly publish excellent blog entries about different aspects of malware. This is one of the blogs which I will ensure I read whenever they publish something new. Their RSS feed is here and I highly recommend it.
Anyone have any good resources they'd like to mention?
Thursday, July 31, 2008
Tuesday, July 22, 2008
Sharing Passwords
Security professionals have always beaten into our heads that we should NEVER share our passwords with anyone. For any reason. At any time.
But take the following situation.
Last night my wife got a call from an old neighbor of ours. Her aunt had died suddenly in an operation and she got a call from her frustrated uncle. Apparently, her aunt did all of the finances on the computer and did not know the password to get onto it! She called us to see if I knew how to get around the password problem.
But this got me thinking. What would happen in a situation like this with my wife and I? She doesn't know any of my passwords and I'm pretty sure I don't know hers. If something happened to us, would we be able to get into the sites the other pays things on?
The obvious solution is that we either use the same passwords or share the ones we need to know. But, sharing passwords is bad, remember? Unless you can do it securely.
While I was looking around, I found a blog post at insomnic.wordpress.com talking about this. IMO, its a pretty decent solution - use a secure password keeper program that both you and your spouse have access to. By keeping the passwords in there which you both need to know, then you are covered in the event something happens to one of you.
Yes, there is now the problem of having the "keys to the kingdom" in one spot covered by one password...but that happens anyways when you use a password keeper program. I believe as long as you are careful in the password you create for that, you should be good.
Does anyone do this now? Does anyone have any other solutions? I'm honestly curious how others do this.
But take the following situation.
Last night my wife got a call from an old neighbor of ours. Her aunt had died suddenly in an operation and she got a call from her frustrated uncle. Apparently, her aunt did all of the finances on the computer and did not know the password to get onto it! She called us to see if I knew how to get around the password problem.
But this got me thinking. What would happen in a situation like this with my wife and I? She doesn't know any of my passwords and I'm pretty sure I don't know hers. If something happened to us, would we be able to get into the sites the other pays things on?
The obvious solution is that we either use the same passwords or share the ones we need to know. But, sharing passwords is bad, remember? Unless you can do it securely.
While I was looking around, I found a blog post at insomnic.wordpress.com talking about this. IMO, its a pretty decent solution - use a secure password keeper program that both you and your spouse have access to. By keeping the passwords in there which you both need to know, then you are covered in the event something happens to one of you.
Yes, there is now the problem of having the "keys to the kingdom" in one spot covered by one password...but that happens anyways when you use a password keeper program. I believe as long as you are careful in the password you create for that, you should be good.
Does anyone do this now? Does anyone have any other solutions? I'm honestly curious how others do this.
Friday, July 11, 2008
My First Malware Analysis
For some reason I was thinking about one of the first malware analysis/reverse engineering attempt I did. It was about 7 or 8 years ago (wow) and I was looking at a RedHat 6.2 web server. I had been given an account there from a local business in order to make sure the security of the server was up to par.
I tried to recreate this as much as possible to give a visual reference. Since I'm going by memory I'm sure I missed something so please forgive me.
While looking over the server I noticed there was an interesting account in /etc/passwd with a UID of 0 named toor. For those not in the know, a UID of 0 on a *nix box is the super-user account on the system. The games user, which no one should be able to log in as, had a password assigned to it. Soon, I found a directory named "..." in /dev, and within that directory were a number of tools.
Additionally, while most of the system logs had mysteriously disappeared, those that were left had a number of messages stating the server was in "promiscious mode". This server had been compromised.
This was really my first attempt into forensics and at the time there were no computer forensic resources available to non-LE folk (or at least I didn't know of any). In other words, looking back I did a number of things I wouldn't do now.
I copied the tools down to my local computer and started looking it over. The files I remember were:
Through reading the files which came with the source I found that the rootkit would backdoor the login process (and a number of other files) such that anyone could log in or become root by knowing a secret, hard-coded password. I had the overwhelming urge to figure out what that password was. The default password of "satori" did not work, so I had to come up with a way to figure it out.
So, I started to reverse the backdoor program in order to determine how to find the password. I still use these techniques when RE'ing malware today.
I ran strings on the program to see if I could pick out the password. Nothing jumped out at me as a potential password, but I did see a number of gcc and glibc version numbers within the binary which told me it had been compiled on a RedHat 6.2 box. In my mind, that meant I could take the source, change the password to something I knew and look for it in the binary. With any luck, I could look in the same place on the rootkit'd server and find the attacker's password.
So thats what I did. I changed the password in the source code to a password which I knew and compiled the login binary. Due to the way the binary stored the backdoor password, strings did not see it.
I opened up the binary in a hex editor and started searching for my password. Eventually, I was able to find the password and record its offset. In the picture below. the password starts at offset 0x196f and the each letter is a few bytes after.
I grabbed the backdoor'd file on the compromised server, threw it in a hex editor and found what looked like it could be the attacker's password. (In the picture below the password is "pebcak".)
To test it, telnet'd to the compromised box and logged in as a normal user with the backdoor password...successfully! I then su'd using the backdoor password and I was root! Needless to say, I sat there for a few minutes with my eyes wide open that it actually worked.
Would this work now on a modern Linux system with the same type of rootkit? Possibly.
In a few days, I'll post part two of this where I analyze what I did wrong forensically and how it should have been handled.
I tried to recreate this as much as possible to give a visual reference. Since I'm going by memory I'm sure I missed something so please forgive me.
While looking over the server I noticed there was an interesting account in /etc/passwd with a UID of 0 named toor. For those not in the know, a UID of 0 on a *nix box is the super-user account on the system. The games user, which no one should be able to log in as, had a password assigned to it. Soon, I found a directory named "..." in /dev, and within that directory were a number of tools.
Additionally, while most of the system logs had mysteriously disappeared, those that were left had a number of messages stating the server was in "promiscious mode". This server had been compromised.
This was really my first attempt into forensics and at the time there were no computer forensic resources available to non-LE folk (or at least I didn't know of any). In other words, looking back I did a number of things I wouldn't do now.
I copied the tools down to my local computer and started looking it over. The files I remember were:
- A psybnc IRC eggdrop
- A sniffer which would scan traffic for credentials and save them to a file. A file was also present which contained a few credentials which had been captured.
- A number of log cleaning utilities
- A rootkit.tgz file which contained compiled binaries and not source code.
Through reading the files which came with the source I found that the rootkit would backdoor the login process (and a number of other files) such that anyone could log in or become root by knowing a secret, hard-coded password. I had the overwhelming urge to figure out what that password was. The default password of "satori" did not work, so I had to come up with a way to figure it out.
So, I started to reverse the backdoor program in order to determine how to find the password. I still use these techniques when RE'ing malware today.
I ran strings on the program to see if I could pick out the password. Nothing jumped out at me as a potential password, but I did see a number of gcc and glibc version numbers within the binary which told me it had been compiled on a RedHat 6.2 box. In my mind, that meant I could take the source, change the password to something I knew and look for it in the binary. With any luck, I could look in the same place on the rootkit'd server and find the attacker's password.
So thats what I did. I changed the password in the source code to a password which I knew and compiled the login binary. Due to the way the binary stored the backdoor password, strings did not see it.
I opened up the binary in a hex editor and started searching for my password. Eventually, I was able to find the password and record its offset. In the picture below. the password starts at offset 0x196f and the each letter is a few bytes after.
I grabbed the backdoor'd file on the compromised server, threw it in a hex editor and found what looked like it could be the attacker's password. (In the picture below the password is "pebcak".)
To test it, telnet'd to the compromised box and logged in as a normal user with the backdoor password...successfully! I then su'd using the backdoor password and I was root! Needless to say, I sat there for a few minutes with my eyes wide open that it actually worked.
Would this work now on a modern Linux system with the same type of rootkit? Possibly.
In a few days, I'll post part two of this where I analyze what I did wrong forensically and how it should have been handled.
Tuesday, July 8, 2008
When will VirusTotal add this one in?
At first I thought it was a joke, but nope. Hello Kitty Firewall and Anti-virus software is real!
Download it from http://www.kittyav.com.tw/ and try it out.
Download it from http://www.kittyav.com.tw/ and try it out.
Wednesday, July 2, 2008
Akron's Free City-wide Wireless
It looks like Akron is moving forward with its plan for free city-wide wireless. The city has just committed $800K over the next 5 years and is also being backed by various organizations to the tune of $25M.
I think this is a horrible idea, as is any free city-wide wireless. Ignoring the costs associated with it that tax-payers will have to shell out, I have not seen word one anywhere on how the security of the network will be handled. Part of the article says:
1. Free wireless typically means unencrypted wireless. That means that anyone within proximity of anyone else can see their traffic...the sites they visit, the emails they read, the credit cards they use, the passwords they have. Think it won't happen? I can guarantee the entire city will be wardriven the first day this is opened.
2. I have heard it touted that businesses would be able to use this and save money. Be careful on that! Businesses who take credit cards for payment have to comply with PCI DSS and depending how they handle their cc's, using free and unencrypted wireless may be a violation of that.
3. Free wireless means anyone can use it...even criminals. I can see a number of scenarios here. First, there are now potentially 80,000+ victims on an open network now. If I'm a computer hacker I can drive around and break into these PCs, install my malware or steal information, and own the box before I'm long gone. Except through the C&C, how are you going to trace it back to me?
Second, what about child pornographers? I have to think that free wireless which is city-wide would be a dream come true for them! They want to share their pics? Drive down to Akron for 20 minutes, jump on the wireless, send everything through and drive away. Probably pretty hard to track down.
4. Who is going to be monitoring this? What privacy policies, if any, will be in place? Is there going to be a clause which states there is no privacy which will allow law enforcement to record traffic when they need it? (Not that I'm opposed to that) People need to consider that as well.
I'm sure this sounds like I'm being a nervous nelly on that, but these issues aren't anything the security industry hasn't seen before with businesses who have spent money to put security in place. I'll be curious to see what happens as this unfolds over the next few years.
I think this is a horrible idea, as is any free city-wide wireless. Ignoring the costs associated with it that tax-payers will have to shell out, I have not seen word one anywhere on how the security of the network will be handled. Part of the article says:
The free wireless corridor will cover about 80,000 to 90,000 city residents and about 31,000 workers. It will allow anyone with a wireless-ready computer to access the Internet for free within the district.I read that as 80,000 to 90,000 victims. Lets look at the security issues regarding giving over 100,000 people (when you include the workers) free Internet access.
1. Free wireless typically means unencrypted wireless. That means that anyone within proximity of anyone else can see their traffic...the sites they visit, the emails they read, the credit cards they use, the passwords they have. Think it won't happen? I can guarantee the entire city will be wardriven the first day this is opened.
2. I have heard it touted that businesses would be able to use this and save money. Be careful on that! Businesses who take credit cards for payment have to comply with PCI DSS and depending how they handle their cc's, using free and unencrypted wireless may be a violation of that.
3. Free wireless means anyone can use it...even criminals. I can see a number of scenarios here. First, there are now potentially 80,000+ victims on an open network now. If I'm a computer hacker I can drive around and break into these PCs, install my malware or steal information, and own the box before I'm long gone. Except through the C&C, how are you going to trace it back to me?
Second, what about child pornographers? I have to think that free wireless which is city-wide would be a dream come true for them! They want to share their pics? Drive down to Akron for 20 minutes, jump on the wireless, send everything through and drive away. Probably pretty hard to track down.
4. Who is going to be monitoring this? What privacy policies, if any, will be in place? Is there going to be a clause which states there is no privacy which will allow law enforcement to record traffic when they need it? (Not that I'm opposed to that) People need to consider that as well.
I'm sure this sounds like I'm being a nervous nelly on that, but these issues aren't anything the security industry hasn't seen before with businesses who have spent money to put security in place. I'll be curious to see what happens as this unfolds over the next few years.
Subscribe to:
Posts (Atom)