Abusing OpenID to Increase Server Traffic

Whilst idly watching my syslog recently (as one does), I noticed with some discomfort, that outbound connections were being made from my server, to sites of questionable repute. Something that might indicate that the machine had in some way been compromised. The logs show messages such as:

Aug 20 14:40:20 hostname apache2: Successfully fetched 'http://litjnz.cn/': GET response code 200
Aug 20 14:52:35 hostname apache2: Successfully fetched 'http://tqeetazx.cn/': GET response code 200
Aug 20 15:00:26 hostname apache2: Successfully fetched 'http://cnduiz.cn/': GET response code 200

Aug 20 12:13:54 hostname apache2: CURL error (6): Couldn't resolve host 'byuxlcifxlso.com'
Aug 20 17:24:43 hostname apache2: CURL error (7): couldn't connect to host
Aug 20 17:24:58 hostname apache2: CURL error (28): connect() timed out!
Aug 20 17:25:07 hostname apache2: CURL error (28): Connection time-out

After a little investigation, checking various access logs and processes, and comparing several different logs at once for serendipitous links*, I spotted, with some relief, that my server hadn’t been compromised after all. It was, in fact, the OpenID service that I run from my server, that allows others to login to this site without registering here.

So, any OpenID server can be forced to make a connection to a third party server, and make a page request. This means that (for example) rather than requiring 1000 distributed bots in order to generate network traffic to a server from 1000 locations, all that is required is one bot and a list of 1000 OpenID servers. Such a tactic is useful for black-hat SEO companies, for example, who want to appear to prove that whatever secret magic tactics they’re using to increase traffic are working.

Whilst this form of traffic generation is cute, there is perhaps a more interesting angle. With thousands of OpenID services around already, and hundreds, if not thousands more being added every day, OpenID might become the platform of choice for proxying and amplifying a DDOS attack.

OpenID server software needs to be able to detect and prevent this kind of attack, or the server on which it’s installed is likely to become very unpopular, very quickly.

* Semantic-web based log analysis anyone

9 Comments

Chris Samuel says:

21/08/2009 at 08:06

There is a commercial tool called Splunk http://www.splunk.com/ (free-as-in-beer up to a certain amount of logs per day) which does log aggregation from many sources and searching/correlation – I don’t know how semantic it is though..

Nice spot!

Reply
FactoryJoe says:

21/08/2009 at 15:16

Thanks for bringing this up. That’s certainly an interesting point — and not one that hasn’t been brought up in the OpenID developer community.

That said, it would seem that preventing automated or repeated OpenID authentication requests — the same way you might prevent automated comment spam with a CAPTCHA — might prevent this kind of abuse.

For example, after 3-4 unsuccessful authentication requests from the same IP, throw a CAPTCHA. After failing the captcha, or after unsuccessfully attempting subsequent OpenID requests, replace the form with an email prompt like, “Looks like you’re having trouble signing in. Drop me an email and I’ll help you.” Or something like that (being nice in case someone, say, forgot their OpenID).

Reply
- Rich says:
  
  21/08/2009 at 16:44
  
  Thanks Chris. The web amazes me yet again, almost exactly 18 years since my first http request. Ask the right questions or make relevant observations and answers (or at least the beginnings of answers) turn up out of thin air.
  
  Reply
willnorris says:

24/08/2009 at 16:40

I would agree with Chris, that this sounds like something that could be caught and some kind of message displayed, or a CAPTCHA required. I do currently send the comment through Akismet first, and only attempt OpenID discovery if it passes the spam check. The way I’m doing that is a little less clean that I’d like, but it *should* be working. If it turns out it is not, then that’s something I’ll see about fixing. It does of course require that you have akismet installed and activated with an API key. Are there any public spam-checking APIs I can check the URL against before doing OpenID discovery? I know Google has a service for phishing sites, but I’m not sure if that would catch the URLs you’ve listed that you’re seeing.

Reply
- Rich says:
  
  24/08/2009 at 18:34
  
  Hi Will, yep, I have Akismet, so if you’d like to test anything on this server I’m happy to do so (I can SVN stuff from a branch or trunk as necessary). I’m not convinced captchas will cut the mustard, for all the normal reasons – they’re a pain for users until the day they get cracked, and then they’re no good at all.
  
  Reply
  - willnorris says:
    
    24/08/2009 at 20:51
    
    So it looks like the plugin definitely was NOT integrating with akismet properly. That has been fixed in trunk. I would not actually recommend running the trunk version of OpenID (it’s a bit unstable right now), but you can apply the changes shown in this changeset. Watch your log files for a day or so and see how that changes things.
    
    Reply
    - Rich says:
      
      25/08/2009 at 07:04
      
      Thanks Will – barring an attack of sausage fingers during entry, that should be running now. I’ll let you know how it fares.
      
      Reply
      - Rich says:
        
        26/08/2009 at 11:55
        
        Seems to have fixed it. A syslog grep from the last 24 hours shows no outbound connections to “.cn” sites.
        
        Reply