Honeypots and privacy
Even though Norway is not a member of the EU, many directives do still apply to us, and if they don’t, they still can provide useful insight. For instance, article 5 of the Directive 2002/58/EC of the European Parliament and of the Council concerning the processing of personal data and the protection of privacy in the electronic communications sector (Directive on privacy and electronic communications) [1] states;
Member states shall [..] prohibit listening, tapping, storage or other kinds of interception or surveillance of communications and the related traffic data by persons other than users [..]“
On a general basis one may emphasize that the end user (the receiving or sending party of the electronic communications) can always do whatever he/she wants to with the data being received (or sent). That includes logging the traffic data or recording the contents. The privacy regulation only sets limits to these actions when they are being performed by third parties.
The EU directive mentioned above may be interpreted in a way that the right to record one’s own traffic (and to participate in electronic communications) is assumed to be such a basic right that it doesn’t even need to be explicitly granted. One should be much more concerned about unauthorized third parties tapping the communications.
A reader pointed out to us that the Finnish legislation 516/2008 section 8 [2] is much more explicit in this regard:
“The sender and intended recipient of a message are entitled to handle their own messages and the identification data associated with these messages [..]“.
If you’re running a honeypot, that makes you a second party of (“unicast”) electronic communication, thus giving you all the rights of the participant. One could also argue that you are the in fact the intended recipient of that communication. It was the attacker that initiated the conversation; you didn’t fool him to do anything nor did you lure him to initiate the traffic under the false pretext. The honeypot is passively waiting for someone to first probe for any of its services and then start recording when it’s being attacked, most likely by a person wanting illegitimate access to this machine.
1. http://europa.eu/eur-lex/pri/en/oj/dat/2002/l_201/l_20120020731en00370047.pdf
2. http://www.finlex.fi/en/laki/kaannokset/2004/en20040516.pdf
Comments on the Aftenposten article
On Friday 26th of June Norwegian newspaper Aftenposten published a two-page article about honeypots. The article expressed concerns about the ethical and legal aspects of the technology. We are happy to see that media is concerned about security and privacy issues on the Internet. Unfortunately the article contained some mistakes and misconceptions which we would like to clarify.
Research organization
The Honeynet Project is an international, non-profit (501c3) research organization dedicated to improving the security of the Internet at no cost to the public. As mentioned on the Honeynet project web site[1], our vision is: To learn the tools, tactics and motives involved in computer and network attacks, and share the lessons learned.
We raise awareness of the threats and vulnerabilities that exist in the Internet today. Many individuals and organizations do not realize they are a target, nor understand who is attacking them, how, or why. We provide this information so people can better understand they are a target, and understand the basic measures they can take to mitigate these threats. For those who are already aware and concerned, we provide details to better secure and defend your resources. Historically, information about attackers has been limited to the tools they use. We provide critical additional information, such as their motives in attacking, how they communicate, when they attack systems and their actions after compromising a system. And for organizations interested in continuing their own research about cyber threats, we provide the tools and techniques we have developed. As an example, the Honeynet project was involved in reducing the effect of Conficker, which among others attacked the Norwegian Police, by providing tools and information [2].
Honeypots
A honeypot is a computer designed to be attacked. Most honeypots are built the the same way as computers used all over the world. The only difference is with a honeypot, there are no valid users nor any use for the system, no one should be interacting with it. Just like any computer at work or at home, a honeypot will log the IP address of any system that attempts to connect to it. To gain access to the system, an attacker must break into the system. The concept is similar to a locked door on an empty house. No one should be coming in or out. The only way an individual can enter is by breaking the lock.
Jon Bing and Georg Apenes expressed concerns that innocent users would enter the honeypots and thus have their actions logged. The honeypots are however never advertised to users. There is absolutely no process involved in the deployment of our honeypots which actively entices or lures anyone to enter the honeypot. You cannot find them through google or any other service. The only way to find them, is to actively probe and scan for them, and this is exactly what attackers do. In addition, there are no legitimate accounts on the system, the only way an attacker can get access is attack the system, the same way a criminal would have to break a lock on a door.
In the article, Bing compared honeypots to building a new street and setting up surveillance cameras in the whole area, without the visitors knowing that the information is stored and analyzed. This analogy is incorrect. An innocent user can easily walk into the wrong street. But to have their actions logged by a honeypot, the user has to find and attack the honeypot, they have to break the lock. So a better analogy would be that a honeypot was a building with a locked door in a back alley and surveillance cameras inside. If someone found the door, and broke into the building, then they would monitored by these cameras. In addition, the goal was not to arrest the perpetrator, but rather to learn how he broke into the house, and what he did once inside. The intention would be to use the knowledge to build safer homes and design better locks in the future.
Donations
Another issue raised by the journalist, was our donations, especially by Telenor and Lyse. Yes, it is correct that those two companies have helped us with both hardware and access to the Internet, and in similar ways, so has other companies as well. But in no cases do these companies receive special treatment or information. All information (as long as it doesn’t compromise ongoing research) are shared with the public at no cost.
In agreement with Aftenposten, we are publishing a translated version of the article.
The Honeynet Project, Norwegian chapter will contact the Norwegian Data Inspectorate and Jon Bing to explain the topic in detail. The Honeynet Project, Norwegian Chapter can of course not operate if we are considered unethical or on the edge of the law.
Notice: We have removed the page “Information in Norwegian” due to possible misunderstandings when English words and expressions had inadequately been translated to Norwegian. It will be replaced with a new fact-sheet about The Honeynet Project.
The Honeynet Project press contact is lance.spitzner@honeynet.org
2. http://en.wikipedia.org/wiki/Conficker#Removal_and_detection
Country Lookup
We’re pleased to announce a new service; CC2ASN – Country Lookup. This service will provide you with AS-numbers, IPv4 and IPv6 prefixes belonging to a specific country. The data is all based on publicly available information from the five RIRs in the world; ARIN, RIPE NCC, APNIC, LACNIC and AfriNIC. The database is updated once every day.
As input to this service, use ISO-3166-1 alpha-2 country codes (more info). Note that in addition to the ISO defined codes, the following two codes are also used when dealing with multi-regional networks; AP (asia-pacific) and EU (european union).
You may access the data either through the web-interface, or via your command line interface. A standard whois client can be used when the result set is “not too large”. The preferred way is to use a raw socket tool, like netcat. Here are some examples illustrating both ways:
whois -h atari.honeynor.no no
whois -h atari.honeynor.no ipv4 ke
echo "all us" | nc atari.honeynor.no 43
The first will list all AS-numbers registered for Norway, while the second example will list all IPv4 prefixes for Kenya. The last line uses netcat to fetch everything (ASN, IPv4 and IPv6) registered for USA (this query will fail when using a standard whois client).
For more information, please read the documentation (There are some caveats to be aware of, and more alternatives to download this data. It’s all in the docs).
Fighting Back!
Yesterday, The Honeynet Project released a brand new Know-Your-Enemy (KYE) paper titled; Containing Conficker. Previous papers about the Conficker variants (like SRI’s analysis) have focused on explaining the inner workings of the malware. The KYE paper, on the other hand, proposes new ideas on how to identify, mitigate and remove Conficker from compromised hosts.
The paper contains a wealth of excellent information and actionable intelligence for both security analysts and network/system engineers trying to defend against the vexing issue that is; Conficker. Together with the paper, a series of different open source tools have also been released:
- Domain Name Generation Tool – Downatool2
- Memory Disinfectant – conficker_mem_killer.exe
- File and Registry Detector – regnfile.exe
- Conficker Remote Scanner – scs.exe
- Nonficker Vaccination Tool – nonficker.zip
The collection page includes the source code for all these tools and also Nebula-generated Snort signatures for Conficker.
Here is the link to the paper again, in case you missed it: PDF.
How to get the password from any SIP user-agent!
This is really, really, really bad!
If I know the IP address of your SIP User-Agent and your extension, I can get your password. Not true? Here is how Sandro and I did it! Sandro Gauci also has a tool (voippack for Canvas) which automates the whole process, you can watch the video here!
The master plan:
- Check up on the Internet which ISPs are delivering VoIP. Check RIPE for their IP ranges. Scan them for SIP devices.
- Get the extensions they are using (or their ranges of usernames (e.g phone numbers, then do brute force on these ranges on each IP)
- Send an INVITE to the correct extension and the phone will ring. When the user hangs-up, we have the password.
The details:
We make the phone send a PROXY AUTHENTICATION when the SIP UserAgent sends the BYE message. We answer with “407 Proxy authorization required” and then the SIP UserAgent actually answers this with the password in a MD5 hash.
The problem
- The SIP stack is not connected to the IP Stack. Why is the SIP User Agent answering on SIP messages from other IPS than the SIP Registrar it is connected to? There should be automatically a rule saying “all SIP messages from other servers than what I’ve registered to = drop them!”
- Why does the User Agent blindly answer a challenge on the BYE message. Just send it a “407″ and the SIP UA answers with the password…
Units tested (and we managed to get the password)
- Linksys SPA2102
- Grandstream GXV3000 (latest firmware)
- AVM Fritz 7270 (firmware December 2008)
The units that will be tested further:
- Polycom
- Thompson ST2030
- Snom
How to protect yourself (for users)
- Make sure your VoIP provider has credit limits! You don’t want to get a huge phone bill!
- Report any unusual phone calls or strange behavior!
How to protect yourself (for VoIP providers)
- Protect your SIP user-agents! This is hard with the Fritz units
which is normally used as a router - Have very long SIP passwords and use all characters that is possible! (#¤%” and others)
- Change the SIP password regularly
- Run VoIP honeypots to detect scans in your area
How serious do you think this is? Write your comments now!
GSoC Mentoring Organization
We are excited to announce that the Honeynet Project has been selected by Google to be a mentoring organization for their annual Google Summer of Code project. Our team of volunteers is very excited about this and look forward to working with and helping mentor students around the world about honeypot technologies. To learn more about the different projects you can work with us on, please take a moment to review our IDEAS PAGE. If you will be submitting an application, your best chance to be selected is to take your time and review and understand the project involved before submitting the application. If you need any additional information or want to ask us questions, you can get in touch by email or on IRC (#gsoc-honeynet on irc.freenode.net).
Looking at some SQL-injection attacks
By using the techniques described in mkrakvik’s post, I’ve been looking at the results of quite a few of the different SQL-injection (and XSS attacks) successfully performed against norwegian and danish servers.
The attacks have several common properties:
- injects a javascript to the attacked page
- the script is obfuscated
- the scripts loads several iframes and other scripts
- the end exploits are ActiveX, .swf or .pdf attacks
The javascripts
The javascripts are usually pointing to a russian or chinese server. They are obfuscated in different ways. Some simply use url-encoding of the actual script combined with unescape() and eval(), while others use complex encryption functions including long encrypted strings that are decrypted by shifting parts of the string and combining parts in different ways.
The first script usually loads several different other scripts from servers, often contacted by IP. Many of these servers are probably zombies, and a lot of the servers were no longer serving any scripts (the zombies may have been cleaned out). The attackers were using scripts from several different servers, in case one of their zombies go down. So it’s basically a “hacker cluster” for availability.
End exploits
The end scripts usually contain several different attacks. I’ve seen scripts trying to exploit up to ten different activeX-components, and many of the scripts use both activeX and flash (.swf) attacks.
One of the attacks (gcounter.cn) had two activeX attacks downloading two .exe files, two flash files and one pdf. The first .exe files was detected by 22/36 vendors at virustotal.com. The other four files had a lot lower ratios. One of the flash movies was not detected at all. This attack was also analyzed by Morten Kråkvik, and he created this interesting picture. His full post is available in norwegian here: Malware og drive-by exploits
Another attack (found on among others yahoo-union.cn and www.jmlrmg.com) had six different flash movies for IE and six for firefox, yielding a total of 12 flash movies for different versions of flash. They were on average detected by 3/36 of the antivirus vendors on virustotal. I reuploaded one of the flash files three weeks after the initial upload, and it’s now detected by 13/36 vendors: virustotal analysis
Protecting your browser and your web site users
- Keep your web sites free of SQL-injection and XSS exploits – OWASP has some good resources for SQL-injection and XSS mitigation
- Focus on security during the entire development projects – not just at the end or the beginning
- Allow your developers to take security trainings. Security can only be achieved through collaborative effort – it’s not the responsibility of a single person
- Keep up to date on all web browser, web browser plugin and OS patches.
- Keep your antivirus up to date (some of the exploits I found were “old” and detected by most of the vendors)
- Don’t visit links you get in emails, social networks or on IM without verifying that they are actually from the person they claim to be.
- Consider using the noscript-plugin if you are an advanced firefox user
VoIP attacks are escalating
There has been numerous VoIP attacks from very different sources the latest months. In this article we will go through attacks towards two different companies in Norway. I will explain how they did it and how you can protect yourself against it.
Who was the attackers?
The attackers IP adresses:
- 124.217.230.238
- 124.217.230.225
- 213.130.74.70
- 213.130.74.72
The first two IP adresses belongs to “Piradius” network in Malaysia.
The second two IP addresses belongs to a VoIP company in Bulgaria, www.iconnectbg.net. These people has not been successful with their actions, but they had about 1000 SIP INVITES while trying to get through.
There was also some port scannings on port 5060 from an American IP, so we contacted the firm and it was most likely a break-in on the local servers.
The attackers business models
There seems to have been to way to make money. One way was to directly use it as an outbound gateway. This is quite risky since you have an existing business to protect.
The other way was to sell these minutes to another provider. One company specializing in discovering and making the gateway ready, then selling this access to prepaid phone card providers.
There are several others, like calling expensive numbers in other countries and then charging the terminating fees.
How did they find the VoIP gateways
The Piradius network (or the people hiring place in this network) did their port scanning from 124.217.252.238. First they search just for open ports, port 5060 (UDP and TCP!) and 1720 (h323). If you have a Cisco PSTN gateway, remember that the Cisco gateways can do both SIP UDP/TCP and H323. The first machine tried all different numbers similar to this.525551690000.
Example:
- 00525551690000
- 000=23525551690000
- 00100525551690000
They tried a lot of different variations of this, and after a while they went over to a brute force way, just counting their way upwards
- 26100525551690000
- 26200525551690000
- 26300525551690000
- 26400525551690000
The always used caller ID 5199362832664 on all calls. They probably had an Asterisk on the other phone number, noticing when it rang and which gateway that then had been used.
What was configured wrong?
One of the customers with an Asterisk had included the “outbound” context to the SIP provider within the reach for the inbound context. Calls coming in and there were no matching numbers internally was routed out to the SIP provider. This is such a bad idea…
Another customer had a Cisco gateway. Cisco gateways just routes VoIP traffic the same as IP based on the dial-peers. It was configured properly with dial-peers but not with the correct access lists. The Cisco just needs 1 dial-peer configured to bounce traffic like this.
The motives
These two attacks were directed to get free calling. The calls were going to expensive countries like Cuba and Jamaica. There has been no directly breach on the system with username/passwords to gain access and get information. The objectives were to send free telephony traffic through the unsecured PBXs.
How to protect your VoIP equipment
- Always have a firewall or session border controller (SBC is just a specialized VoIP firewall) between you and the Internet.
- Limit your access to your VoIP servers from the rest of the world
- Do not let inbound contexts in Asterisk have access to outbound.
- Be careful with dial-in features and get a new dial-tone based on a password.
- Update the software regularly.
- Use VPN tunnels to protect the VoIP traffic going over the Internet
- Use SIP TLS and SRTP if possible (we are waiting on hardware manufacturers here as well)
- Shutdown all services on equipment that is not in use. Example H323 on a Cisco gateway used only for SIP
Talk about data analysis
We did a talk about data analysis at the annual ISF conference (IT-sikkerhetsforum). The conference gathered around 200 attendees from all over Norway and was held at the Strømstad Choice hotel in Sweden. The conference has typically been hosted in Norway, but this year it was hosted in our neighbor country and the total number of attendees was record high. It has to be the “tax-free” store at the border, or the Honeynet Project talk?
The slides are available here (in Norwegian).
UPDATE: Slides has been translated to English. English slides here
Capture-HPC 2.1
The Honeynet Project and School of Mathematics, Statistics and Computer Science at Victoria University of Wellington, New Zealand are excited to announce the release of Capture-HPC v2.1.
Capture-HPC is a computer security product that allows anyone to: investigate client-side computer attacks; security researchers to find and study malicious servers; virus and malware researchers to collect malware pushed by malicious servers; network administrators to monitor their systems for client-side attacks; and web site operators to monitor their web sites for unauthorized modifications with client-side attack code.
The new version have a 500% increase in performance over the previous version, which should be greatly appreciated by those already familiar with the tool. Besides malware and unauthorized state changes, Capture-HPC now collects network traffic for all client/server interactions. In addition, Capture-HPC now reports statistics about the performance of the system allowing operators to monitor and tune the Capture-HPC system during operation. Introduction of a client plug-in framework.. This framework allows third-party developers to include client applications that are currently not supported by Capture-HPC. A Safari browser plug-in that makes use of this feature is provided with the 2.1 version of Capture-HPC adding support for this browser and demonstrating the capabilities of this framework. In addition, a wide range of browsers, office applications, and media players are supported by Capture-HPC.
