All Entries Tagged With: "ssh"

Protecting your browsing with iPhone SSH tunnels

From http://c22blog.wordpress.com/

Most of the time I feel relatively secure when I’m browsing the web or checking twitter on my iPhone. That said, I rarely use the built in wireless for these purposes, and rely instead on the reasonably good 3G network in Austria. When I’m out of the country I usually try to buy a pay-as-you-go sim card and pay for the daily data transfer. This isn’t as expensive as you’d think. For example in the Netherlands it costs around €3.50 per day of data transfer. Not cheap if you’re using it long-term, but if you’re only there for a couple of days it’s a lot cheaper than paying for a hotel WLAN that’s insecure and only works inside the hotel. Still, this solution doesn’t work everywhere and isn’t for everyone. The fallback is to use whatever wireless you can find, insecure or not. This is something I’ve been fighting with for a while now. Stemming (mostly) from my unwillingness to setup a VPN server (my home ADSL isn’t good enough quality, and doesn’t have a fixed IP) or pay a huge price for a VPN solution through my existing hosting provider (thanks for the cheap hosting Dreamhost).

The iPhone (at least version 2.2.1) supports the use of HTTP proxies when connecting via a wireless connection. This is great. Surely I can setup an SSH Tunnel to my server and tell the iPhone to use this as a SOCKS proxy. As with everything on the iPhone however, simple always turns into complicated very quickly. I experimented with this solution and found that the HTTP proxy support was really just that, HTTP proxy support and nothing else. So back to the drawing board. I searched for another solution and settled on using the 3proxy application (in cydia for those lucky enough to have a jailbroken iPhone) to setup a local HTTP proxy.

A few requirements to get this up and running on your iPhone.

• A Jailbroken iPhone (or iPod Touch)
• SSH Client installed
• 3proxy (available in cydia)
• terminal application
• An SSH server (setup for either password or certificate access)
• Backgrounder (or some other way to run commands and have them running in the background)
• OPTIONAL: iFile (easy file editing)

Starting off we’ll take a look at the configuration of 3proxy. By using the following configuration you tell 3proxy to forward all traffic to a second proxy server, this time a SOCKS proxy (in this case my SSH tunnel).

#!/usr/bin/3proxy
daemon
auth iponly
log /var/log/3proxy.log D
rotate 5
fakeresolve
internal 127.0.0.1
allow * * 127.0.0.1
parent 1000 socks5+ 127.0.0.1 8081
proxy -p8080 -a -i127.0.0.1

The quick rundown on the above configuration.

• #!/usr/bin/3proxy – Tells the script what interpreter program to use
• daemon – Tells 3proxy to run as a background process
• auth iponly – sets the authorization to be ip restricted
• log – Setup a log that rotates daily (the D option)
• rotate 5 – Sets the number of log files to keep before rotating
• fakeresolve – Tells 3proxy to route DNS lookups through the proxy
• internal – Listen in the internal interface only
• allow – Currently set to * for all (you can limit this by username/password or IP, however this caused issues in testing)
• parent – This is where we’re setting the next proxy in the chain (1000 is always use this parent, SOCKS5+ is the type and then the SSH tunnel listening ip and port)
• proxy – this final command tells 3proxy to start a proxy on port 8080 using anonymous proxy mode (-a) and listen only in internal loopback

You can find more configuration information on the 3proxy website. Although leaving the allow set to * (all) is a concern, remember that the proxy is only listening on the localhost address and from outside the port is blocked.

Now that we’ve got the 3proxy.cfg file saved (mines stored in /usr/bin with the 3proxy executable) you’ll need to run chmod +x to make it executable. Next up is the SSH Tunnel, and doing this on an iPhone isn’t much different to a normal linux system (just harder to type for obvious reasons). I opted to add a certificate for quick easy access and restricted access to the certificate to the root user on the iPhone (you have changed your root password right ???). I added the private key to ~/.ssh/id_dsa (or id_rsa, your choice) and setup a bash script to kick off the SSH tunnel (typing that command each time gets boring fast).

ssh -D 8081 -N -C username@remotehost.your.domain -2 -p 64000 -i /home/root/.ssh/id_dsa

