When Windows Hosts Files Stop Working

So, working on what should have been a quick PowerShell script today, I ran into quite the hiccup. Annoying as hell.

My Hosts file on my Windows 7 Machine stopped working!

This was a rage inducing issue for me. But luckily I think I've identified the "problem." And yes, it is technically PEBKAC - but I think Microsoft should carry a little of the blame too.

First let us set the stage with a very basic PowerShell script to setup the hosts file the way we'd like.

$hosts = @()
$hosts = $hosts + [String]::Format("{0} {1}", "192.168.0.1", "some.local.domain")
$hosts = $hosts + [String]::Format("{0} {1}", "127.0.0.1", "www.somesite.com")
$hosts > $env:windir\system32\drivers\etc\hosts

Note: This must be run with appropriate permissions to write to the hosts file!

Pretty straight forward, make an array, add two strings to it with formatted IP/domain pairs. Write the array out to the file. When this is all said and done you should have something which looks like the following:

This is what we would expect. A hosts file with two entries that says some.local.domain -> 192.168.0.1 and another entry that says www.somesite.com -> 127.0.0.1.

Looks correct to me - and if you're reading this yours probably looks correct to you too. But as you can see the ping commands are not resolving based on the IPs in the hosts file! This is certainly not the desired effect. As if the hosts file were being "skipped."

What's the deal?

The error that resides in the above script does not reveal itself when opening the hosts file in your text editor. And in fact in some text editors it'll exist all of the time. Why you ask?

Simple; Your text editor probably detects and allows you to edit Unicode files. Optionally your text editor only supports Unicode files.

Yep, the whole annoying as hell bug - is just a simple encoding problem.

Here's how I noticed it - I opened my hosts file in a hex editor (HxD in my case, cause it's free). Viewing the raw hex we see:

This thought occurred to me as a mere suspicion. I did what I've seen a number of sources say to do: open the hosts file, copy it's contents, remove the hosts file and then re-save the contents using just plain-ol'e notepad. This does work, but it's not a solution for automation in the case of scripts (like I need it to be).

Also remember notepad will save it with the extensions .txt and you'll need to rename it.

So this works, in theory, because when notepad saves the contents it saves them in ASCII and stripping the Unicode encoding. Which is seen when viewing the contents of the new hosts file in HxD:

So, how does one fix the PowerShell script to work too? You're in luck,  it's an easy fix. Annoyingly easy after so many hours bashing your head against a keyboard over nothing.

Setup your array in the same way, when you're ready just pass your array to Out-File like so:

$hosts | Out-File -Encoding ASCII -FilePath $env:windir\system32\drivers\etc\hosts

And now, you should have similar - but better - results! Notice how notepad looks exactly the same! But the pings resolve the correct names, etc. Thus confirming my hypothesis.

That's it, I hope this helps someone. So as usual....
Hack Legal, Hack Safe, buy most of all Hack Fun!
Until next time...

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.


Cheers

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:

http://some.network.com/

And contains an image from a web cam that has a source that looks like this:

http://some.network.com/proxy/10.1.1.2/jpg/fullsize.jpg

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 some.network.com/proxy/[desired content] and it'll just pass it along? Lets give it a try, load up a browser and load:

http://some.network.com/proxy/www.google.com/

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...

http://some.network.com/proxy/some.othernetwork.com:84/

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?

http://some.network.com/proxy/10.1.1.2:443/jpg/fullsize.jpg

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?

http://some.network.com/proxy/10.1.1.3/ --Nope

http://some.network.com/proxy/10.1.1.4/ --Nope

http://some.network.com/proxy/10.1.1.5/ --Nope

http://some.network.com/proxy/10.1.1.6/ --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...

http://some.network.com/proxy/10.1.1.6:1/ --Nope

http://some.network.com/proxy/10.1.1.6:2/ --Nope

...

http://some.network.com/proxy/10.1.1.6:22/ --Nope

http://some.network.com/proxy/10.1.1.6:23/ --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.