I’m sure by now most people are aware of a new round of scams where victims are being called by a ‘support company’ suggesting that the victim’s computer has malware installed which they can fix. If you need it, this BBC article covers the basics. Well, I just got the call 😉
First up the caller seemed to be auto-dialling large volumes of numbers looking for someone to pick-up as the caller (male, poor line quality meant I missed the name given) was unprepared when I answered. The caller was clearly reading from a script, I may have over-played the ‘Sorry, I’m just a dumb user that knows nothing about computers card’ but despite telling him I was clueless and willing to accept everything he told me I was still present with a long winded argument for ‘if you don’t believe us this is how I’ll prove it’ speech.
Unfortunately I wasn’t able to through the full process as, despite telling my new friend otherwise, I wasn’t able to get to a Windows machine to work through the process. Only laptop to hand was my netbook running Ubuntu, and my landline isn’t mobile so I couldn’t head up stairs. (My landline never rings, everything I do is via mobile and only have landline for ADSL connection. I’m suspicious of all landline calls before I even pick up the phone.)
After ensuring I was looking at the system wallpaper, I was instructed to press the ‘key on bottom left of keyboard with four squares that looks like the Microsoft logo’ and with another finger press the ‘r’ key. This is where I was given ‘proof’ that my system was infected, using a ‘hidden’ command that will list all infections, what is the magic command? inf (for ‘infections’), which opens Windows Explorer in C:\Windows\inf, screenshot below shows the infections on my system. I’m guessing at this point, the every user may have just entered dummy mode.
At this point I lost the caller, whether a technical fault or he’d guessed something wasn’t right (I can’t act for toffee). I’m hoping that I’ll get a second bite at the cherry at some point; my missus took a similar call a few weeks back, having spent too long listening to my security rants she immediately spotted the scam, pointed out that I was a ‘security guy’ and hung up. Information that they clearly didn’t have when ringing back (could be more that one cold calling organisation). Unfortunately, despite my usual laughing at people who fall for these scams I can see how those with less knowledge could fall for the premise. Computers and software regularly phone home to check for updates etc, using this information to identify infected systems would/could make sense, and from an end user perspective I struggled to tell the difference between the sorts of actions I was asked to take by my ‘friend’ than those I regularly instruct friends and family members when I’m trying to provide remote support. Be safe and spread the word to those less knowledgeable about computers that this is an active scam. Bottom line is: no legit IT company will call you to fix a problem that you weren’t aware of. –Andrew Waite
I just received a new call following the same theme but with a different vector. This time the call came from ‘Microsoft Service Department’, and with a different convincer; this time I was baby-stepped through to opening the Security log with each entry being ‘evidence’ of the malware infection that ‘at this very moment is damaging my computer and hard drive’. To be fair, in this case they ‘could’ be right.
Other differences indicate that either this is a different group from the first caller, or they’ve improved the call systems used to implement the scam. On lifting the receiver I was placed immediately to on hold music before speaking to my ‘MS representative’ a few moments later. I believe that automated dialling is illegal within the UK, but given the nature of the call I doubt they care much either way. REMEMBER: Microsoft will NOT call home (or business) users to inform that you’ve got a malware infection
I’ve tried messing around with SSH port forwarding in the past, but always struggled to get my head around what I was trying to connect to where, and ultimately didn’t result in anything useful. This time around I’ve put in some dedicated time to get to the bottom forwarding ports within SSH tunnels. And I’m glad I did, my with only a handful of connections the possibilities are making my head spin.
To help my head get around problems I encountered I found a number of resources helpful.
Example Scenario: A server (10.0.0.100) on an internal LAN has web services that need to be accessed, but has no remote access through the firewall. Luckily, there is remote access to an SSH server (10.0.0.200) sat on the same LAN.
This connects to the machine at ssh-server.somedomain.tld and, once authenticated, forwards 10.0.0.100:80 to port 8000 on the local machine. Now accessing the remote services is as simple as pointing your browser to http://127.0.0.1:8000.
The same functionality can be achieved using configuration files. For example, edit ~/.ssh/config:
To establish a connection with the configuration file in place simply run; ssh tunnel.
The port forward will remain active for as long as the SSH session is connected. If you don’t need to interact with the SSH session in addition to the forwarded port passing ssh the -fN flags will cause the session to be backgrounded once authentication can be established.
If you haven’t already, I suggest you investigate the possibilities within your own environment; and if an evil grin doesn’t spread across your face then you still don’t fully get it 😉
I’m trying to do a better job of documenting the systems that make up InfoSanity. To do that it’s everyone’s favourite, a wiki. In this case I went with DokuWiki, for no real reason other than it came up first on a Google search. Installation is simple on a Debian based system, just the usual: apt-get install dokuwiki. So far so good, but I’m wondering how long I can actually keep the documentation upto date…
At the same time I came across the the BeerWare license from my Twitter feed (sorry, can’t find original message, thanks to whoever pointed me in the right direction. The license was created by Poul-Henning Kamp, and does a good job of summing up my feelings toward the tools/scripts I’ve released the last few years:
* "THE BEER-WARE LICENSE" (Revision 42):
* <phk@FreeBSD.ORG> wrote this file. As long as you retain this notice you
* can do whatever you want with this stuff. If we meet some day, and you think
* this stuff is worth it, you can buy me a beer in return Poul-Henning Kamp
So, why not combine the two together? DokuWiki has the ability to apply one of several standard licenses by default, but unfortunately BeerWare isn’t one of them. To correct this obvious mistake edit /etc/dokuwiki/license.php to include:
n.b. I struggled to find a better license location that just deals with the license, if anyone finds better let me know.
Now it’s just a matter of editing the main dokuwiki config file, /etc/dokuwiki/dokuwiki.php:
As proven by the logs generated by Kippo honeypot sensors have shown, attacks against SSH services are regularly seen in the wild. Even if you follow best practices for securing the service, the malicious scans will utilise resources available to your environment; CPU, bandwidth etc. In sufficient volume legitimate operation may be impacted as the server rejects failed login attempts.
This is where utilities like Breakinguard come into their own. Basically Breakinguard monitors log files for signs of malicious activity, and once a single source has triggered enough alerts blocks all connections from the source location. Other utilities (most notably fail2ban) perform the same activities, but I’m partial to Breakinguard due to it’s small size and simple configuration (and from knowing the author 😉 ).
Installation is straightforward, and for the most part automated. Once downloaded and extracted installation is handled by the configure script. On Debian based systems this will install the pre-requisite Perl modules and transfer the utilities components to the standard locations:
Once installed you need to edit your configuration. The breakinguard.conf file is fairly self explanatory, I normally edit:
$alert_email -> set to the email address that you want to receive notifications of blocked attacks. On a publicly accessible system these alerts can be high volume, you may want to use a specific email account or at least setup some auto-move rules in your email client to avoid your inbox being spammed.
$number_of_attempts -> This specifies the number of malicious log entries need to be generated by a specific IP address before the source is blocked. Due to the timing of the Breakinguard route this isn’t always an exact science, the default of 5 does a good job of avoid false positives whilst still blocking an attack in it’s infancy.
$log_to_watch -> selects the logfile to monitor for signs of malicious activity. /var/log/auth.log is the obvious choice on a Debian based system.
@safe_ips -> This array allows you to specify a number of trusted networks that will not be blocked, regardless of the number of times the they trigger alerts in the logs. This is useful for insuring that you don’t get locked out of your own systems in the event your keyboard ‘breaks’. On higher end systems with hardware remote management systems (iLo, DRAC, etc.) or virtual systems that provide remote access to the ‘physical’ console I leave this list to local subnet only and use the alternative options to access the server if I do lock myself out.
$DEBUG -> set to 1 by default, this runs the utility in test mode without actually blocking malicious sources, perfect for testing configuration before going live. Once you’re good to set set $DEBUG to 0 and wait for the attacks to start. Example testing in debug mode is below:
Blocking and unblocking of malicious sources is handled via iptables. Once the $number_of_attempts limit is hit Breakinguard will run the $block_command (configurable in /etc/breakinguard.conf) which by default is ‘/sbin/iptables -I INPUT -s %s -j DROP’, with %s being replaced with the attacking IP. After a configurable timeout ($block_length), the $unblock_command removes the restriction.
You can see the IP addresses currently blocked as they are listed in /var/run/breakinguard/, alternatively listing the current iptables configuration will show sources currently being blocked, for example:
I’m sure this is basic for most of you, but I seem to keep making the same daft mistakes whilst updating Dionaea, so I’m hoping documenting the issues and corrections will work as a memory aid in the future.
Firstly, I can never remember Git’s equivalent to ‘svn update’, which is:
Next up is recompiling Dionaea from your updated source directory, this is no different to an initial install as per Markus’ excellent instructions.
I keep forgetting to update my configuration file to include any directives needed for the new shiny new functionality you’re upgrading to get access to. I find diff useful for identifying any new additions, for example
Assuming there’s no major changes you should only see differences specific to your installation, for example your email address to receive analysis reports, or your VirusTotal api key. If there are any other differences you’ll need to add the new content.
From the experience I’ve had in the past week, if you encounter any unexpected problems after updating Dionaea, make sure your pre-requisites are also upto date. After updating Dionaea last week to gain access to the new integration with VirusTotal’s api my Dionaea sensor started to die randomly. Markus was a great help with troubleshooting (thanks again) and my problems were eventually corrected after it was noted that my libemu installation was outdated; after a quick ‘git pull’ and ‘make’ (again following Markus’ instructions).
As I said, this is probably basic for most of you out there, but as I keep making similar mistakes I plan to refer back to this list of daft issues before bugging anyone for support in future. You never know, it might allow someone else to retain an air of competence before proving otherwise 🙂
I’ve been lax in writing this, so apologises.
Recently the already vibrant social networking scene in Newcastle Upon Tyne gained another group, ToonCon. What is ToonCon?
ToonCON is a monthly meeting and yearly conference in Newcastle-upon-Tyne of people with an interest in information security, these people include security professionals, students and hobbyists. We attempt to meet once a month at a local venue in the heart of Newcastle city center to discuss information security, drink b33r and have a good time. Our chosen venue will have free WLAN access, be quiet enough to have a decent conversation, have wheelchair access and be safe enough to leave your new gadgets and laptops on the table. At this moment in time we are still deciding on a venue, if you know of one that fits the description above, let us know!
After two events, ToonCon has so far lived up to billing, with plenty of infosec debate on a whole range of topics. With attendee’s experience ranging from students who are still learning the ropes, to those who have been on the frontlines for many years, all are welcome and everyone has something to both offer and gain from the discussions.
If you’ve got an interest in keeping information secure (or accessing supposedly secure information) and in the North East why not get involved?
Development of new features for Dionaea has been fairly impressive of late, and I’ve been lax in keeping up to date. When Markus asked if I’d tested the graph utility that he created and wrote about here, it served as a kick to stop putting off some of the jobs I’ve got on the growing to-do list.
I won’t go into too much detail about running the script as Markus has already done a better job than I could. However I will point out that if you run your Dionaea installation on Debian stable, then your out of luck; the standard packages for sqlite are too old to take the script. Best advice is to copy your logsql.sqlite database to a Ubuntu machine and work from there (oh, and in case you didn’t guess from the script name, make sure you’ve actually installed gnuplot…).
A powerful machine is recommended, the only Ubuntu system I had to hand whilst testing was my AA1 netbook, which took 85 minutes to crunch through the script and my database.
I have immediately found the graphs produced useful as they’ve highlighted a couple of obvious spikes (see below) in activity that I would have (and did) miss if solely relying on log files and databases. This really shows the power and importance of visualising security and log information.
If you’re interested the output for the InfoSanity’s installation is now online here. I’m looking to expand the statistics from the InfoSanity honeypot environment that are publicly available, this makes a nice start. As always, big thanks to Markus and carnivore.it team for the effort.
— Andrew Waite
<UPDATE>Live download mirror: carnivore.it</UPDATE>
Mercury Live DVD was initially (I believe) announced in a post to the Nepenthes Mailing list. It is a remastered Ubuntu distribution with pre-installed honeypot applications and malware analysis tools created by John Moore. From the ReadMe:
This live DVD is a remastered version of Ubuntu 10.0 Beta LTS x86_32. It was designed due to my being disappointed with another reverse engineering malware live CD that was released recently. I have decided to call my creation MERCURY, which is an acronym for Malware Enumeration, Capture, and Reverse Engineering.
The Mercury live DVD contains tools used for digital forensics, data recovery, network monitoring, and spoofing. It should primarily be used as a honeypot or network monitoring platform as well as a laboratory and teaching aid. There are three honeypots installed – honeyd, nepenthes, and dionaea. Four, if you include netcat.
The majority of the additional applications reside in /opt:
Dionaea (0.1.0) – Dionaea is a malware collection honeypot focusing primarily on SMB emulation, covered on InfoSanity numerous times before.
FFP – Fuzzy Fingerprinting is a util to aid SSH MitM attacks.
Kippo (svn rev.169) – Kippo is an low-medium interaction SSH honeypot, Also covered
mitm-ssh – Unsurprisingly, a utility for aiding man in the middle attacks against SSH connections.
Zerowine-vm – A malware behavior analysis platform. I’ve covered ZeroWine here before, and whilst I find it useful for initial analysis I found it a pain to setup and get running. The fact this works out of the box on Mercury is enough reason alone to keep the .iso handy.
Other tools are installed on the system as started, access from standard locations (/etc, /usr/bin, etc.). I won’t try to list them all, but some highlights include:
Wireshark – Packet capture and network analysis tools.
I could go on, but I’m sure you get the idea.
Setting up a honeypot, and analysing the results, has never been easier. And I’m sure the toolkit’s functionality will also be useful in other scenarios; incident response, general network administration or as a safe learning platform. So what are you waiting for?
N.B. there have been several mirror’s and downloads established, the most reliable download source I’ve used is Markus’ mirror at carnivore.it
This week I was interviewed for the Disaster Protocol Security Podcast. My theory is that everyone else was superstitious and didn’t want to risk being on number 13, so they got stuck with me…..
Basically, the interview is just me talking about honeypots and some of the results and findings that have been discussed discussed both on this blog and via Twitter. Hopefully you’ll find it an interesting listen, and hopefully you’ll be able to understand me. Seems a fewpeople have struggled so I’ll need to work on my ‘BBC English’ next time around….
Always interested in hearing others thoughts or comments on honeypots or infosec in general; so if you liked, disliked or disagreed with any of the content let me know.
The podcast episode can be downloaded here.
This morning I cause myself a problem. Annoyingly it was foreseeable and avoidable, this is my excuse (not great, but I’ll stick to it). But as every problem is merely an opportunity in disguise whist I’m re-building systems I might as well document the process. The original InfoSanity guide for installing Kippo was based off of the latest stable version, but I rapidly migrated to the development SVN on learning of the MySQL logging capabilities, so this guide covers that. Packages
As I’m using a Debian system a lot of the system pre-requisites are packaged, this aren’t all needed immediately but we might as well grab them all at once.
That’s it, all that is required to get the system running. To confirm you can ssh locally with ssh -p2222 email@example.com, unless you’ve jumped ahead and edited the config, password will be 123456. MySQL
Log into MySQL via commanline, assuming you’ve not modified the kippo.cfg database directives build the database:
create database kippo;
grant all on kippo.* to ‘kippo’@’localhost’ identified by ‘secret’;
Next edit the kippo.cfg accordingly you database/user/password and uncomment the [database] configuration directives. REMEBER to uncomment ;[database] line not just the parameters, that has now caught me out twice.
Finally, build the database structure with the script that can be found in <kippo>/doc/sql/:
doc/sql/# mysql -ukippo -psecret kippo < mysql.sql
Restart your Kippo process and you should be good; re-test access to the shell and view the database tables to confirm that logs are being written to the database.