The above command is a simple SSH tunnel setup to connect to port 64000 on remotehost.your.domain and logon as the user username using the certificate file stored in /home/root/.ssh/id_dsa. It will then setup a local listener on port 8081 and dynamically route all traffic coming to this port through the SSH tunnel. As we’re treating the tunnel as a SOCKS proxy we don’t need to have anything else setup at the other end (no other proxy server waiting to route the requests) although you could setup privoxy or any other kind of proxy if you wanted more control.

So, now that we have the two parts of our configuration ready we just need to drop to the shell and kickoff the SSH Tunnel (using your bash script), and then startup the 3proxy using the /usr/bin/3proxy.cfg command. I’ve linked it all into a single bash script to make things a little quicker.

In testing Safari works pretty well (minor decrease in performance as you’d expect). Twitterfon was the second application I tested. Although this follows the HTTP proxy rule, it still insists on doing DNS lookups for advertising outside of the proxy. This is also the case for a couple of other applications. Mail doesn’t follow the HTTP rules, however you can easily setup additional 3proxy ports for these, or use SSL and make sure your DNS is all piped over the local listener and through the SSH tunnel (3proxy supports a DNS caching proxy, tcp and udp forwarding proxies also).

Supported:

• Safari
• Twitterfon (partially: Advert DNS lookups are still a possible concern/attack vector)
• Cydia
• AppStore
• iTunes
• Youtube
• Weather
• GRiS
• WordPress (partially: As with the Twitterfon issue, the DNS appears to ignore the HTTP proxy settings)

Obviously these were just the applications I tested. I’d suggest running your own tests to ensure that you’re seeing the same results.

Not-Supported:

• Mail (setup a port forwarder to achieve support for email)
• Siphon (This is a real disappointment)
• F-Stream
• … probably more, so your mileage may vary

If you test any other applications please let me know and I’ll add it to my list.

Once you’ve finished using the SSH Tunnel and proxy, remember to kill -9 them using the console.

TODO:

• Test with alternative “allow” settings to restrict access further (username/password too easy)
• Prevent initial DNS lookup on SSH Tunnel (i.e. dyndns service)
• Log Bug with Twitterfon regardin DNs lookups
• Find an easier way to trigger the tunnel & 3proxy build-up/tear-down
• Resolve issue of tunnel disconnecting when screen gets locked (FOR loop ???)
• Use the tunnel for 3G connections (paranoid much !!!)

Maximum Risk to Maximum Security

From http://blog.sebastien.raveau.name/

(Sorry for the delay; doing now what I should have done a long time ago: split my article in two parts, as it is the second part that really keeps me back… What do you want? Being a perfectionist I can’t publish a “From Maximum Risk To Maximum Security” article until I have everything covered :P)

What I describe here should be very useful to you if you can find yourself in at least one of the following situations:

• you can use an Internet access but it lacks security (e.g. free WiFi hotspots, campus Internet, etc)
• you want to demonstrate ineffective firewalling during a pentest
• you subscribed to a 2-years contract for “unlimited mobile Internet access” – so unlimited their marketing department even named it “Illimythics 3G+” in my case – asked every rep you could if it would indeed correspond to your needs, and while none of them seemed to know what SSH is, they all blatantly assured you that it was possible… until you realized, too late, that it is in fact HTTP-only
• you feel ripped-off by a hotel reservation that you chose specifically because it advertised Wi-Fi access for customers, but once there you realize they charge extra for it.

All in all, this comes down to a simple problem: how to get a full & secure Internet access in (almost) every case?

To address this problem, we’ll rely on what I call a “stepping stone”, i.e. a computer reachable by all means, preferably 24/7, with a private full Internet access and to which we will tunnel our Internet traffic by whatever mean we have available at some point.

Now, being able to reach your stepping stone depends on what kind of traffic you are allowed on the connection you try to reach it from… Let’s enumerate them from best case to worst case in terms of usability:

1. IPSec traffic directly to the stepping stone

I cite IPSec first because it is THE standard for secure Virtual Private Network-ing and therefore available on all operating systems. However, you will only be able to use it if there is no firewall or if the firewall doesn’t filter it (cf. paragraph on IPv6 below), and if behind a NAT router, if you’re the sole IPSec user or if the router supports NAT-T.

