Wednesday, September 29, 2010

Public Networks and Torrents

I must advise against using networks without permission, as this violates laws for many states in the U.S. including my state, Arizona. This article assumes you have full permission to use the networks in question and that the techniques herein have been explicitly (or implicitly) deemed acceptable and appropriate for your purposes.

I've heard things like "torrents are illegal;" they're not. Transferring copyrighted content may be, depending on your country. So here is my opinion on the morals and ethics of copyright infringement, et al. ... Just kidding, I find the moral and ethical talk about file sharing a bit boring. So lets talk about the problems people face when attempting to leap technological hurdles instead!

Problem one: How to connect to a network but reduce or segregate the information collected about your specific machine at that time?
Often you don't have to prove anything about yourself on networks, so why sign your name on every piece of data? Wireless networks are all over the place. Once you're given permission and you have that green light to access a network as you wish, you have the leeway to modify your MAC address.

Many systems rely on your MAC address as a 'static' element of your communications. For instance, DHCP servers record your MAC address when supplying an IP address with a lease period. This is because generally your MAC address won't change as you use a network consistently for an hour. In fact in general your MAC address doesn't change when you leave a network and come back a week later. So a DHCP server can keep track of what your most recent IP address was for at least the lease period. However, your MAC address is not a static element of your communications. Changing it often can even provide some benefits. Like controlling the types of traffic your network is routing, or increasing anonymity through diffusion.

Depending on your personal computer there are different ways to change your MAC address. We'll cover the Windows 7 way and a Linux way here:

Using Windows 7:

  1. Start-> Control Panel
  2. Network and Sharing Center
  3. Change Adapter Settings
  4. Right click on your adapter of choice (I use my wireless), disable
  5. Right click on your adapter of choice (I use my wireless), select Properties
  6. Click Configure
  7. Click Advanced Tab
  8. Look for anything related to your MAC address (varies per driver), modify it and save all your changes.
  9. Right click on your adapter of choice (I use my wireless), enable
  10. Confirm in a command prompt by running ipconfig /all to determine if your MAC address changes have taken effect (you should also have a new IP addres).
Linux systems:

  1. ifdown [interface]
  2. Run ifconfig [interface] hw ether [MAC]
  3. ifup [interface]
  4. Confirm by running ifconfig [interface] to make sure the changes have taken effect.
Finally, connect to your network of choice.
Problem two: We're connected, we feel fresh and clean, but we can't seem to connect to the BitTorrent network?
I use a lot of wireless networks, coffee shops, work, bars, libraries, schools, airports, city, you get the idea. Occasionally these networks will limit the types of connections leaving and entering them in part as a safety precaution for the users on the network. A common type of limitation is port restrictions on everything but port 80/443 traffic.

When you only have web channels available but you still really need to torrent that new release of Back Track, you just need to convert your torrent traffic to web traffic. Using a torrent client which supports proxies is a great way to maximize your throughput and control the type of traffic your moving - not to mention depending on the network you've been given this free reign on it can provide you just that a little more anonymity to the rest of the BitTorrent network. Since you're on a public network, you're fresh and clean, it could be anyone located in your geographical location and connected to the same network. 

Just select any proxy which is available to you that runs on port 80 and configure your torrent client to use this proxy. Ideally you'll have a high bandwidth path to the proxy and you'll be able to encapsulate your torrent traffic into web traffic allowing you to access the BitTorrent network.


Tuesday, September 28, 2010

Scanning Internal Networks Through Exposed Proxies

Proxies are a really cool idea. They provide us with a way to get to places we couldn't before. A way to hide our true identities from the outside world or in some cases a way to hide our true identity from an inside world. Some networks of interest have such a proxy and it should pique your curiosity about what it provides the outside world when looking in.

