Written by journalist Kevin Poulsen (of wired.coms Threat Level blog), KingPin spans the hacking, cracking and carding underworld spread over several decades. The narrative covers the life and activities of Max Vision, a computer consultant, key member of the carding underworld and ultimately convicted criminal.
From the timescales involved, kingpin covers many years and several of Max’s ‘projects’ made national headlines at the time. Some, like the Pentagon being hacked via a weakness in BIND were folklore by the time I personally entered the infosec profession. While others, like the ongoing wars and takedowns between various carder forums were more recent and featured heavily in the press at the time.
The part of the book that I found fascinating throughout was that I was unaware that many of these, on the surface, unconnected stories were linked to the same individual; plus several more on the legal/whitehat side of the community, some of which I have used and experimented with prior to reading Kingpin, it’s usually interesting to get some of the backstory behind tools in this industry, but it’s especially the case with this backstory.
Equally, I found the portrayal of Max’ early years to be intriguing, reading Kingpin I had the feeling (rightly or wrongly), that the outcome of the story could have been different had a couple of actions and/decisions gone the other way, leaving Max as an asset to the infosec community rather than running one of the largest criminal forums on the net. Can’t help wondering if Max could have ended up being a positive force in the infosec community, or if those that are could have ended up going the same route had circumstances been slightly different.
From the right side of the law, I was fascinated with the details of Special Agent Mularski’s undercover work as Master Splyntr. Like a lot of the content of the book I was familiar with the impact Splyntr had had within carding community from several press articles at the time, but hadn’t dug in too much depth. Knowing more about the time and dedication required by one man that ultimately lead to many arrests I’d like to make an offer to Agent Mularski: if we’re ever in the same place, introduce yourself and the drinks are on me (and hopefully the war-stories are on you).
If you’ve got any interest in information security or crime in general, I’d strongly recommend that you put a few hours aside read Kingpin. If you’re disappointed after you finish I’ll be surprised.
–Andrew Waite
Book Review: Zero day
Written by Microsoft’s Mark Russinovich, Zero Day focuses on the actions of a security consultant who starts a job for a client who’s systems have been infected with unknown malware and taking out of action. With the business losing money and circling the drain whilst it’s systems are out of action the characters rapidly find themselves caught up in a plot far large than they originally signed up for.
The scope of the plot starts out slow, and rapidly expands to cover a full gamut of topics, from skiddies in IRC channels and Russian hackers for hire, to corrupt government officials and Al Qaeda terrorist plots (even Bin Laden turns up in person). Dispite the Hollywood style plot elements, Russinovich keeps the technical aspects of the plot grounded in reality, even to the level that the odd code segment included can be reviewed by a (semi)proficient reader can determine the next plot arc before the characters reach the same conclusions.
The overall story, and the culture the characters operate in clearly show the difference between an author with a technical background and plenty of real world experience with the subject matter, over a proficient author who has had expert assistance to get the technical aspects of a story to a plausible level, and makes a very welcome change in this growing area of fiction. Russinovichs experience working with government and industry parties as part of the recent clampdown on botnets, the work in this area is a clear influence for the Zero Day story arc. Thankfully, Despite this being Russinovichs first novel I found it surprisingly well written, with believable characters and a plot that I became emotionally invested in (and without spoilers, cheered inside when a certain character got what I’d felt from first introduction that they deserved).
If you’ve got any interest in information security, computer/network administration to just good sci-fi I’d strongly recommend picking up a copy of Zero Day, it may be shorter that I would have liked (only because I want MORE) but I thoroughly enjoyed the time spent in its created scenario. Hopefully it will serve as a warning of what could happen, rather than a premonition of an actual occurrence; unfortunately it’s likely that those with the true power to stop events similar to the books plot won’t be interested in the story summary and will miss the warning.
— Andrew Waite
Starting with Artillery
On Friday I arrived home looking forward to a well-earned rest; unfortunately Dave Kennedy seemed to have other ideas for my weekend as he announced the alpha release of a new honeypot, Artillery.
Artillery is a combination of a honeypot, file monitoring and integrity, alerting, and brute force prevention tool. It’s extremely light weight, has multiple different methods for detecting specific attacks and eventually will also notify you of insecure nix configurations.
Installation of Artillery is currently really simple, download via svn, run the installer script, edit the config file (if necessary) and run:
$svn co http://svn.secmaniac.com/artillery artillery/
$./installer.py
$nano config
$./artillery.py
N.B. don’t make the same daft error I made initially by editing the files in the svn download. Once the installer.py script has been run, cd to /var/artillery.
Artillery goes beyond typical honeypots, as it actively blocks remote clients and protects the system it’s running on. Artillery listens on a number of common ports (configurable, look at the PORTS variable), if it receives a connection on any of the fake ports it permanently blocks the source IP address by adding a DROP rule to iptables.
From my experience Artillery gets results REALLY quickly. After getting the system online I performed a quick test from another host under my control and starting writing up this post; in the time it’s taken to write the content above Artillery has already added 8 addresses to iptables:
Chain INPUT (policy ACCEPT) target prot opt source destination DROP all -- host-31-42-163-53.pois.com.ua anywhere DROP all -- net242.187.188-2.oren.ertelecom.ru anywhere DROP all -- 94-21-36-156.pool.digikabel.hu anywhere DROP all -- 89.122.216.109 anywhere DROP all -- ras.beamtele.net anywhere DROP all -- dsl5401A8C9.pool.t-online.hu anywhere DROP all -- catv-178-48-151-67.catv.broadband.hu anywhere DROP all -- 176.14.205.91 anywhere
Other functionality included in Artillery mirrors that of Tripwire, monitoring the contents of different directories (again, configurable) and generating alerts if the contents of the directories and files changes.
I really like the premise of Artillery, and Dave in his usual fashion is coding like a madman adding fixes and new functionality (new version, 0.1.1 was released 24hrs after initial announcement). I’d be wary where you set this system up to test it though due to the automatic lockout; if Artillery is on a remote system, and you connect to a dummy port from your location to test you’ve just been locked out of your own server 😉
Looking forward to seeing Artillery mature, thanks Dave.
–Andrew Waite
AVG & FUD?
Like most techies I get the job of fixing and maintaining relatives’ PCs. As part of this after fixing whatever is broken I have some common clean-up and install routines that I go through to both help the system run faster and to extend the period before I’m called back, and I’ve used AVG free as part of this for many years to keep costs down for my users.
During a recent job I came across a new (I’m assuming, hadn’t noticed it before) feature of AVG free, the PC Analyzer component. Being the curious sort I hit the go button, scan ran for around 5 minutes and I was presented with this:
Ouch, I was surprised with the number of errors as this is a machine I keep a regular eye on, and in some cases use myself (it’s the missus’). Time to panic? Let’s see:
- Registry errors: Errors affect system stability: (125)
That doesn’t sound good, checking the ‘Details…’ link presented me with a long list Registry keys, which to a standard end-user would result in turning on BofH’s Dummy Mode. In reality, it found a lot of keys to set the ‘open with’ right-click function depending on file extension. ‘Affect system stability’? Not so much, and I find the links useful enough that I’ve previously researched how to add my own…
- Junk Files: These files take up disk space: (599)
Again checking the details, long list of randomly named files. In the temporary folder. All ~600 took a total of less the 300MB, and the machine has more the 200GB free. Something to correct come next house cleaning session, but not really a problem.
- Fragmentation: Reduces disk access speed
In fairness to the tool, it did come back clean and we know that fragmentation can be an issue. But that’s why every machine I’ve ever used has come with a defrag utility, as standard, for free. (OK, my BBC Micro B didn’t, but then it also had a cassette deck rather than a hard disk).
- Broken Shortcuts: Reduces explorer browsing speed(42)
Ok, so I forget a folder of shortcuts to junk that came pre-installed with the system. I’d deleted the junk, forgot the shortcuts. Thanks for the reminder, fixed.
Summary
Plenty of ‘problems’ highlighted, time to run out and drop £25 for an annual subscription to the clean-up tool? Nope, ignoring the fact that many of these issues are system settings that actually aid the end user, the remaining issues won’t have any negative impact that the end-user will notice.
In my own opinion, AVG is taking a leaf out of the fake AV scams and scaring non-techies into parting with their hard earned coin in a bid to keep the computer running and bank details away from the scary hackers that the nice lady on the news keeps taking about. Presenting a list of meaningless (to most) information and saying it’s bad is exactly the tactic I encountered with cold call scammers earlier in the year.
As a final side note, I’ve lost two of my ‘users’ this year to AVG simply because when the AVG free license I’d installed expired, they couldn’t find a link to download the latest free version, only MANY links to the paid version. As my users are nice people (latest ‘victim’ was my grandfather), they decided themselves that it was better for them to pay the small fee than have to call me and interrupt my life.
Can anyone recommend a free AV suite that doesn’t con the unwitting into unnecessary purchases to perform a cleanup that could be performed manually with around 5 minutes and half a clue? AVG Free is a great tool, and for free I shouldn’t really complain, but when the sales tactics change to make money selling things people don’t need, to those that don’t know any better?
–Andrew Waite
Recover corrupt KeepNote filestructure
<update>Further investigation has shown that data has been restored, but the tree structure isn’t perfect. Use at own risk</update>
Anyone who’s taken Offensive Security training should be familiar with KeepNote (similar to Leo, for those that took early versions of the courses). If you’re not familiar with KeepNote it does exactly what you’d expect from the name, provide a handy way to keep and organise information. And it does a good job of this, until….
Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/keepnote/gui/__init__.py", line 469, in open_notebook version = notebooklib.get_notebook_version(filename) File "/usr/local/lib/python2.6/dist-packages/keepnote/notebook/__init__.py", line 248, in get_notebook_version raise NoteBookError(_("Notebook preference data is corrupt"), e) NoteBookError: SyntaxError('junk after document element: line 11, column 0',) Notebook preference data is corrupt root@bt:~/pwbv3/labnotes#
Aaaarrgh!
After much searching I found several posts discussing similar issues but following the same resolutions did not resolve by problems. With this I resorted to my fallback plan, create new notebook and begin to repopulate with my content (each node is stored as a plain text file, so I was looking at lots of cut and paste). Then a thunderbolt hit me.
I copied each branch of the original note tree to the new tree, and hay-presto! functioning notebook retained and disaster averted.
cp -r ~/old-notebook/branch/ ~/new-notebook/.
Of course a better solution is just to hit the ‘File>Backup Notebook’ option occasionally.
–Andrew Waite
Kippo – Clearing pass.db
Very quick post to highlight a process for clearing all entries from your pass.db file. I had thought that this would take a bit of quick scripting utilising the list and remove modes from the passdb.py utility script. Turns out it’s even easier; simply pass a non-existent file to passdb.pyass.db parameter and it’ll create a fresh database file, no questions asked.
For example:
/opt/kippo/utils/passdb.py /opt/kippo/data/idontexistyet.db add testpassword
Will create a new database file with a single entry of ‘testpassword’ (this can be removed once you’ve established everything works). N.B. even with a blank pass.db, kippo will provide access to the password(s) configured in kippo.cfg.
Not sure yet if clearing the database will net any interesting results, only time will tell…..
–Andrew Waite
Kippo – pass.db
After a few weeks running my daily Kippo review script I’ve noticed that whilst I’m still mostly receiving several logins per day, it’s rare for a connection to actually interact with my emulated system. (For those new here, Kippo is a medium interaction honeypot emulating an SSH daemon, get started here). So I started trying to investigate what was causing the trend.
One of Kippo’s features is the password database. Basically once an intruder gains access to the shell if they try to change the password or add a different account the system adds the password to the list of allowed. This then allows connections to log into the shell with the new password. Kippo ships with a small utility script to interact with the password database:
@kippo01:/opt/kippo-svn/utils$ ./passdb.py Usage: passdb.py <pass.db> <add|remove|list> [password]
My pass.db file contains 26 entries added by malicious ‘users’; I’m still analysing the contents in detail, but it looks like the Bad Guys(tm) are paying attention to user education 101 and using long, complex passwords.
Using the password used to log into the system, I’ve had a new (to me) way to link disparate logins. For example the query below linked connections spanning two months, originating from multiple source IP address, across three different continents (according to WHOIS records).
Source IPs for same user (based on pass)
SELECT sessions.id AS Session, sessions.ip AS Source, auth.password AS Password, auth.timestamp AS Time FROM sessions, auth WHERE sessions.id = auth.session AND auth.success = 1 AND auth.password = 'mariusbogdan';
Similarly I looked for a connection between multiple successful logins from the same source IP address. The query below provided a list of report offenders:
Successful logins from same source
SELECT COUNT(sessions.ip) AS Num, sessions.ip AS Source FROM sessions, auth WHERE auth.success = 1 AND auth.session = sessions.id GROUP BY sessions.ip ORDER BY COUNT(sessions.ip) desc LIMIT 25;
My summary from this is that Kippo is receiving a lower level of ‘interesting’ connections the longer the system is operational, as attackers login to check if they’ve maintained access to an ‘0wned’ resource, without utilising the resource. I’m intending to clear my pass.db to remove existing access; hopefully this will return to more interesting connections and I’m also curious to see if any of my current tenants return from either the same source location(s) and/or re-using passwords (and proving me wrong with previous comment about user education).
–Andrew Waite
Reviewing Kippo Logs
When I first started running Kippo almost a year ago I had no difficulty getting motivated to log into the honeypot, check for new connections and generally get a feel for what my victims visitors have been up to. As time went by, sessions started to follow familiar patterns and some days would get no hits. Slowly I’d check the logs less frequently, and when I did I’d get an ever increasing backlog to review, decreasing my motivation further.
Recently I got annoyed with myself, my system was ticking along in the background but I was gaining no benefit from it. So in a moment of madness I dusted off my bash and built a quick script to provide a daily review of activity on my system. Essentially this does two things, lists session interaction and files downloaded within the last 24hours.
I’ve had the routine running daily for around a week; for days there was minmal activity on my system, either no logins at all, or logins with immediate disconnects. Today was different, and marked the first success of the script. Delivered to my morning inbox, along with the rest of my regular quick tasks and RSS feed as an interesting session. Malicious user connects, downloads a scanner (archive contents looks like gosh), an irc bot (looks like EnergyMech derivative); and when attempts to run toolkit fail, downloads and runs three (yes, three, paranoia is strong with this one) log cleaners.
Example (snipped) output:
:~$ /opt/kippo-svn/kippo-sessions.sh ***Sessions*** ---START:/opt/kippo-svn/log/tty/20110519-220029-5503.log--- www-dev:~# w 22:00:38 up 14 days, 3:53, 1 user, load average: 0.08, 0.02, 0.01 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root pts/0 77.210.18.212 22:00 0.00s 0.00s 0.00s w <SNIP> ***DOWNLOADS*** /opt/kippo-svn/dl/20110519220445_http___eduteam_home_ro_mech_gz: gzip compressed data, from Unix, last modified: Sun Oct 4 17:46:52 2009 <SNIP>
The script can be downloaded here, as usual it’s released under the Beerware License
–Andrew Waite
Network sniffing in VMware ESXi
VMWare ESXi is perfect for a self contained lab, but as I’m used to having full access to a ‘real’ network there are a few things I miss not having control over for testing and other things. The biggest of these is a spanf port (or mirror port depending on your hardware). If you’re not familiar, the basic premise is to configure one (or more ports) to reproduce any traffic flowing through any port(s). This provides packet level access for debugging network problems, passing to an I[D/P]S, etc.
ESXi doesn’t provide this functionality, but does allow you to set a vSwitch to be ‘promiscuous’. Unfortunately this isn’t as controllable as a span/mirror port as (from the quick tests I’ve run) essentially turns the vSwitch into a vHub. Not a problem in my lab environment but you probably want to give it some serious thought before enabling in a production environment; do you really want every server on the network to be able to see all traffic on the (virtual) wire?
To make the change in ESXi you need host -> Configuration -> Networking and set the properties as shown below:
Once this change is made, any guests connected to the vSwitch can all see any of the network traffic on that switch.
For testing you can build a quick lab scenario with 3 live boot BackTrack systems. Each machine has a different role; server, client and ‘sniffer’. The sniffing machine is now able to view direct communication between the other two systems. Using wireshark’s Follow TCP stream functionality shows the conversation:
–Andrew Waite
SSH Tunnelling Example
Towards the end of last year I spent a few hours trialling SSH tunnels, I knew how the process worked but hadn’t had much cause to use it in anger; so my lab got some use instead, and a post was written covering the basics; SSH port forwarding 101.
Since I now know how to quickly and successfully implement a tunnel, it turns out that I previously had plenty of cause to use tunnels in the past, I just didn’t know SSH tunnels were the right tool for the job. A couple of recent conversations has made me realise others don’t always know the flexibility of tunnels either so I wanted to try and describe a common scenario to highlight the usefulness of tunnels.
Scenario:
Above is a fairly common setup. You’ve got an internal resource (for example an intranet wiki for documentation), this is in turn protected by a firewall that only allows access from trusted location. Under normal circumstances all staff can access the resource without problems, and any malicious sources (human or automated) can’t access the service.
This works well, until someone needs access and they aren’t at one of the trusted locations (we’re assuming this is an unusual problem and remote access solutions aren’t in place). In a lot of environments SSH is a ‘trusted’ system management solution and is world accessible (and hopefully secured well enough to keep the barbarians from the door, but that’s for different posts).
Solution?:
SSH tunnels (but you guessed that). Tunnel the server’s HTTP (or whatever) service back to your local system, and then connect locally. Using the syntax I discussed previously, from a ‘nix shell you can use this command:
ssh -L 8000:127.0.0.1:80 ssh-server.domain.com
This makes an SSH connection to the server (ssh-server.domain.com), tunnelling the local HTTP service running on port 80 (127.0.0.1:80) and binds it to your machines TCP 8000 port. Now you can connect to the service by typing 127.0.0.1:8000 into a browser, thus traversing the firewall source IP restrictions.
If you’re living in a Windows world, then the PuTTY equivalent configuration will be:
Next time you’re sat in the coffee shop on a Sunday morning, and the boss rings with an ’emergency’; are you sure that you can’t access the resources you need from where you are? If you can, that coffee (and extra slice of cake) just became expense-able 😉
–Andrew Waite