2. any kind of traffic directly to at least one UDP port on the stepping stone

In this case the best is to use OpenVPN; if you know the port number in advance all you have to do is configure OpenVPN to bind on this port, otherwise you can redirect traffic arriving on other UDP ports to OpenVPN with Netfilter:

iptables -t nat -A PREROUTING -i eth0 -p udp -j REDIRECT --to-port 1194
I made my OpenVPN reachable on all UDP ports because every now and then I am surprised to see some exotic UDP port allowed through a firewall, no idea why… HD Moore wrote a very useful script to test that.

3. any kind of traffic directly to at least one TCP port on the stepping stone

Here you can use OpenVPN like above (but two separate configuration files are needed in order to get it to listen both to UDP and TCP) or OpenSSH tunneling.

I put TCP under UDP because TCP over TCP is considered a bad idea so OpenVPN over TCP or OpenSSH with its new VPN capability (ssh -w) won’t work as well as OpenVPN over UDP.

Personally I chose OpenVPN on TCP too because:

• using OpenSSH to tunnel to a HTTP proxy (like Squid) on the stepping stone is definitely quick to setup (ssh -L 3128:127.0.0.1:3128, and adjust HTTP proxy parameters in your browser, instant messaging client, etc accordingly), or to act itself as a SOCKS proxy (ssh -D 1080) which is even quicker if your applications support SOCKS proxying (all browsers do), but that requires having a highly-privileged daemon facing the Internet for little reason
• it sure is nice to be able to administer your stepping stone remotely with OpenSSH, but you can always do that once you’re connected with OpenVPN

And, same as above, if you know the port number in advance all you have to do is configure OpenVPN to bind on this port, otherwise you can redirect traffic arriving on other TCP ports to OpenVPN with Netfilter:

iptables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-port 1194
Like with UDP, you never know what crazy TCP port a firewall might allow. I once found a firewall that would allow me nothing but emailing the whole Internet (TCP port 25) : what the f… oh well.

4. IPv6 traffic directly to the stepping stone

While not answering the communications confidentialy aspect by itself (but it goes along with IPSec pretty well), if you’re lucky enough to have IPv6 support on both sides and if the firewall administrators were as clueless as to have a default allow policy (yes… they’re many) and as not to take IPv6 into account (usually that goes together), IPv6 is a firewall traversal mean deserving to be mentioned.

5. any kind of traffic or just SSL traffic to at least one TCP port (typically 443, the HTTPS port) on the stepping stone via a HTTP or SOCKS proxy

Many people use OpenSSH tunneling with connect.c to get through such proxies; it is indeed convenient but once again, I’m not comfortable with the security implications. Fortunately, OpenVPN supports HTTP and SOCKS proxying out of the box. You can make OpenVPN reachable on TCP port 443 and other ports like explained above.

Note: some mobile Internet operators filter access to their proxy based on the User-Agent string of the web browser shipped with your smartphone; copy it to OpenVPN via the “http-proxy-option AGENT” parameter and off you go!

6. ICMP (like ping) traffic directly to the stepping stone

If for example you are able to ping 4.2.2.2 (one of the easiest publicly pingable IP address to remember), chances are you can use PingTunnel to connect to a TCP port on your stepping stone, and from there access the whole Internet securely by using OpenVPN or OpenSSH… There are issues with some NAT routers, so you might want to try “unprivileged mode” in PingTunnel, not for security reasons (I heavily patched PingTunnel to make it super tight; you’ll see in next blog post) but because it then uses real ICMP Echo requests and replies (to the cost of throughput), which get through the NAT routers that don’t like how PingTunnel normally operates.

Also, a firewall not allowing ICMP Echo doesn’t mean it won’t allow ICMP messages of other types… Come to think about it, I’ll have to add this feature too to PingTunnel.

7. recursing DNS requests to the stepping stone via some DNS server

Now, about DNS tunneling: I put it among the last in this list because it provides less throughput than the previous solutions and really, from a protocol engineering point of view, it’s ugly… Then again, it’s AWESOME because it works almost everywhere!

