Javascript spam

You may have noticed some unusual amounts of spam over the past few days, which has had an impact on a number of channels.  This spam is the result of some malicious javascript being distributed on a number of webpages which causes visitors to these pages to make a connection to freenode and send spam.  While we are doing what we can to mitigate the spam, we would ask that you take a careful look at any unusual sites or URLs you might visit in the near future to be sure you are not being tricked into visiting such a site.

If you have been banned from the network after clicking on one of these links, please email [email protected] with your internet-routeable IP address. Visit http://myip.dk/ and include both the IP address and hostname provided on this site.  It’s also helpful if you let us know what nick you were using at the time.  We will address these requests as quickly as possible, but please be patient.

It is of course never a good idea to visit a link that’s not from a trusted source.  If you must do so, look into using a browser with limited or no scripting support (wget from the command line is a great solution here on linux, as is links) or using something like no-script for firefox.

If you run a channel on freenode, you might want to consider setting +R to prevent unregistered users from sending to the channel as the spambots described here will not be registered.  If you do so please consider being proactive about contacting unregistered users joining your channel to ensure they get the help they need, and feel free to send them to #freenode so network staff can help them register.

For users, now is an excellent time to register your nickname and setup your client to auto-identify.  You can find information about registering here.  Configuring your client to auto-identify varies depending on the client, but one easy way is setting up your client to send the nickserv password as your server password. Most clients have an option for this.

It is also worth noting we will be moving to a new ircd in just 13 more days, as described here.  This new ircd provides a number of exciting new capabilities including improved capability to deal with spam of all kinds, including this most recent type which is entirely mitigated by improvements in seven.

9 thoughts on “Javascript spam

  1. What I’m wondering is how JS is managing to do this. Is the link to a third-party site that launches a CSRF attack against a web-based IRC interface, or is it a script-injection attack against said web client?

  2. Re: “It is of course never a good idea to visit a link that’s not from a trusted source.”

    An occasional inconvenience does not warrant abandoning the web as an information dissemination system and treating it like executable software. Simply have your server drop connections that open up with HTTP commands (or any non IRC commands right at the start.) rather than preach xenophobic use of the web.. unless you’re honestly proposing we revert to paper for the open dissemination of ideas.

    I’m particularly displeased such a suggestion would come from freenode of all places.

  3. Of course, they did mention that this bug doesn’t affect ircd-seven at the end of the post. Fixing this oversight in hyperion-ircd would be ridiculous at this point, so we only have to bear with this for 8 additional days. Doesn’t sound much of a stretch to me.

  4. The first paragraph iterates, “While we are doing what we can to mitigate the spam…” ;-)

    You have to admit though, there is so much junk on the web these days, the stuff slows the system to a crying halt. So I use noscript for my browsers, SeaMonkey being faster then Firebloat (Firefox). I do use Dillo or even ELinks more frequently, resorting to SeaMonkey/Firebloat as a last resort.

    I think a touch of xenophobia is called for. ;-)

  5. Agree with kermit. How about “Don’t accept connections from clients who speak gibberish” instead?

  6. kermit, Jonas: Newer ircds do block HTTP POST connections (or gibberish if you guys wish) and as the attacks started less than two weeks away from our migrating to a new ircd, we discussed among ourselves and decided that it was more prudent to deal with the issues for the 12 days until migration, rather than needing to spend the time on patching a ‘dead ircd’ and take the entire network down for the sake of a few days worth of blocking it.

  7. Pingback: Plaats hier software gerelateerd nieuws! - Page 17

  8. Pingback: InfoSec Daily » Episode 60 – The Pain Train

Comments are closed.