IRC-Junkie.org – IRC News

All about Internet Relay Chat

Mibbit has been compromised

On August 14 a cracker group claiming to be “hackers” named HTP broke into Mibbit, the popular web chat client for IRC. According to their temporarily “rescue” blog the break-in only affected their IRC network, their primary blog and their Wiki. NickServ passwords in clear text were released later the same day by the HTP, as well as personal information regarding several staff members. Both their IRC O-line passwords as well as their NickServ passwords, home addresses and phone numbers were published to the public via a range of file hosting services, and Pastebin.

Something perhaps even more concerning is that the group has revealed not only channel logs, but logs of private messages. It appears like Mibbit has been logging what people have said in PM to each other over their network. According to official statements, this was only a test. Some people have heard that Mibbit has been logging all messages going through their systems. Mibbit has never logged anything, unless a user wants to enable logging. The leaked message logs were captured by a staff member, and not by Mibbit’s system, according to official statements. While this is fully legal, the level of ethicality has been questioned.

The web IRC client that can be used to connect to almost any other network, which is what made them famous, has not been affected. It is operating normally.

All NickServ passwords were stored in plain text, and that raised a concern for those who are interested and engaged in enforcing security. According to staff member pottsi password hashing was not done because that would “means sendpass and getpass would not work”. Another staff member, Joshua, claimed that password hashing was not done because it was too much work to convert all passwords. This has however proven to be incorrect, at least if they used a plain copy of Anope. In Anope’s module database, there is a module called enc_switchover. It’s fairly easy to migrate from one encryption method, or none, to another, using that module. In addition to that, the Anope module ns_resetpass will allow users to reset their passwords despite encryption taking place.

Many people, especially IRC administrators, are now questioning Mibbit’s reliability and some are considering to block access from the web service, just like one of the largest networks, freenode, did a couple of years ago. This is mainly due to the question whether they log messages there too, which would go against many networks’ policies.

The Mibbit team is now working very hard to bring all services back up again. At the time of writing, ChanServ and NickServ on their network is down and staff members are forced to use /samode if they need to get op. They advice everyone who had a NickServ account registered in April or earlier, this year, to change password.

  Copyright secured by Digiprove

KVIrc 3.x and 4.x Remote Command Execution Vulnerability

All current versions of the KVIrc IRC client contain a remotely exploitable command execution vulnerability, including builds of KVIrc 4 from subversion up to revision 4692 as well as the older 3.x versions.

The bug, triggered by inserting carriage returns (r) into DCC GET commands, can be used to execute every command the IRCd understands in the context of the user running the vulnerable client instance.

To check if your version is exploitable you can either take a look at the “About KVIrc” tab under “Help” and check the revision or execute the following command on IRC:

/echo $version

To make matters worse, whole channels can be exploited at once if they don’t have a mode set that disallows CTCPing them.

A quick workaround is to execute the following command, effectively preventing those “failed” DCC handshakes to be notified and disabling the bug:

/option boolNotifyFailedDccHandshakes 0

To see if you’ve already been exploited you can take a look in your server window and search for lines that look similar to these:

[01:27:46] Processing DCC GET PRIVMSG #kvirc :I’m owned
request from ATTACKER [ATTACKER@HOSTNAME] (DCC GETrPRIVMSG40#kvirc40:I’m40ownedr)
[01:27:46] Unable to process the above request: Unknown DCC type ‘GET PRIVMSG #KVIRC :I’M OWNED ‘, Ignoring and notifying failure

Updated builds of KVIrc are available on their homepage – some distributions also already have updated builds in their repository. If you can’t update because your distribution is not among the one with updated builds, the workaround helps to not fall prey to any possible attackers.

Original report on KVIrc bugtracker
Advisory on Secunia.com

  Copyright secured by Digiprove

Some UnrealIRCd 3.2.8.1 downloads trojaned [Update 3]

Syzop of the UnrealIRCd project just posted an announcement on their mailinglist and forums that some versions of their IRCd have been compromised and had a backdoor added which went unnoticed for quite a while.

The first signs of the compromise have been traced back to November 2009 and Syzop writes that “Any Unreal3.2.8.1.tar.gz downloaded BEFORE November 10 2009 should be safe, but you should really double-check”.

Only the 3.2.8.1 source downloads (.tar.gz) are affected from this hack. Windows users, copies checked out from their CVS as well as users of older versions are safe and don’t need to check – everyone else should ensure they’re running a clean version of UnrealIRCd since the backdoor allows an attacker to issue and execute commands as the user the IRCd is running as, which essentially means your shell could easily compromised despite all other security measures.

Checking if your IRCd is one of those trojanized copies can easily be done either checking with md5sum or grep’ing the source for the backdoored code:

Run ‘md5sum Unreal3.2.8.1.tar.gz’ on it and compare the resulting sum to the checksums below:

Backdoored version (BAD) is: 752e46f2d873c1679fa99de3f52a274d
Official version (GOOD) is: 7b741e94e867c0a7370553fd01506c66

or use the command ‘grep DEBUG3_DOLOG_SYSTEM include/struct.h’ from your Unreal3.2 directory – if this outputs 2 lines you’re running the trojanized version and need to get yourself a fresh and clean copy of the IRCd and recompile it since the compromised section is in the IRCds core and “it is not possible to ‘clean’ UnrealIRCd without a restart or through a module”.

Syzop writes that they have take precautions so such a compromise can never happen again and if it does that it’ll be noticed more quickly. They’re also planning to reimplement PGP/GPG signing of the releases which “in practice (very) few people use” but “still [will] be useful for those people who do”.

Closing his announcement he writes that he’d like to “apologize about this security breach. We simply did not notice, but should have. We did not check the files on all mirrors regularly, but should have. We did not sign releases through PGP/GPG, but should have done so. Hope you’ll all continue to support UnrealIRCd”.

The full announcement can be read here and the advisory can be found here.

[Update]: Servers running the trojanized versions of UnrealIRCd should be updated as soon as possible since HD Moore, the creator of the Metasploit exploitation framework, already released a module for it – but even without that the security hole is really simple to exploit.

Also, here is a .sh script that might help you in the upgrade process – at least one user on the UnrealIRCd forums claimed it worked for him (although no kind of guarantee is given neither by the author nor by me).

[Update 2]: Syzop just posted a follow-up in which he writes that their releases are “from now on signed with GnuPG (PGP) again”.

[Update 3]: In an email to the UnrealIRCd mailinglist, Syzop elaborates on the GPG/PGP signing and says that there will be instructions on how to verify the key when you download the future releases. He also goes into some detail which precautions the team has taken that such an incident “will never ever happen again”. He rightfully criticizes certain news-outlets that claimed it was the fault of the Open Source model and even Linux (*cough*ZDNet*cough*) – some websites even confused the IRCd with EPIC softwares first-person shooter Unreal Tournament.

  Copyright secured by Digiprove

Researchers develop "HoneyBot", Social Engineer IRC Users automatically

Researchers of the TU Wien (Vienna University of Technology, Austria) achieved a stunning – and at the same time scary – 76,1% click rate on possibly malicious links in conversations that took place on IRC using an automated social-engineering software dubbed “HoneyBot”.

Their new approach to automated social engineering (“ASE”) does not rely on artificial conversations from an AI but instead used the bot to relay messages between humans, effectively avoiding detection according to what is commonly referred to as “Turing Test” in which humans assess if they can tell apart that they are talking to a human or a computer program of sorts. Previous generations of such bots used an AI called “Artificial Intelligence Markup” to engage in conversations with a much lower success rate: Users where able to spot 80% of the bots after exchanging only 3 messages with them.

HoneyBot acts as a “Man-in-the-middle” and relays messages between two unsuspecting users which seem to have perfectly normal conversation going on:

bot → Alice: Hi!
Alice → bot: hello
bot → Carl: hello
Carl → bot: hi there, how are you?
bot → Alice: hi there, how are you?
Alice → bot:

But that’s not all – the bot is capable of influencing the ongoing conversation by “dropping, inserting, or modifying messages” and the researchers assert that “if links (or questions) are inserted into such a conversation, they will seem to originate from a human user” and therefore the click-probability will be “higher than in artificial conversation approaches”.

The really sophisticated bot is able to determine the gender of the persons it is talking to and makes on-the-fly adjustments to all relayed messages so “Hello, i’m a guy” becomes “Hello, i’m a lady” when its gender-detection algorithm determined that the conversational partner likely is male. Insertion of links also has some level of sophistication – instead of just dumping a link into the conversation and hoping for a click, the bot has 3 options for doing so:

  • Insert a random link: Along with a generic message a link is sent to the other user if they have been engaged in a conversation for a minimum number of messages
  • Keywords: Reply with links to keywords such as “ASL?”
  • Replacement link: Questions already containing links to sites such as YouTube are replaced with own links and therefore look most natural since the question was composed by a human. Also, the bot can inject probing questions to steer the conversation into a certain direction.

Trying to be as stealthy and sneaky as possible, the bot never contacts users with “administrative privileges” but replys to private messages by such, although it will never inserts links or questions into those conversations. Additionally, a random delay is used when “typing” messages to make detection even harder.

Aware that what they have created is a whole can of worms when used unethically, the researchers made sure that personally identifiable data such as eMail and IM addresses are never relayed and links sent in conversations are filtered if they’re not going to be replaced by HoneyBot.

The channels monitored by the bot where 2 dating and one generic chat channel of  which neither the channels nor the network have been named in the research paper.

HoneyBot Monitoring Statistics

HoneyBot Monitoring Statistics

When talking about the ethics, the researchers conclude that they’re well within the guidelines set forth by the IRB (Institutional Review Board) based on similar researches and also got a nod from the legal department of the university. They chose to not inform users before the experiment since this would most likely have influenced the results as “users that are aware of participating in a study are likely to be more cautious than usual” and say that they “carried out the study only with users that responded to our messages and thereby accepted talking to the bot (i.e., stranger)” and emphasize that there were no “ongoing conversations intruded” by them. Also they note that all data collected “although largely anonymous” has been deleted after the “evaluation phase”.

With 3 seperate bots – a “periodic spam” bot, a private-message spam bot and a keyword spam bot – they evaluated the likelyhood of users clicking on links, the results can be seen in the below table:

HoneyBot Monitoring Statistics - Clicked Links

HoneyBot Monitoring Statistics - Clicked Links

Altogether, only 1.7% of the online users could be enticed into clicking a link by those 3 “classic” bot types and the bot only got to post 8 links on the Chat channel before it was banned by a channel op.

Enter HoneyBot:

The longest conversation HoneyBot had took a staggering 2 and a half hours with 325 messages transmitted and it achieved a median chat time of “longer than 30 minutes”.

Out of the 3 possible URLs the bot has sent – broken down in IP, TinyURL and a MySpace link – TinyURL links where the most clicked about which the researchers rightfully say is counter-intuitive since “TinyURLs can hide arbitrary URLs whereas a MySpace link always leads to a profile”.

HoneyBot - Clicked Links Breakdown

HoneyBot - Clicked Links Breakdown

Furthermore, the MySpace links the bot sent out had to be reassembled by the user because a space character was inserted into the URL and the researchers said they’re “surprised that this reassembly has happened at all”.

It should not go unmentioned that the same type of research was conducted on Facebook where they created one male and one female profile and tried to befriend users of the opposite sex. The new friends, if successful in bootstrapping a conversation, then tried to make them click on the same links as the IRC bot. And even though 4 out of 10 people clicked them, the researchers believe that the attack could have been way more successful if they went as far as cloning profiles, befriend users from those and relay messages from cloned to authentic profiles.

As can be seen from the Facebook example, this kind of attack is not limited to IRC exclusively but can be adopted to a whole host of so-called Social-networking sites and systems.

Mitigation of these social engineering threats is not easy and there is no fast and hard measure that can prevent all of them, however raising awareness is one way to make users more alert to it and is what the researchers tried to achieve: “We hope that this paper will contribute to this process.”

In Soviet Russia Vienna bots social engineer you!

  Copyright secured by Digiprove

UnrealIRCd team releases patch against Firefox XPS Attack

In a posting on the UnrealIRCd project website, coder Syzop announced a module that can help mitigate and completely stop the so-called “Firefox XPS Attack” (NSFW link).

The attack, which exploits the fact that malicious JavaScript can send arbitrary data to a wide range of ports, gained publicity when it was used against the freenode network over a period of a few weeks.

Even though the Mozilla project has a blocklist of ports that are specifically not allowed to be communicated to, the port commonly used by IRC networks (6667) was not on those lists.

The attack – which ironically doesn’t affect Safari, Internet Explorer or Firefox with the NoScript extension – only works if the targeted IRC server does not use anti-spoofing measures before proceeding to the login phase.

UnrealIRCd generally is immune to the threat when it was compiled with the NOSPOOF feature which is enabled by default for the Windows builds but an option that defaults to “no” on Linux (“Do you want to enable the server anti-spoof protection?” – the first question on ./Config).

With the module you can now instantly K/G/Z:Line such connections and therefore prevent them from filling up connection slots which might cause a DoS situation before they eventually time out. For maximum efficiency it is recommended you use both the module and the NOSPOOF option, however one works fine without the other.

To test whether your IRCd is vulnerable or the implemented measures against the attack are effective you can find the code that has been used against freenode here.

Thanks for the tip go to katsklaw!