In order to use it, you will need a domain name (or a subdomain at DNSTunnel.de, kindly offered by Julius Plenz) and one of the following: NSTX, Iodine, OzymanDNS, Heyoka…

Research is still active on the subject of DNS tunneling, this is why there are many tools already and more coming up. NSTX is the historical one, Iodine offers better throughput than NSTX and is available for most operating systems. OzymanDNS and Heyoka are less than a year old and still a bit proof-of-concept-ish but nonetheless interesting: the former is Dan Kaminsky’s attempt, and the latter has the highest ambition.

Personally I’m more than happy with Iodine.

8. HTTP traffic to TCP port 80 on the stepping stone through a (transparent) HTTP proxy

As the name suggests, transparent proxies transparently redirect your connections to the Internet on TCP port 80 to a local HTTP proxy; it may look like you are simply allowed TCP port 80 to the Internet, but try sending anything else than HTTP on this port, it won’t work. Good thing to know though: even if the transparent HTTP proxy doesn’t let you through for some reason, you will most likely be able to do DNS tunneling (see above) as letting the clients perform their own DNS requests is mandatory in transparent HTTP proxy setups.

Now, allowing HTTP but not HTTPS is utterly suspicious, besides breaking many web authentication procedures. Fortunately it is very rare, but in case you end up in this situation, HTTPTunnel is the way out: it will give you the possibility to connect to another TCP port on your stepping stone (and thus reach OpenVPN or OpenSSH) while making your traffic look like HTTP.

Note: User-Agent filtering can happen in this case too, see paragraph on HTTP and SOCKS proxies for solution.

9. other means of relaying data to and from the stepping stone via some reachable server

Apparently my friend Mubix has a super-secret project coming on that… in addition to having a Hak5 episode on tunneling SSH over DNS :)

As you can see, if you want to maximize your chances to reach your stepping stone and thus get a full & secure Internet access, you basically have to make it face the Internet with all TCP ports open, all UDP ports open and even ICMP tied to a daemon… While I generally disagree with the people who say a computer with 10 ports open is more insecure than a computer with 4 ports open, I have to concede that we are kind of daring the devil here…

And that is why in the other half of this article (which I’ll hopefully manage to find the time to finish within the week) I will explain how to achieve maximum security!

Information Gathering Using SSH Public keys

From: http://gdfuego.blogspot.com/

I’ve been a pretty heavy user of SSH for the past 10 years or so. In that time I’ve learned a number of tricks including port forwarding in various directions, forwarding SSH agents (and the associated risks) and various key management techniques if you’re providing key based authentication to large numbers of systems.

The most interesting trick I’ve learned with SSH, I haven’t really seem talked about much. A former co-worker pointed me to the feasibility of this working with protocol 1 and a hacked up SSH client, but these days it trivially works with both protocol 1 and 2 using the normal OpenSSH client.
The Trick

1. Generate an RSA SSH key, and delete the private half. The passphrase does not matter since we won’t be using the private key at all. ssh-keygen -t rsa -f test -N “” && rm test

2. Take the public key file (test.pub), and copy it to the authorized_keys file of a remote system.

3. Set mode 600 on the public key. chmod 600 test.pub

4. Try to log into the remote system using the public half of the SSH key. ssh -2 -i test.pub user@server

Assuming all went according to plan, you should get prompted with Enter passphrase for key ‘test.pub’:. Since this is the public half of a key, no passphrase will ever succeed. You do however know that the private half of this key would have allowed you to log in.

In case you’re curious, the reason for the chmod 600 is that the SSH client attempts to enforce good permissions for private keys by refusing to use a “private” key with open permissions. Since you’re essentially tricking the client into treating a public key as a private key, the same rules apply.
So What?

This trick allows you to do two things:

It allows you to identify what servers a user has access to. If you have access to a person’s public key (which are typically not protected since they’re PUBLIC), you can determine what servers the person has access to by attempting to log into root, their username or any other account using their public key.

The second piece is a bit more interesting. If your company has a central key repository which is available to all employees, it becomes very easy to test all keys against a specific server in order to determine who has a private key which has access to the system.

