Jon Anderson, Ben Laurie, Kris Kennaway, and I were pleased to see prominent mention of Capsicum in the recent FreeBSD 9.0 press release:

Continuing its heritage of innovating in the area of security research, FreeBSD 9.0 introduces Capsicum. Capsicum is a lightweight framework which extends a POSIX UNIX kernel to support new security capabilities and adds a userland sandbox API. Originally developed as a collaboration between the University of Cambridge Computer Laboratory and Google and sponsored by a grant from Google, FreeBSD was the prototype platform and Chromium was the prototype application. FreeBSD 9.0 provides kernel support as an experimental feature for researchers and early adopters. Application support will follow in a later FreeBSD release and there are plans to provide some initial Capsicum-protected applications in FreeBSD 9.1.

“Google is excited to see the award-winning Capsicum work incorporated in FreeBSD 9.0, bringing native capability security to mainstream UNIX for the first time,” said Ulfar Erlingsson, Manager, Security Research at Google.

We first wrote about Capsicum, a hybridisation of the capability system security model with POSIX operating system semantics developed with support from Google, in Capsicum: practical capabilities for UNIX (USENIX Security 2010 and ;login magazine). Capsicum targets the problem of operating system support for application compartmentalisation — the restructuring of applications into a set of sandboxed components in order to enforce policies and mitigate security vulnerabilities. While Capsicum’s hybrid capability model is not yet used by the FreeBSD userspace, experimental kernel support will make Capsicum more accessible to researchers and software developers interested in deploying application sandboxing. For example, the Policy Weaving project at the University of Wisconsin has been investigating automated application compartmentalisation in support of security policy enforcement using Capsicum.

Earlier this month, I blogged about monitoring password-guessing attacks on a server, via a patched OpenSSH. This experiment has now been running for just over two weeks, and there are some interesting results. I’ve been tweeting these since the start.

As expected, the vast majority of password-guessing attempts are quite dull, and fall into one of two categories. Firstly there are attempts with a large number of ‘poor’ passwords (e.g. “password”, “1234″, etc…) against a small number of accounts which are very likely to exist (almost always “root”, but sometimes others such as “bin”).

Secondly, there were attempts on a large number of accounts which might plausibly exist (e.g. common first names and software packages such as ‘oracle’). For these, there were a very small number of password attempts, normally only trying the username as password. Well established good practices such as choosing a reasonably strong password and denying password-based log-in to the root account will be effective against both categories of attacks. Surprisingly, there were few attempts which were obviously default passwords from software packages (but they perhaps were hidden in the attempts where username equalled password). However, one attempt was username: “rfmngr”, password: “$rfmngr$”, which is the default password for Websense RiskFilter (see p.10 of the manual).

