I’ve seen many different ways that something like that could “work” — as in, a number of ways a bad person could exploit the Internets to take advantage of your info…
“Man in the middle” have to do with DNS or even bookmarks that you’ve saved to the wrong URL — or someone who is grabbing your logins, then redirecting you to an error page (every time), so you can legitimately log in again (that would explain the double-login). If that’s the case, the double-login is a symptom / sign of the compromise, not necessarily a plugin flaw.
Another thing to be careful of — if you’re hosting any other type of live chat or PHP-based solution, PHP can be exploited if your PHP ownership on the server is the same as the Apache user. In other words, common ways of changing your code might include someone using an “include” to execute their nefarious code from their library on another site. WordPress has always appeared solid in this regard, but I give the files ownership to a user that can’t be modified by Apache (so you have to be SSH-ed in to make changes). Not all software is as include-preventative or sturdy. This is a real-world example I’ve seen a number of times with non-WordPress addons (like a Live-chat that’s hosted on the same server). WordPress is pretty solid, but it’s only as solid as the least secure thing you’re running on the same box.
There are all sorts of other things that can go wrong for you, depending on how locked down you are. SQL injection where someone can change the parameters of the redirect… or other symptoms you mentioned before.
IMHO, it’s entirely possible that your problems here had little or nothing to do with the exploitability (is that even a word) of this plugin — but it’s tough to deny the coincidental timing.
My unsolicited advice to you — find someone you trust who has a tendency to be a security nut — or if you’re savvy to do so yourself… check your logs and code to see any trace of what someone might have done. Lock down your iptables setup, lock down the log permissions (if others have SSH access to your server). Block external access to any services like MySQL that likely don’t need to be accessed externally. It’ll be a lot of “security nut 101” type of stuff, but that will ultimately help you sleep better at night and reduce the chances of anyone getting in. Lastly, run SSH on a non-standard port and turn off password authentication. I get thousands of people weekly trying to port scan my servers and brute-force. It’s possible that someone got in by *GUESSING* a password. I run hostkey-only with a password-protected hostkey just because I’m a nut like that.
The above statements assume you haven’t locked down the server to the “nutty extent” (don’t feel bad, many don’t)… and it also assumes you’re running some Linux variant (isn’t everyone?) ??