In the past I’ve used this functionality at work in order to determine who can still log into a system which had been down for a considerable amount of time (and had missed some key rotations). A hacker could instead use this functionality to know who’s private SSH key they’re going to need to steal in order to gain access to the targeted system.
Why it works

The reason this works can be understood by looking at the Public Key Authentication Method of the SSH protocol.

Among other bits of data, the SSH client sends a copy of the public SSH key to the server as part of the authentication process. The server then responds with SSH_MSG_USERAUTH_FAILURE or a SSH_MSG_USERAUTH_PK_OK message. At this point you now know if access would be granted with the private key, but you have not needed to use that private key in any way yet.

This explains why only the public key is needed during the authentication step, but not necessarily why the SSH client makes this so easy for us. I suppose its probably just a quirk of how their key parsing code works.

They could change the code to not allow you to attempt to do private key operations without a private key, but really that just adds a small hurdle to exploiting this small weakness in the protocol. At the end of the day, you’re still only as safe as the protections you put in place on your private keys.

Detecting SSH Brute Forcing with Mixed Log Sources

From: http://blog.tenablesecurity.com/

Event Analysis Training – SSH Brute Forcing with Mixed Log Sources

For a period of time during the evening (the grey area is 6:00 PM to 6:00 AM), there were many SSH sessions detected by Snort, the Tenable Network Monitor (the events beginning with “TNM”) and by the systems where an actual login was attempted.

The customer was concerned because they had received multiple correlated “Password Guessing” events during the evening, but only on a few systems. Only a partial number of servers had SSH and full system logs configured to send to the LCE. However, Snort, the TNM and even the Passive Vulnerability Scanner were reporting evidence of attacks against the entire network. The SSH authentication failure and other SSH messages were all in system logs, not all of which were being sent to the LCE.

In this case, I told the customer there was very little to be concerned about and explained that the Log Correlation Engine correlation script that looks for password guessing also looks for a successful password guess. Visually inspecting the graph, there were no login events of any type recorded. The LCE normalized all valid login events from SSH. If this attacker had leveraged an SSH key from the Debian debacle or indeed guessed a password, a successful SSH login would have been reported.

I was concerned that some of the other systems without full logging could have been compromised. To investigate this possibility, I suggested that the customer perform an IP summary to get a list of all internal systems and then check each of the Tenable Network Monitor Session Completed events to look for any session times or bytes transferred values that looked different from the others. In doing this, the customer was able to conclude that the network sessions to all of the other servers were very similar. If they had had full system logs being sent to the LCE Server, this form of analysis would have been quicker.

Last, I was concerned that some of the network sessions could have included some sort of buffer overflow attack and that the password guessing was a decoy. The customer verified that all of their SSH daemons were of the same build, OS and patch level. If there had been a successful attack on the target system for which we did see logs, we didn’t see any odd behavior on that host. There certainly were no outbound connections originating from that host, or new ports browsing. Both of these types of activity would be logged by the Tenable Network Monitor or the Passive Vulnerability Scanner.

For More Information

Tenable has written several Event Analysis Training articles that cover many different aspects of event analysis such as blacklisted IP address correlation, different types of worm traffic patterns and botnets, including:

• Event Analysis Training — An aggressive active worm analysis that isn’t Conficker
• Event Analysis Training — Working with “BlackLists”
• Event Analysis Training — Long Term Blacklist Activity
• Using “New Port Browsing” Events to find Worm/Trojan/Rootkit Activity

filetype:reg reg HKEY_CURRENT_USER SSHHOSTKEYS

This search reveals SSH host keys from the windows registry. The files contain information about where the user connects, including hostnames and port numbers, and shows sensitive information such as the SSH host key in use by that client. Interesting to note, yet again, that this search string has been around since at least 2004 and it’s still finding issues. It just goes to show how much most don’t know about the threats of the internet.

filetype:reg reg HKEY_CURRENT_USER SSHHOSTKEYS

I’ve linked the query above for instant gratification, but remember this is just one of many ways to use google to search. I didn’t form these queries I merely searched the web for ‘answers’, and used queries from googles advanced search operators page.

As always. these posts are educational and should not be used for pwning or any such unethical ’stuff’.