There were, however, some more interesting attempts. One category was passwords far too complicated to be in a standard password dictionary, or even found through offline-brute-force attacks on a hashed password database (e.g. “TiganilAFloriNTeleormaN”, “Fum4tulP0@t3Uc1d3R4uD3T0t!@#$%^%^&*?”, and “kx028897chebeuname+a”). The best guess is that these passwords were collected from an unhashed password database, or from a trojaned SSH server or client. Theo Markettos identified a likely source for this password database. Other odd password attempts include plain hashes (e.g. E4F89B211D997C1D5ECCE2153DC9184A which is the MD5 of “upintheair”, found by Google), salted hashes (e.g. $1$EdkQIoSn$T3gzKLxlcxF7tsTCFqC8M) and filenames (e.g. “/var/run/sshd22.pid” and “/var/run/sshd”).

One conclusion which can be drawn is that this attacker does not care enough about the quality of the password database to filter out passwords which it makes almost no sense to use. This carelessness is supported by the fact that after I initially enabled my patched SSH server, I received many log-in attempts but no passwords. It turned out that the default FreeBSD configuration is to only support keyboard-interactive authentication, rather than the more limited password authentication. The brute force attack tool only attempted password authentication, and therefore was always rejected before any password was sent, so the attack was running for days without ever having a hope of succeeding. I did enable password authentication, but some later attacks, presumably using a different tool and probably from a different attacker, attempted both keyboard-interactive and password authentication.

One attack I hadn’t seen before was to try a large number of usernames, and parts of the hostname as password. For a hostname of the style MACHINE.DOMAIN.DEPARTMENT.cam.ac.uk, the attack tried DOMAIN, DOMAIN.DEPARTMENT, MACHINE, then MACHINE.DOMAIN. This clearly isn’t a dictionary but a bit of custom code which did a reverse DNS lookup on this host then generated some possible passwords. Using the hostname as a password for a host isn’t a good idea, but I can imagine some sysadmins doing so. The fact that some attackers are taking this approach might merit some explicit statement in password selection guidance.

Another curious trend was receiving meta-data as username/passwords. This might be due to the brute force tool not properly interpreting comments in the dictionary file, or the attacker not understanding the comment notation. For example I received the following username/passwords:

• [uratu/was HERE]
• [I`m/A HaCkER ON]
• [This/Is A Blow ShiT]
• [acest/este:varza]
• [data.conf/contzine]
• [peste=6.000/de:usere]
• [setate/=<SweetSoul>
• [checking/SweetSoul]\\par

It looks like the attacker thinks that square brackets are comment notation, but the brute force tool simply sends the text as SSH username/password pairs. There also seems to be a Romanian language connection. For example, “acest este varza” according to Google means “this is cabbage” (perhaps an idiom), “contzine” means “list any”, “peste de usere” means “over the user”, “setate” means “set”. The Romanian connection also came up in the previous post where Romanian for “Handbook of Mechanical Engineering” was tried as a password.

Attentive readers will note the “\\par” in the above list perhaps indicating that the file was converted to RTF at some point. This appears indeed to be the case from the later attempt of username: “\\*\\generator”, password: “Msftedit 5.41.21.2508;}…[checking uratu]\\par”. From this we can also conclude that the attacker is using Windows WordPad.

Overall it was an interesting experiment, with some conclusions confirmed but a few surprises. However, this was only a two week experiment on a single machine, so care should be taken in drawing generalisations which assume that these results are typical.

Privacy and anonymity are increasingly important in the online world. Corporations, governments, and other organizations are realizing and exploiting their power to track users and their behavior. Approaches to protecting individuals, groups, but also companies and governments, from profiling and censorship include decentralization, encryption, distributed trust, and automated policy disclosure.

The 12th Privacy Enhancing Technologies Symposium addresses the design and realization of such privacy services for the Internet and other data systems and communication networks by bringing together anonymity and privacy experts from around the world to discuss recent advances and new perspectives.

The symposium seeks submissions from academia and industry presenting novel research on all theoretical and practical aspects of privacy technologies, as well as experimental studies of fielded systems. We encourage submissions with novel technical contributions from other communities such as law, business, and data protection authorities, that present their perspectives on technological issues.

Submissions are due 20 February 2012, 23:59 UTC. Further details can be found in the full Call for Papers.

There’s a huge literature on the properties of static or slowly-changing social networks, such as the pattern of friends on Facebook, but almost nothing on networks that change rapidly. But many networks of real interest are highly dynamic. Think of the patterns of human contact that can spread infectious disease; you might be breathed on by a hundred people a day in meetings, on public transport and even in the street. Yet if we were facing a flu pandemic, how could we measure whether the greatest spreading risk came from high-order static nodes, or from dynamic ones? Should we close the schools, or the Tube?

Today we unveiled a paper which proposes new metrics for centrality in dynamic networks. We wondered how we might measure networks where mobility is of the essence, such as the spread of plague in a medieval society where most people stay in their villages and infection is carried between them by a small number of merchants. We found we can model the effects of mobility on interaction by embedding a dynamic network in a larger time-ordered graph to which we can apply standard graph theory tools. This leads to dynamic definitions of centrality that extend the static definitions in a natural way and yet give us a much better handle on things than aggregate statistics can. I spoke about this work today at a local workshop on social networking, and the paper’s been accepted for Physical Review E. It’s joint work with Hyoungshick Kim.

Last year when I wrote a paper about mitigating malware I needed some figures on the percent of machines infected with malware. There are a range of figures, mainly below 10%, but one of the highest was 25%.

I looked into why this occurred and wrote it up in footnote #9 (yes, it’s a paper with a lot of footnotes!). My explanation was:

The 2008 OECD report on Malware [14] contained the sentence “Furthermore, it is estimated that 59 million users in the US have spyware or other types of malware on their computers.” News outlets picked up on this, e.g. The Sydney Morning Herald [20] who divided the 59 million figure into the US population, and then concluded that around a quarter of US computers were infected (assuming that each person owned one computer). The OECD published a correction in the online copy of the report a few days later. They were actually quoting PEW Internet research on adware/spyware (which is a subtly different threat) from 2005 (which was a while earlier than 2008). The sentence should have read “After hearing descriptions of ’spyware’ and ‘adware’, 43% of internet users, or about 59 million American adults, say they have had one of these programs on their home computer.” Of such errors in understanding the meaning of data is misinformation made.

We may be about to have a similar thing happen with Facebook account compromises.

On Jan 4, ZoneAlarm published a blog article along with this graphic (I’ve provided a local copy because I hope that all other copies will get destroyed!). One of its key findings was:

• 4 million Facebook users experience spam on a daily basis.
• More than 20% of newsfeed links currently open viruses.
• 600,000 logins are compromised every day. That’s 7 logins every second.

The graphic now says:

• 4 million Facebook users experience spam on a daily basis.
• 20% of Facebook users have been exposed to a virus.
• Facebook sees 600,000 attempts to hijack logins a day and pre-emptively protects against them.

which, you have to agree is really rather different.

This blog article is sceptical, but not (entirely) corrected — I quote it because it mentions the PR reasons behind Zonealarm’s statistics (they sell a product which purportedly protects you), and because it mentions that other people had been confused about the 600,000 figure in the past.

So I looked into where the 600,000 figure originated, and found that it’s original source was Facebook!

This post by Graham Cluley at Sophos draws attention to Facebook’s graphic (original copy here) accompanying an Oct 27 2011 article about their security mechanisms which said:

• Less than 4% of content shared on Facebook is spam.
• Only .06% of over 1 billion logins per day are compromised.
• Less than .5% of Facebook users experience spam on any given day.

Graham did the simple multiplication required to produce the 600,000 compromise figure, which is the same sum as Zonealarm’s PR people have done. Similarly the “less than .5%” translates to the 4 million figure they use.

However, if you look at the official Facebook copy of the infographic accompanying their blog post today (copy here) then you can see they have revised it. It now just has the data points:

• Less than 4% of content shared on Facebook is spam.
• Less than .5% of Facebook users experience spam on any given day.

In fact they revised their report pretty much immediately after they first posted it, when journalists started ringing! In this article on the topic Facebook is quoted as saying that the 600,000 is a count of logins that are blocked because Facebook is not convinced it is the account owner who is doing the login — so if some criminal tries a brute force guessing attack on 850 accounts, getting around to each one every 2 minutes, they alone would create the 600,000/day figure!

Time will tell whether the original meme survives, but perhaps people searching for a source to cite will encounter this blog post (or indeed this one which looks at the spam data) and avoid promulgating misleading data the way that Zonealarm has done.

PS: So far I cannot source the Zonealarm “20% of newsfeeds figure” to see how that came about, but I’m keeping looking.

The USENIX Security Symposium brings together researchers, practitioners, system administrators, system programmers, and others interested in the latest advances in the security of computer systems and networks. The 21st USENIX Security Symposium will be held August 8–10, 2012, in Bellevue, WA.

All researchers are encouraged to submit papers covering novel and scientifically significant practical works in computer security. Submissions are due on Thursday, 16 February 2012, 11:59 p.m. PST. The Symposium will span three days, with a technical program including refereed papers, invited talks, posters, panel discussions, and Birds-of-a-Feather sessions. Workshops will precede the symposium on August 6 and 7. Further details can be found in the full Call for Papers.

In common with other USENIX conferences, the proceedings of USENIX Security 2012 will be open access, and made available for free to everyone from the first day of the event.

I recently set up a server, and predictably it started seeing brute-force password-guessing attempts on SSH. The host only permits public key authentication, and I also used fail2ban to temporarily block repeat offenders and so stop my logs from being filled up. However, I was curious what attackers were actually doing, so I patched OpenSSH to log the username and password for log-in attempts to invalid users (i.e. all except my user-account).

Some of the password attempts are predictable (e.g. username: “root”, password: “root”) but others are less easy to explain. For example, there was a log-in attempt for the usernames “root” and “dark” with the password “ManualulIngineruluiMecanic”, which I think is Romanian for Handbook of Mechanical Engineering. Why would someone use this password, especially for the uncommon username “dark”? Is this book common in Romania; is it likely to be by the desk of a sys-admin (or hacker) trying to choose a password? Has the hacker found the password in use on another compromised system; is it the default password for anything?

Over the next few weeks I’ll be posting other odd log-in attempts on my Twitter feed. Follow me if you would like to see what I find. Feel free to comment here if you have any theories on why these log-in attempts are being seen.

Every Christmas we give our friends in the banking industry a wee present. Sometimes it’s the responsible disclosure of a vulnerability, which we publish the following February: 2007’s was PED certification, 2008’s was CAP while in 2009 we told the banking industry of the No-PIN attack. This year too we have some goodies in the hamper: watch our papers at Financial Crypto 2012.

In other years, we’ve had arguments with the bankers’ PR wallahs. In 2010, for example, their trade association tried to censor one of our students’ thesis. That saga also continues; Britain’s bankers tried once more to threaten us so we told them once more to go away. We have other conversations in progress with bankers, most of them thankfully a bit more constructive.

This year’s Christmas present is different: it’s a tale with a happy ending. Eve Russell was a fraud victim whom Barclays initially blamed for her misfortune, as so often happens, and the Financial Ombudsman Service initially found for the bank as it routinely does. Yet this was clearly not right; after many lawyers’ letters, two hearings at the ombudsman, two articles in The Times and a TV appearance on Rip-off Britain, Eve won. This is the first complete case file since the ombudsman came under the Freedom of Information Act; by showing how the system works, it may be useful to fraud victims in the future.

For your Christmas entertainment, we offer the bank statement which told Eve of the fraud; the initial exchange of letters between Eve’s lawyers and the bank; the ombudsman’s routine initial ruling against Eve, and her protest; the correspondence between the ombudsman and Barclays; Eve’s appeal and expert opinion; the verdict; and the offer of settlement. And let’s not forget the Thunder. A Merry Christmas to all!

The UK’s National Blood Service screens all donors for a variety of health and lifestyle risks prior donation. Many are highly sensitive, particularly sexual history and drug use. So I found it disappointing that, after consulting with a nurse who took detailed notes about specific behaviours and when they occurred, I was expected to consent to this information being stored indefinitely. When I pressed as to why this data is retained, I was told it was necessary so that I can be contacted as soon as I’m eligible again to donate blood, and to prevent me from donating before that.

The first reason seems weak, as contacting donors on an annual or semi-annual basis wouldn’t greatly decrease the level of donation (most risk-factor restrictions last at least 12 months or are indefinite). The second reason is a security fantasy, as it would only detect donors who lie at a second visit after being honest initially. I doubt donor dishonesty is a major problem and all blood is tested anyway. The purpose of lifestyle restrictions is to reduce the base rate of unsafe blood because all tests have false negatives. Storing detailed donor history doesn’t even have much time-saving benefit: history needs to be re-taken before each donation, since lifestyle risks can change.

I certainly don’t think the NBS is trying to stockpile data for nefarious reasons. I expect instead that the increasingly low technical costs of storing data speciously justify its very minor secondary uses if one ignores the risk of a massive compromise (NBS gets about 2 M donors per year). I wonder whether the inherent hazard of data collection was considered in the NBS’ cost/benefit analysis when this privacy policy was adopted . Security engineers and privacy advocates would do well to advocate non-collection of sensitive data before fancier privacy-enhancing technology. The NHS provides a vital service but they can’t do it without their donors, who are always in short supply. It would be a shame to discourage anybody from donating and being honest about their health history by demanding to store their data forever.

We are pleased to announce a job opening at the University of Cambridge Computer Laboratory for a post-doctoral researcher working in the areas of security, operating systems, and computer architecture.

Research Associate
University of Cambridge – Faculty of Computer Science & Technology

Salary: £27,428 – £35,788 pa
The funds for this post are available for one year:

We are seeking a Post-doctoral Research Associate to join the CTSRD Project, which is investigating fundamental improvements to CPU architecture, operating system (OS), and programming language structure in support of computer security. The CTSRD Project is a collaboration between the University of Cambridge and SRI International, and part of the DARPA CRASH research programme on clean-slate computer system design.

This position will be an integral part of an international team of researchers spanning multiple institutions across academia and industry. The successful candidate will contribute to low-level aspects of system software: compilers, language run-times, and OS kernels. Responsibilities will include researching the application of novel dynamic techniques to C-language operating systems and applications, including adaptation of the FreeBSD kernel and LLVM compiler suite, and measurement of the resulting system.

An ideal candidate will hold (or be close to finishing) a PhD in Computer Science, Mathematics, or similar with a strong background in low-level system software development, which should include at least of one of strong kernel development experience (FreeBSD preferred; Linux acceptable), or compiler internals experience (LLVM preferred; gcc acceptable). Strong experience with the C programming language is critical. Some background in computer security is also recommended.

Candidates must be able to provide evidence of relevant work demonstrated by a research publication track record or industrial experience. Good interpersonal and organisational skills and the ability to work in a team are also essential. This post is intended to be filled as soon as practically possible after the closing date.

Applications should include:

• Curriculum Vitae
• Brief statement of the particular contribution you would make to the project
• A completed form CHRIS6

Completed applications should be sent by post to: Personnel-Admin,Computer Laboratory, William Gates Building, JJ Thomson Avenue, Cambridge, CB3 0FD, or by email to: personnel-admin@cl.cam.ac.uk

Quote Reference: NR10692
Closing Date: 10 January 2012

The University values diversity and is committed to equality of opportunity.