This page is a list of items that are related to HackLabs and the work we perform.
NB: HackLabs is a Security Consulting Company specialising in Penetration Testing . We perform testing for our clients whom are from all around the world.
With a sudden surge in people scanning for RDP ports that are exposed to the internet, one can assume they are building lists of possibly vulnerable hosts waiting for the chance to spring once exploit code comes on board. This of course got me thinking about profiling people most likely running RDP. Several people have been portscanning TCP 3389 but a quick list method is much easier.
Microsoft Small Business Server = RDP Pain. I came to his conclusion as;
It's designed to run all critical and sensitive data on one server
- Has an internet facing design touted by MS
- Core of most SMB's operations
- Slower to patch the server possibly, given the liklihood to not have a dedicated IT team.
- There is 6,000 of them indexed by Google.
Thats right "Google Dorking" for
gives a little over 6,000 entries. Which is a nice way to start a list of vulnerable hosts.
Please go patch your SBS Server.
Changing the default RDP Port from 3389
Terminal Services by default listens on port 3389 (but can be changed by editing the registry).
If you want to change the listening port, edit this registry key:
\HKLM\System\CurrentControlSet\Control\Terminal Server\WinStationRDP-TCP Value : PortNUmber REG_DWORD=3389
Microsoft recently released patches for several vulnerabilities -- one of which is a critical bug for Windows' Remote Desktop Protocol (RDP) which stands a high probability of being exploited . Based on our experience in the field and previous penetration tests, Hacklabs believe that;
- Approximately 98% of all organisations run RDP internally
- 30% have RDP on an Internet facing Windows host.
Additionally, we anticipate that attackers will begin reverse engineering the patch immediately and subsequently attacks in the wild can be expected shortly. MS12-020 is an patch update for a vulnerability which exists within RDP which allows for unauthenticated remote code execution at the default privilege level that RDP normally runs for (SYSTEM on most Windows machines). The vulnerability has been assigned a CVE number CVE-2012-0002.
The Microsoft advisory has suggested that this patch be applied urgently , in anticipation that attacks against it will begin occurring in the not too distant future. Those with Automated Updates enabled will automatically receive the patch.
We suspect this will affect both small and large orgainsations equally. This is due to;
- Small business make use of Cloud Servers more frequently which use RDP (aka Terminal Services) to access the destop of the server. This means by design often it is internet facing.
- Many orgainsations - both large and small - use RDP extensively for management inside an internal network.
As a mitigating control, Microsoft have suggested that customers consider applying Network Level Authentication (NLA) however this will prevent older machines running Windows 2003 or Windows XP from connecting. However this mitigation does not eliminate the need to patch the machines as the vulnerable code is still present, it still requires an attacker to successfully authenticate first. Windows XP users simply need to download and enable CredSSP in order to authenticate to these hosts. Unfortunately there is no CredSSP support for Windows 2003.
HackLabs recommends that all clients test and apply this patch urgently. As part of a sound "defence-in-depth" strategy, Windows servers running RDP should not be directly Internet facing but rather reside behind a firewall, VPN or suitably hardened bastion gateway which directly limits connectivity to authorised users and networks only. Those running a Terminal Services Gateway should explore options for restricting access to the host to known and trusted networks and hosts if they have not already done so.
- MS12-020: Vulnerabilities in Remote Desktop could allow remote code execution: March 13, 2012:
- CVE-2012-0002: A closer look at MS12-020's critical issue
- Configure Network Level Authentication for Remote Desktop Services Connections
During the weekend Kingcope released an exploit "Apache Killer" for Apache Web Servers on the Full Disclosure message board. The vulnerability takes advantage of a feature called "Partial Content" that allows Apache Sites which support it, to be DoS in many cases.
Apache Killer works by sending partial content requests to Apache httpd. These requests cause the daemon to swap memory to the filesystem, and with enough requests, exhausts the server of its resources.
We did some testing for some of our customers and confirmed that it worked very well with little resources (3G connection was used during the testing to DoS a site).
We edited the exploit script and removed the DoS payload and then used it determine how many sites could be affected. By running this across the Alexa Top 1000 sites for Australia we identified that 91 were possibly vulnerable. Similarly on the ASX 200 List 26 organisations were likely to be vulnerable.
To mitigate against this in one instance where no other controls were possible (As in a shared hosting environment) an IP tables rule was used to defend against it. However any firewall, WAF or IPS could be configured to prevent this attack.
To test your susceptibility to this attack you could run curl with the following to determine if Partial Content is supported on your Apache Site;
curl -H "Range:bytes=1-" -I http://target.com | grep Partial
A patch for adding support to turn off Partial Content was also found here with a quick google
Also someone else has posted this video of the DoS in action (albeit in a test environment)
A lot has been written about Firesheep and whilst I have provided some commentary on it myself. There wasn't much mentioned on that it relies on specific scripts tailored for the site's in which it targets. Curious I had a quick play and wrote up a couple of scripts for some Australian Sites I have used.
NB:All of the ones I tested used HTTP for the sign in process which was the default setting, Some offered HTTPS but as an additional link to click .
It's a pretty straight forward process;
1) Identify the correct domain
2) List the cookies sent as part of the session (Normally the ones sent to you after you have authenticated)
3) Identify the section of the page in which the user name is displayed
4) modify the (identifyUser: function). For the sites I looked at it meant I had to change
this.userName = resp.body.querySelector('changeme').innerHTML;
The changeme value above has to reference where the username value is. So for Whirlpool for example the page source snippet looks like this;
The username is referenced as the following within the script;
this.userName = resp.body.querySelector('dl.userinfo span').innerHTML;
One thing I did notice when running Firesheep was the number of third party connectors that sites were running. As these were linked from the news site I was viewing they automatically connected back over HTTP to the service.
In one example it had a bit.ly bookmark extension and a facebook connector. If you had an open session in another window or opted to keep yourself logged in by checking a box (which I guess many users might do) it would connect back and expose the session cookies and hence appear in Firesheep.
I don't condone illegal activity and have provided the above information for people to evaluate their own applications or the applications they legitimately have access to.
The following firesheep scripts were written with help from RD (Thanks Mate).