The Google Summer of Code is an annual program in which Google awards stipends (5000 USD) to hundreds of students who successfully complete a free and open-source software coding project during the span of one summer.
Google invites students who meet their eligibility criteria to post applications that detail the software-coding project they wish to perform. These applications are then evaluated by the corresponding mentoring organization.
The Honeynet Project is one of these mentoring organizations and we provide mentors for the project ideas relevant for us. The mentors then rank the applications and decide among themselves which proposals to accept. Google then decides how many projects each organization gets, and asks the organizations to mark at most that many projects accordingly.
This year The Honeynet Project has mentored a total of 16 very exciting projects. Check them out!
- Automated Attack Community Graph Construction
- Automated Attack Community Graph Construction
- Expand Cuckoo Sandbox
- HonEeeBox User Interface
- Data mining, module for finding frequent network-itemsets
- AfterGlow Cloud
- Network malware simulation
- IPv6 attack detector
- IPv6 attack detector
- HoneyProxy – HTTP(S) Traffic Investigation
- Improve our Android application sandbox (DroidBox)
- Improving APKInspektor
- Network Analyzer
- Glastopf improvements
- Further extend Capture-HPC with possibility of detecting malicious behavior on Linux Machines
- USB Honeypot (Internal project)
Now the scanning has started again.
For those remembering back in 2008 there was a large scanning in Germany, where customers with softphones experienced incoming calls (very annoying during the night..), it has now started again. A good paper from ipcom.at describing it extensively.
What caugt my attention was the very long branch and callid fields. They contain IP of the scanner, the scanned victim, the phone number trying to be called and several other fields (if you know what the rest of the codes are, please let me know!)
INVITE sip:email@example.com;transport=udp SIP/2.0
Via: SIP/2.0/UDP 184.108.40.206:3916;branch=110100101110100010101\
CSeq: 1 INVITE
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS,
PRACK, REFER, REGISTER, SUBSCRIBE, UPDATE, PUBLISH
User-Agent: eyeBeam release 1003s stamp 31159
o=- 16264 18299 IN IP4 the.honeypot.ip
s=CounterPath eyeBeam 1.5
c=IN IP4 the.honeypot.ip
m=audio 34222 RTP/AVP 18 0 8 101
- Hide quoted text -
And no, it is definely not “CounterPath eyeBeam 1.5″ but a custom-made scanner. This is just an indication that people are willing to put mony into developing software to attack these insecure VoIP servers.
Status now is frequent usage of stand-alone SIPviciuous and other scanners, and two kits doing extensively scanning:
they started this spring, getting scannings from all over the world, but an overweight of Chinese IP addresses.
the current scannings with “Counterpath” as user-agent.
They have been active before, and now started again (scanning latest month)
And this is just the beginning…. so secure your VoIP servers!
content originally written on the blog usken.no by Sjur Usken
Yesterday we had the pleasure of doing a presentation at the Norwegian infosec conference “ISF“. Our presentation gave a brief introduction to the Honeynet Project in general, but the main part introduced to the audience a lot of the tools developed by the project together with a few external tools as well. The presentation is available for download in several formats: PDF, ODP or PPT.
The latest month of scanning has seemed valuable for the hackers. A Norwegian municipality has been hacked and their PBX has been calling Somalia and a lot of others destinations we have picked up on our VoIP honeypots during the last month.
If you have an unsecure IP PBX on the net, now it will only take hours before it will be detected. Most normal cause for this is misconfiguration. The people setting up the IP PBX has not taken security seriously and the IP PBX is wide open for calling.
The simplest ways is that inbound calls is routed out again if no local destination is found. A little harder is to just brute-force the password on extensions. I can only say, there will be more like this!
The hacker can sell this “gateway” to a third party dealing with calling cards. I have investigated frauds in Norway where they managed to send 1,2 million NOK (approx 200 000 USD) within 10 days. This was a Cisco installation, but misconfigured Asterisk installations are also abused a lot.
For over 9 months we’ve run our CC2ASN service, allowing you to lookup up ISO-3166 country codes and get back all ASNs, IPv4 or IPv6 prefixes for that specific country. Now the time had come to do an update.
A major issue with the RIR data (delegated-feeds) used by the CC2ASN service, is ASNs registered to a region instead of a specific country. There are currently two regions in use; European Union (EU) and Asia Pacific (AP). The reason for using this is the ever increasing globalization of corporations and organizations, and hence quite understandable. But when you want a list of AS numbers for any given country code, the regional registrations have to be included.
This is where the enhanced database comes into action. In this database we’ve manually overridden the country code assignments for those ASNs that in the RIR data were registered to either EU or AP. In addition we’ve also corrected a few other ASNs that we knew had a wrong country code. The list we’ve compiled is publicly available: asn_override.txt.
It’s all been a manual job, going through all the EU and AP ASNs, plus a good portion of the CCs also. The CC override decision is based on one or more of the following actions:
- Looking at references to location in whois descr, address or country records.
- Using location info in router names from tracepath of the AS prefixes.
- The nationality of peers and upstream providers.
- Location of corporate headquarters or regional headquarters.
- General googling/binging.
And this is a continuing job, whenever new ASNs are allocated to either EU or AP.
So, how do you access this new database? From the CC2ASN web-interface make sure you check the box labeled “Use Enhanced Database“. The database is also available by directly querying port 44/tcp (the normal CC2ASN database is available on standard whois port 43/tcp). Note that the enhanced database only outputs ASNs, not prefixes.
$ echo "GB" | nc atari.honeynor.no 44
Every day, when the latest RIR data are downloaded and parsed, all changes to the enhanced database are recorded. This allows us to provide you with an ASN history tool; CC2ASN Delta. The main page lists changes over the last 90 days for ASNs registered to a spesific country. By clicking on a county, you get a textual representation of all registered changes for that country. By further clicking on an ASN, you get a listing of potential country changes for that AS.
For more information, take a look at the documentation.
The Honeynet Project has once again been accepted as a mentor organization in Google Summer of Code (GSoC). During the next week or so, we’ll keep updating our GSoC-2010 page, especially the page of proposed ideas.
We’ve got a wide range of projects and develop tools using most of the popular programming languages, so if you are an eligible student interested in open source software, information security or honeynet technologies and think spending your summer being paid by Google to work on an exciting software development project sounds like a great plan, we look forward to hearing from you.
Simply connect to #gsoc-honeynet on irc.freenode.net to chat to our organizational admins and project mentors. Do remember that you don’t have to apply for one of our pre-defined project ideas, you can also propose your own project topic which we’ll try to find a suitable mentor for too. Google will start accepting student applications from Monday, March 29 at 19:00 UTC.
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)  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  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.
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.
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, 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 .
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.
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 firstname.lastname@example.org
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).
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
Here is the link to the paper again, in case you missed it: PDF.