Malware emails with fake cellphone invoice
"Thank you for ordering from Cellphone Inc" is what the email says ... what it doesn't say is "have a nice day cleaning your infected PC". Reader Scott had just taken his mobile phone to a store for repair, but being the savvy security specialist, he was still suspicious when he got the following email shortly thereafter
Thank you for ordering from Cell Phone Inc.
This message is to inform you that your order has been received
and is currently being processed.
Your order reference is Cell Phone Inc. You will need this in all correspondence.
This receipt is NOT proof of purchase. We will send a printed invoice by mail to your billing address.
You have chosen to pay by credit card. Your card will be charged for the amount
of 629.99 USD and "Cell Phone Inc." will appear next to the charge on your statement.
Your purchase information appears below in the file.
Cell Phone Inc.
Turns out of course that this email had nothing to do with Scott's phone, it is just the latest malware scam. The email comes with a PDF attachment that - at current count - tries to exploit collab.getIcon, media.newPlayer, collab.collectEmailInfo and util.printf -- all rather "old" Adobe Acrobat vulnerabilities, but apparently still "good enough" for the bad guys to warrant a new spam run.
The PDF's guts are obfuscated JavaScript, as usual, and currently showing up with a lousy 2/43 on the Virustotal radar.
Keep your users from clicking ... and keep up with those pesky almost-feels-like-weekly Adobe updates!
Requesting deletion of "free" email and chat accounts
Past August, we ran a story about the dangers of abandoned email and chat accounts. Since then, we've been getting a steady trickle of requests from readers for advice on how to get a provider to delete an unused profile or address completely.
Reading the fine print of legalese is never fun, and therefore it's no surprise that many users apparently read the privacy policy of a "free" web site for the first time when they want to cancel the account. More often than not, they then find out that ... there is simply no way to back out. Or rather, that the legalese gives the provider ample rights to delete an account at any time, without warning, but that there is no way for an user to request such an action.
Today's question on the topic came from reader Mike, who tries to have his old and unused ICQ.com account properly closed and deleted. Not so easy, it turns out: The "support forum" on ICQ is full of users who post "please close my account" requests, but don't seem to be getting an answer or action. If you know an approach that works for ICQ, please comment below, or let us know via our contact page.
Making sense of RSA ACE server audit logs
Following up on the earlier post by fellow ISC handler Rob on the RSA Breach, here's a couple practical things you can look for in the audit log of your RSA ACE (SecurID) server. In line with Rob's scenarios, an attacker who is in possession of the "seed" values of your SecurID tokens still has to guess the userid and PIN to get a successful login. With ample foresight :), the authors of the ACE/RSA software seem to have expected such a scenario, and have implemented an audit log that fits to the case:
AUTH_FAILED_BAD_PIN_GOOD_TOKENCODE will show up in the audit log whenever someone has a good token (or the seed values) and either fumbles or tries to guess the associated PIN. You'll get quite a few of these in normal use, simply because authorized users sometimes forget or mistype their PIN. If you see a lot of these against one single userid, chances are it will lock after "n" failed attempts and no harm is done. But if you see 1-2 of these per user and enumerating several of your users .. then you should take a closer look for sure.
AUTH_PRINCIPAL_RESOLUTION / AUTH_ALIASES_NOT_FOUND will appear in the log if the userid that tries to log in does not exist. Again, you can expect a couple of these per day in normal operation, it is just a fact of life that users can't type their own names ... But if you get a lot of these, and especially if the username format is completely different than the userids in use, someone might be trying to guess your users from a phonebook or LinkedIn accounts. Take a closer look!
Irrespective of the recent RSA breach though, there is one audit log entry that you should keep a close eye on:
NEW_STATIC_PCODE_AUTH_SUCCESS shows up in the log whenever someone logs in with a static passcode. This means that the user has lost his token, or never had one, and that someone with ACE Admin privileges has assigned a static password instead. Yes, this is possible, and it basically turns two factor authentication into two-password authentication, while still everyone can claim to the auditors that "login goes via the SecurID server". There are legitimate emergencies for this kind of login, but it certainly is a dangerous option to have - if someone can smooth-talk your Helpdesk, they can get in, without needing a token.
Considering the latter, you probably shouldn't worry all that much about what was or wasn't stolen in the recent RSA heist. But if you're not doing so yet, you certainly should check your ACE server audit log.
Comments