E-mail address spoofing with RLO
E-mail address spoofing with RLO - http://wouter.coekaerts.be/2011/email-rlo Introduction = When we reply to an e-mail, the address we see in the To-field serves a purpose beyond getting our answer back to original sender. We attach a meaning to these addresses. If we see john.sm...@example.com, we expect that we're really sending a mail to someone at the Example company. We may have learned not to trust the "From" address: that's about as unreliable as the return address on the back of an envelope. But we should be careful with what we think we see in To-field too. Problem === The problem comes from the unicode "right-to-left override" (RLO, U+202E) character. It's an invisible character, that forces the text after it to be treated as right-to-left. For example "abc[RLO]def" is displayed as "abcfed". It's well known that these kind of characters have security implications[1][2], it has led to other problems[3] before, and this is a new one in that category: It can be abused to display an E-mail address backwards, so that it appear to be on a different domain than it actually is. Details === An RLO is usually not accepted in an address, but it is accepted in the display name. The display name and the address are often shown together, allowing the RLO in the display name to affect how the address is shown. For example, "Firstname Lastname [RLO] " is displayed as "Firstname Lastname ". This can not be used to spoof arbitrary addresses because the attacker's reversed real domain is still in it. But it can be used to spoof any domain. And a well chosen domain name reversed can look like a convincing foreign real name in the first part of the address. This problem is worse than spoofing of the From-addresses, because an attacker can have a whole conversation without an indication to the victim that he's not who (from the domain) he pretends to be. Affected software = This affects most e-mail clients. These are the ones I tested, and whose vendors have been made aware of this in 2009. * Gmail: still vulnerable * Hotmail: Fixed in February 2010 [4] * Outlook 2007 (and later?): no fix announced, presumably still vulnerable * Outlook Web Access: no fix announced, presumably still vulnerable * Evolution: still vulnerable (Bug 601172 [5]) * KMail: Fixed since December 2009, KDE 4.2.x (never released), 4.3.5 and 4.4.0 * And more... 1: http://unicode.org/reports/tr9/#Explicit_Directional_Overrides 2: http://unicode.org/reports/tr36/#Bidirectional_Text_Spoofing 3: http://www.mozilla.org/security/announce/2009/mfsa2009-62.html 4: http://technet.microsoft.com/en-us/security/cc308575.aspx#0210 5: https://bugzilla.gnome.org/show_bug.cgi?id=601172
Quassel IRC: connection hijacking
Quassel IRC (http://quassel-irc.org/) is "a modern, cross-platform,
distributed IRC client".
A vulnerability in the CTCP handling allows an attacker to trick Quassel IRC
into sending arbitrary commands to the IRC server.
This can be used by an attacker for example to gain operator privileges on a
channel.
Details
===
A CTCP ping where the value contains a CTCP quoted newline ('\020' + 'n') will
let the Quassel core reply with a message containing an unquoted newline
('\n'). The IRC server interprets this as a command separator.
Solution
This has been fixed in version 0.3.0.2, released Oct 27 2008.
Online version: http://wouter.coekaerts.be/site/security/quassel-ctcp
Re: Quassel IRC: connection hijacking
On Wednesday 29 October 2008, Wouter Coekaerts wrote: > This has been fixed in version 0.3.0.2, released Oct 27 2008. Oops, correction: It is fixed in version 0.3.0.3. Wouter.
Re: Vulnerability in multiple "now playing" scripts for various IRC clients
On Wednesday 15 August 2007 18:27, [EMAIL PROTECTED] wrote:
> I may be rusty with knowledge about mirc (say almost 10 years out of
> date)...but, in what situation would the pipe ('|') ever be processed from
> a variable, even if it was read from a mp3 ID3?
It gets processed before it ends up in an mirc variable. The plugin to link
your media player to mirc sends something like:
"/set %songname "
And it's when executing that command that it goes wrong already, not in the
command that's using the variable. That's why it's easier to exploit: the
user only needs to play the song, he doesn't need to do anything in mirc.
In my old notes, I found that at least these plugins have this problem:
* Nullsoft mIRC Control Plug-in v0.6 (gen_mirc.dll) and other versions
* mIRC Control EX Plug-In V 2.00 (gen_ircex.dll) and other versions
* mIRCPlug v1.0,1.2 (gen_mircplug.dll)
Those are all old plugins. I don't know if they're still used a lot, or what
the currently popular plugins for this are, and if they're vulnerable or not.
On Wednesday 15 August 2007 19:34, Michael Tharp wrote:
> This is probably a bigger concern for *nix scripts, especially of the
> homebrew variety
I haven't found any public script for a *nix client that allows arbitrary
command execution like this (they only allow sending IRC commands to the
server).
Wouter.
Multiple vulnerabilities in ircu
Ircu is the open source IRC server used on Undernet and other IRC networks. I (Wouter Coekaerts) discovered multiple vulnerabilities in various versions some time ago, which have all been fixed for some time (since 2.10.12.06) but not yet made public. Now that servers have had enough time to upgrade, I feel it's time to do so. None of these bugs can be abused for arbitrary code execution. Two are about crashing a server, one about exposing IP addresses, and the effect of the others stay within IRC: they allow clients to get more privileges on the IRC network then they are supposed to have. Overview Affecting only 2.10.12.01: 1. Crashing servers with an innocent-looking oper-only command 2. Easy protocol violations (wallop) flooding 3. Crash with oplevels Affecting 2.10.12.02 up to and including 2.10.12.04: 4. DoS on server by creating many zannels Affecting 2.10.12.01 up to and including 2.10.12.04: 5. Gaining ops on channels that get empty on one side of a netsplit 6. Making clients think someone is on a (+D) channel, who isn't Affecting 2.10.12.03 and 2.10.12.04: 7. Netriding with ops, using zannels Affecting very old up to and including 2.10.12.05: 8. Timestamps in bounces ignored Affecting 2.10.12.01 up to and including 2.10.12.05: 9. Any op setting or changing Apass when server restarts Affecting very old up to and including 2.10.12.05: 10. Desync: unkick/deopable ops Affecting very old up to and including 2.10.12.05: 11. Getting hidden IP's of +x users Background info === To fully understand these bug descriptions, you'll need some knowledge of IRC and ircu-specific features like how timestamps (TS) work. Some of these vulnerabilities only affect servers with oplevels or zannels enabled, which was the default (but not anymore). Oplevels (A/Upass) is a feature that allows the creator of a new channel to set passwords on it that, when used to join, automatically give ops. Zannels is a feature introduced in 2.10.12.02 that keeps empty channels alive for a while instead of destroying them immediately, to avoid A/U passwords being set on a channel that was only empty for a short time. Zannels was enabled on Undernet on some servers for a short time and then disabled because of the trouble it caused. Oplevels never were enabled. Details === 1. Crashing servers with an innocent-looking oper-only command -- Servers crash when an oper tries to do a remote names -D (/names #foo -D some.server). This is an oper-only command, but still is a security problem because a user could trick an oper into doing it (because the command is supposed to just show info to the oper). 2. Easy protocol violations triggering -- /join #aa...aa and then #aa..aaa (one character longer) will cause a protocol violation. Too long channel names aren't cut off consistently (or at the wrong place). This could be abused to flood wallops. 3. Crash with oplevels -- When a server receives a "J 0:#channel" (a server message indicating a join with apass), on a channel of which it thinks doesn't have an apass set, it crashes. This can be done for example by making such a join and a mode -A cross. 4. DoS on server by creating many zannels - The fact that channels don't die immediately (but become zannels) can be abused to create a lot of channels, probably enough to take any IRC network down with a not unusually big amount of clients. A quick experiment I did shows one client (constantly sending JOIN 0,#a,#b,#c,... different channels all the time, 20 channels per command) can keep between 600 and 1200 channels alive. Besides using quite some memory for 1 client, this also sends bursts of 600 DE (destroy) messages across the network every few minutes. Now if 1000 drones would be doing this, that would mean more than a million channels alive, and bursts of 600.000 DE messages every few minutes. I guess this would probably take down a lot of servers. 5. Gaining ops on channels that get empty on one side of a netsplit --- A bug in how channel TS is handled in .12 makes it possible to gain ops on a channel if you're the only one in it, without lowering the TS. This could be abused during a split to takeover a channel. This works with zannels disabled and enabled. Cause: A join (from a server) with an older TS lowers the TS on the channel, but does not remove ops. Exploit: 2 servers, each one client: s1 and s2. c1 on s1, c2 on s2 c1 the only client, not opped, on #chan. * c2 joins #chan, and parts immediately * at the same time (before the join and part arrive on s1), c1 parts and joins => when the join and part of c2 arrive the TS is set back to the original one, but c1 keeps his ops. 6. Making
Vulnerability in multiple "now playing" scripts for various IRC clients
In October 2006 I discovered many "now playing" scripts for various IRC clients allow an attacker to send commands to the IRC server on behalf of the user. Details === Many scripts for various IRC clients, that report the name of the currently playing song in a media player on IRC share the same security bug. They don't sanitize the name of the song before sending it to the IRC server. When a user plays a song with a newline (LF or CR, which are both message separators in IRC) in the name of a song, and uses such a script, the text following the newline will be interpreted by the IRC server as another command. Exploitation requires the attacker to trick a user into playing such a specially crafted song, and to then use his script while the song is playing. That makes it hard, but not impossible to exploit in practice. It results in the ability to execute IRC commands in the client of the victim. This could be abused, for example, to gain operator privileges on chat channels. Because it requires so much user interaction to exploit, and the results are limited to sending commands to IRC, I'd call this a minor problem. Affected What makes this bug noteworthy in my opinion is that it is present in *all* scripts with this feature which were tested. They can all be exploited by the same malicious mp3. This includes: * irssi: from http://irssi.org/scripts/: ixmmsa.pl 0.3, l33tmusic.pl 2.00, mpg123.pl 0.01, ogg123.pl 0.01, xmms.pl 2.0, xmms2.pl 1.1.3, xmmsinfo.pl 1.1.1.1 * XChat: many from http://xchat.org: xmms-thing 1.0, XMMS Remote Control Script 1.07, Disrok 1.0, a2x 0.0.1, Another xmms-info script 1.0, XChat-XMMS 0.8.1, and more... * weechat: from http://weechat.flashtux.org/: now-playing.rb, xmms.pl 1.1 * BitchX: from http://scripts.bitchx.org/: xmms.bx 1.0 * Konversation: included media script * Many scripts for mIRC, and probably other clients too Related bug === Similarly, but worse, some scripts/plugins made for mirc don't remove | characters, which is a command separator in mirc. This allows arbitrary command execution (on the client, not just to the server), without needing more user interaction then just starting to play the file. For example http://www.winamp.com/plugins/details.php?id=187 has this problem. (That bug was reported years ago already though.) Irssi = I now put off my reporter hat, and put on my Irssi developer hat :) This has been fixed in all scripts on the irssi site, and irssi 0.8.11 prevents scripts for making this bug. I'm not aware of other clients or scripts having released a fixed version. Online version: http://wouter.coekaerts.be/site/security/nowplaying