This was discovered by looking at a homepage which links to some internally available service. The web server providing the exposed proxy looks typical:
And contains an image from a web cam that has a source that looks like this:
Fascinating, IP addresses starting with 10 are defined in RFC1918 (section 3) as being private. So does this mean we can make a web request to[desired content] and it'll just pass it along? Lets give it a try, load up a browser and load:
The results are not only as expected, but exciting! Google appears to be the web page served. But how far can this proxy really go? I wonder...
Now a more interesting result. Choosing another network which I am aware has a web server running on the non-standard port of 84 we see the slightly less expected result that the proxy actually forms a connection anyway. This means its not confined to web services on port 80 or 443! This is interesting but not exactly as useful as the title implies. We're really just bouncing off the proxy to get back to the Internet from the Internet. But we still have the internal IP address lingering in that source attribute, so if it works one way, surely it works the other way?
Praying for an SSL service. "Service is currently unavailable" I think this means "No Dice." This error was received after a significant delay, which means the proxy itself must have been waiting for the TCP/IP connection timeout before actually responding. That's good, since it means it tried and as expected did not rewrite the port to 80. Maybe another host would be more interesting? --Nope --Nope --Nope --DING!
Awesome, another web server. Contains miscellaneous content of no consequence, but it also has some content that leads us to believe there could be another service running. Lets give it another try... --Nope --Nope
... --Nope --DING!
No way, really? Port 23 is for Telnet, convenient and very interesting. The result is we're served with a 'file' which we go ahead and download it into RAM, since we'll probably be throwing it away, and what do we see?
[Telnet Stuffs]
[System Banner]
Enter Password > 
   ERROR - Timeout
Awesome, it is a telnet server, we've got a nice little banner in there too for the type of system it is running on. We can't go much further than this on that one host (nor would we want to), but as you can see we can easily scan for services of interest on the internal network from the Internet at large.

What is one of the most interesting questions here is: what about firewalls? What are the expected trust boundaries and how do they compare with the actual trust boundaries? Depending on the different web services available and of course other configuration issues, this proxy is likely side stepping a firewall and could be putting a huge chink in the perimeter of the owning network.

Monday, September 27, 2010

Powershell: Start-BitsTransfer & User Authentication

I recently discussed an issue with ActualReverend (alright it was a month and a half ago and I'm just now blogging about it) concerning Powershell and using Start-BitsTransfer against a web server requiring user authentication. Additionally, this is my first time ever using Powershell for any task more than running 'ipconfig /all'. So I suppose we'll start with our problem statement:
"Using 'Start-BitsTransfer', download a file from a web server (an apache/svn service), which requires user authentication against an LDAP server, to a given location. Path is '/path/file.ps1' user credentials are 'username:password.' "
Should be a fairly simple script, he needed it for more but I am mostly interested with why it's not working as expected.
$creds = Get-Credential
Start-Bitstransfer -Source -Destination C:\destination\ -Credential $creds -Authentication basic
Pretty straight forward script. It prompts the user for their credentials we enter "username" and "password" as that's our credentials. The authentication type is basic, and the server is properly configured to goto LDAP, so we're ready to Rock 'N Roll... But the results are of course not as expected, let's see the error.
Start-BitsTransfer : HTTP status 401: The requested resource requires user authentication.
Well, damn. We thought that providing the username and password pair would cover us but something went wrong and the error is not as forthcoming with the cause as we'd like. We provided credentials and the fact that we wanted the cmdlet to use authentication, so what the hell? Maybe our server logs will provide some insight.
[Thu Aug 19 13:30:50 2010] [error] [client] user \\username not found: /path/file.ps1 
 Ah ha, so our user isn't found. Thats weird though why is there a '\\' preceding our username, we didn't enter that! Lets inspect our object $creds and see if it supports this outrageous server log claim (hopefully identify the source of the hiccup).
PS C:\Users\username>$creds 
UserName              Password
--------              --------
\username             System.Security.SecureString
PS C:\Users\username>
Huh so, there is our issue. Our LDAP server certainly has no idea who '\username' is. So our Username property in our... wait what type of object is this? Running $creds.GetType() shows us its a 'PSCredential' type. The MSDN shows us this is in the 'System.Management.Automation' namespace. So in theory I can use the New-Object cmdlet to make a new object with the contents of the old object and clean it up, right? Right!
PS C:\Users\username> $creds = New-Object -TypeName 'System.Management.Automation.PSCredential' -ArgumentList $creds.Username.Remove(0,1),$creds.Password
Alright,  lets check out our object now...
PS C:\Users\username>$creds 
UserName              Password
--------              --------
username             System.Security.SecureString
PS C:\Users\username>

Very cool, so lets try it out (cross our fingers):

PS C:\Users\username> Start-BitsTransfer -Credential $creds -Source "" -Destination C:\destination\ -Authentication basic
PS C:\Users\username> 
VoilĂ , we're now providing our user credentials successfully and downloading the file we want without error! Powershell, you have just made my Windows using experience that much better.