I’m going to be at CCS 2010 in Chicago this week presenting @spam: The Underground on 140 Characters or Less. My presentation is the 3rd talk of the conference in the security session (on the first day).
email@example.com and firstname.lastname@example.org are going to stop working this Friday! CITES is officially done forwarding my email. Use my new ones @berkeley.edu, or better yet: email@example.com!
At the beginning of the year, in the middle of the project that led to the CCS paper on Twitter spam, I decided to try out Amazon Web Services. As I’ve slowly become familiar with the process, I’ve found that more and more I can make use of EC2, S3, Elastic Map Reduce, or even Virtual Private Cloud for what I’m working on.
Sometimes this is a mixed blessing – I spend a bunch of time working out how to use a certain AWS feature, when I could have just ran with something I baked myself. Other times, it’s awesome.
One of the current projects I’m working on is building a service that can quickly identify URLs as being spam, the target being a service that Facebook, Twitter, or anyone else could add into the line of fire and remove bad messages before they are seen a few thousand times (and reported as spam or phishing).
For the most part, our stuff is up and working –and even works at quite a large volume on relatively small amount of computers. What’s even better is that it’s currently operating on AWS, running a reduced volume (1 million URLs per day) on medium sized instances, for around $.00086/URL (works out to $860/month for 1 million URL capacity). We’ve also been testing to see if this scales, and it looks like it does! a little less than linearly with the number of URLs we need to handle per day. As we evaluate more of the system we’ve built and write the paper, I’ll post a few updates on how it’s built and what we are using to make it all work.
In the summer of 2007 I wrote a paper on the OP web browser that was published at Oakland in 2008. A few months afterward I was invited to submit it as a “fast tracked” paper in a journal. I thought it would be a easy way to add in some of the work we had done while working on and using OP since summer 2007.
If, or when, the journal paper actually gets published, security and systems researchers will have been using OP since November 2007 (3 years ago!), Chrome since Sept 2008 (2 years ago!), had the opportunity to read the Gazelle paper (summer 2009), use Firefox with out-of-process plugins (spring 2010), and possibly even try out a full multi-process Firefox (upcoming release?), not to mention LCIE in IE8 (spring 2009). And this list doesn’t even include the many other security improvements that have been made in these browsers by both researchers and industry.
My paper about spam on Twitter has been accepted into ACM Conference on Computer and Communications Security in Oct 2010. It’s going to be a fun presentation in Chicago, and I’m looking forward to continuing the project now that we have the first part of our work out on it.
Overall it was an interesting project that’s goal was to understand spam on Twitter and what, if anything, is the difference between Twitter spam and email spam (besides that it’s shorter). More details on the results and analysis after the camera ready…
Chris Grier, Kurt Thomas, Vern Paxson and Michael Zhang, “@spam: The underground on 140 characters or less,” To appear in the Proceedings of the ACM Conference on Computer and Communications Security (CCS), October 2010.
I’ve put added recent publications to the research page including links to the PDFs. Shuo presented our paper on Alhambra at WWW, Cho presented our paper on MegaD infiltration at LEET, and Kurt will be presenting unFriendly at PETS this summer which is a project that examines multi-party privacy on Facebook. If we are lucky, I’ll be presenting a Twitter-related paper next Fall.
Short paper summaries:
Alhambra – a browser-based replay system to test client side security policies. Using replay and comparison metrics we can quickly and automatically determine if a particular browser security policy breaks web applications.
MegaD infiltration – Developed milkers to continually monitor and participate (in a safe manner) in the command and control network used by the MegaD spamming botnet. We present our analysis of four months of C&C infiltration.
unFriendly – Examined multi-party privacy on Facebook. Multi-party privacy conflicts exist when one user has more restrictive privacy settings than their friend and using simple data mining techniques, we are able to infer private profile attributes by examining the conflicts that exist for users on Facebook.
Last fall I moved to Berkeley and started as a postdoc in the EECS department for Vern Paxson. I’ve been there now for about 4 months working on a number of different security topics ranging from web security to bot nets.
On the web front we just found out that we have a paper in WWW 2010 on a system named Alhambra, that was the third (and final) part of my dissertation.
On bots, I’ve taken some responsibility on the farming of bots, including testing new malware binaries, attempting to identify malware, and keeping bots running in an environment where we can monitor them.
Another interesting project has involved Twitter (with Steve and Kurt), and I’ve been doing a lot of infrastructure work to get our code running on the scale we need. Python, Amazon’s EC2, and the multiprocessing library seem to be the key so far to making things work the scale we are aiming for.
Finally, climbing – There’s been a lot of weekend trips since I moved here: Yosemite, Kings Canyon, Pinnacles national monument, Mount Diablo, Bishop, Owns River gorge, Castle Rock state park, and probably others. Climbing a lot at Berkeley Ironworks too.
I have just about finished moving out to Berkeley, CA where I have started my position as a postdoc. Now that I almost have a computer setup, its about time to get pictures on here from Red River Gorge, KY and Red Rocks Canyon, NV, the two most recent climbing trips. The RRG trip was this last summer leaving from UIUC with Kurt, Mirella, Justin and Carolyn. The Red Rocks trip was during all our free time during DEFCON, about 4 trips each.
RRG – Climbed for two days, then it started raining. We hit Muir Valley (practice wall area) and the Natural Arch (roadside crag). There’s plenty of climbing all over, but unless you comfortably can climb 5.12 sport or trad, be prepared to drive around to find stuff that’s in your range.
Red Rocks – Mostly climbed at First and Second Pullout, at Black Corridor, the Gallery, and the Panty Wall. The Black Corridor was right in our range for climbing, not impossible, but a good range of routes to climb during the day (and in the shade). The panty wall was simply too easy, and would have been a good warmup if it wasn’t already 105 deg outside. The Gallery area was good but not as big as I expected and it took us a long time to find the right approach. It was our last day so we were tired from DEFCON and the other days of climbing, so a few hours in the morning shade climbing and we had done most of the routes we wanted to.
The Gazelle web browser, which was my summer project in 2008 at MSR, has been getting a lot of press lately and even has a wikipedia page now. It’s interesting to read and see what different writers say and how people have been reacting.
There’s two official docs from MSR on Gazelle, a tech report and the USENIX Security 2009 publication. The publication is an improved version of the TR, so I’d stick with that. If there are more, let me know (firstname.lastname@example.org). I’ve given a couple talks on Gazelle, one at Stanford for EE 380 that is online somewhere, and anyone can email me for my slides.
The project that I designed and developed at MSR last summer is going to be at USENIX security (and was previously a tech report). It’s available as a PDF here.
Simply put, Gazelle is a browser with an OS architecture that provides greater strength against different types of attacks than other browsers. By adopting OS principles the browser is able to provide isolation for different-origin content, with additional control over display and user generated events. There’s a lot more to it and the full details are described in the paper.
Back to UIUC, we have adapted a couple of the ideas from the Gazelle paper into the OP web browser, such as the isolation of frames and the display security (and delegate-once policy), though it is a much different implementation than Gazelle.
Gazelle has been slashdotted a few times (first and second), and there’s a pretty good Arstechnica article on it.
Posted in research