Skip to Content

Hacks

xrayspx's picture

Once again with security Spam

Why can't we pay attention to FB hacking warnings?

People do hack FB profiles, it happens every day. They often do it by inducing the target user into clicking a link that can steal their login information in any number of ways. This happens. It's a Big, Bad Internet, and in all likelihood at some point you will:

  • Have your bank information stolen
  • Have your FB, Twitter, etc. account password stolen
  • Have your machine used in a botnet, used as a spam relay, or hacked in one of countless other ways
  • This sort of thing happens every day, to all of us. There are people deeply involved in network security who accidentally click some link and their profile gets hacked.

    Occasionally, you see status updates like this:

    BEWARE ATTENTION: THE HACKERS ARE PUTTING SEXUAL VIDEOS TO YOUR NAME IN THE WALLS / PROFILES OF YOUR FRIENDS WITHOUT YOU KNOWING IT. YOU DONT SEE IT, BUT OTHER PEOPLE CAN SEE IT, AS IF THESE WERE A PUBLICATION THAT YOU MADE! ALSO, THEY'RE SENDING INBOX MSGS TO YOUR FRIENDS ASKING YOU TO CLICK A LINK. DON'T DO IT!! SO IF YOU RECEIVE SOMETHING FROM ME ABOUT A VIDEO OR A STRANGE INBOX MESSAGE, IT'S NOT ME! copy this in your wall. It is for the security of YOUR OWN IMAGE!!! And REPORT IT!!!!! ALSO IF U ARE ASKED TO VOTE ON A PICTURE. DO NOT GO & VOTE: IT'S A HACKER!! POST THIS TO YOUR WALL FOR YOUR FRIENDS

    There are so many problems with this they're hard to count. It's no different from a chain email warning of some vague threat from some somewhat familiar antagonist, like FEMA camp emails. It's so vague as to be meaningless, and just screams BE AFRAID literally as loudly as possible. ZOMGFEMAGONNATAKEAWAYMYGUNSANDLOCKUPOURFAMILIES.

    ZOMGHACKERZONTHEINTERNETSWTFBBQ.

    There are legitimate people doing hard work daily to make web browsing safer for everyone. These sorts of ridiculous "warnings" do a serious disservice to everyone in the community and lowers awareness among those people we should all be trying to reach. The more people keep re-forwarding this stuff, the more it becomes just "noise", and people start paying even less attention to their security than ever. People see this stuff as 2012 Mayan calendar doomsday predictions, as urban legends, and as plain SPAM, and tune it out, and they're not wrong to do so.

    Real threat alerts look much more like this (from the NIST CVE database for CVE-2011-2383):

    Vulnerability Summary for CVE-2011-2383
    Original release date:06/03/2011
    Last revised:09/27/2011
    Source: US-CERT/NIST

    Overview:
    Microsoft Internet Explorer 9 and earlier does not properly restrict cross-zone drag-and-drop actions, which allows user-assisted remote attackers to read cookie files via vectors involving an IFRAME element with a SRC attribute containing an http: URL that redirects to a file: URL, as demonstrated by a Facebook game, related to a "cookiejacking" issue, aka "Drag and Drop Information Disclosure Vulnerability." NOTE: this vulnerability exists because of an incomplete fix in the Internet Explorer 9 release.

    Impact:
    CVSS Severity (version 2.0):
    CVSS v2 Base Score:4.3 (MEDIUM) (AV:N/AC:M/Au:N/C:P/I:N/A:N) (legend)
    Impact Subscore: 2.9
    Exploitability Subscore: 8.6
    CVSS Version 2 Metrics:
    Access Vector: Network exploitable
    Access Complexity: Medium
    Authentication: Not required to exploit
    Impact Type:Allows unauthorized disclosure of information

    What that means is "Someone can steal your cookies, and can gain lots of information about you, including usernames, passwords, session IDs".

    You'll see that the CVE ticket is pretty dry, considering the potential impact, but they have lots of corroborating evidence, even videos to show you how easy it is to accomplish. And all they have to do is get you to click on a link.

    The point is to always be aware before clicking on anything. If something is unusual, or sent by someone you almost never hear from, don't click it. If it's misspelled, has bad grammar, ALLCAPSALLTHETIME, don't click it. If you really, really just need to see what some near-stranger who can't spell needs you to click on so badly, then you should be aware of the risk you're taking.

    For what it's worth folks; I'm unlikely to send you a link to porn, unless I'm really, really drunk. If I do, you I'll just go ahead and apologize now.

    xrayspx's picture

    Hey Hey RSA

    Today I got a customer satisfaction survey from EMC. It was specifically about RSA and how we like their products and the company in general. Cynically, I have to believe that it's not entirely a coincidence that they did this survey during BlackHat & DefCon because, well jeez maybe because half of the people receiving this aren't even in their home fucking state? There was a comment field to one of these asking "why do you feel this way". All I could muster was that they utterly blew it with me when they didn't immediately own up to what we all knew from day one: That their "Two Factor" auth SecurIDs were really now "One Factor" auth.

    It's not gone well:

    Clicky biggy:

    xrayspx's picture

    Yay Yay RSA!

    The key point I took away from RSA's communications today is that all implications are that it's likely their token seed database was taken and that token codes are predictable, and may be able to be matched to customers.

    They didn't say this, clearly, but every action they suggest to mitigate risk points to the fact. The mitigation steps they give are:

  • Consider changing PINs
  • Remove all remote access from your Auth Management servers. This was key, they said "turn off telnet, ftp, yadda yadda", but they also said "disable ssh". Meaning you should only be able to login from the console, period.
  • Watch for strange access elevations of users that would put them in a group that can see the database mapping tokens to users/PINs
  • Evaluate and audit your helpdesk procedures to make sure your helpdesk folks aren't potentially leaking information that could be valuable in an attack. So if your Helldesk people are chatting with users, they might tell that user slightly more than they need to know about our auth process or other salient fact that could be combined with other information to escalate access.
  • Institute training on social networking and make sure both your Helldesk staff and userbase are always on their toes and verifying who they're talking with.

    Those glaringly point to the possibility that the only thing protecting clients are their PIN codes. If someone has a predictable database of token codes, what do they need to attack to gain access? PINs. What are we told to protect to our last breath? The database of PINs on the Auth Management servers and stop Helldesk people blabbing about things users don't need to know. Also, stop Helldesk people resetting PINs for folks. Scenario:

    Caller: Hi this is Bob, I can't log into the VPN.

    Helldesk: Are you sure you're putting the token code in right, can I have the Serial?

    Caller: Sure, serial is 928374

    Helldesk: Have you checked CAPS lock, blah blah num lock etc, yadda yadda

    Caller: I know I'm putting the token code in right, can you reset my PIN?

    Helldesk: sure

    pwnd.

    RSA are saying that the data which was copied "cannot directly lead to a compromise, but can lower the effectiveness of current two-factor auth deployments". The only thing that can mean is that those deployments are now actually one-factor deployments.

    They have lowered the attack plane with a 4 digit PIN from 1/10,000,000,000 over a 60 second or so span until the token code changes, to a 1/10000 chance of guessing over a much more manageable timeframe, since they don't have to worry about the code rolling over.

    Even in the case that you have token lockouts after a certain number of failed attempts, this also appears to be time-sensitive. In tests, I went 4 or 5 failed attempts past the limit on a test device, then entered my PIN correctly, and it let me in. 2 minutes later, my token was locked out. So it seems it does not lock immediately on the 6th failed attempt if you have max failures set to 5. If that's actually the case, then an attacker could try their 10000 PINs in a very short period of time and perhaps squeak in before they get locked out.

  • xrayspx's picture

    Help me kill this window

    I have a bash script on my work Mac which creates an ssh tunnel to my home machine, then runs the Mac ScreenSharing.app VNC client so I can VNC home without opening VNC externally. All this works great with key based auth and stuff for the ssh session, so I just get a login prompt for the VNC session and I'm on my way.

    At the end, I try to have it clean up after itself, I've tried using waits and then killing the PIDs associated with things like the tunnel, so when Screen Sharing closes, it tears down the SSH tunnel.

    The one thing left is that it opens in a Terminal.app window, which it leaves behind at the end with a [process completed] message. I'd love to be able to kill that window, but I can't tell what PID is associated with that specific window, so I'm left with just closing it later. It's no big deal, but it's just an annoyance.

    I have it killing the PID of the bash shell it's using, but the window itself remains...

    #! /bin/bash

    for pid in `ps -A | grep localhost\:5901 | grep my-home-machine | awk '{print $1}'`
    do
    echo $pid
    kill $pid
    done
    ssh -c arcfour,blowfish-cbc -N -L 5903:localhost:5901 xrayspx@my-home-machine &

    sshpid=`jobs -p`
    echo $sshpid
    shellpid=`echo $$`
    echo $shellpid
    sleep 5

    /System/Library/CoreServices/Screen\ Sharing.app/Contents/MacOS/Screen\ Sharing /Users/xrayspx/Launchers/vnc--127.0.0.1-5903.inetloc

    #kill $sshpid
    kill $shellpid

    FIXED:
    There is a setting in Terminal.app's preference to close windows when the shell exits cleanly, takes care of that. It's the next best thing to not having the terminal window open at all.

    Thanks Matt!

    xrayspx's picture

    A new job for the little Asus

    I think I've finally found the perfect job for the little Asus EEE, since it's just too weak to show good video. It has the following tasks:

    • Linux machine I can ssh to
    • Spam Sorter and mail filter
    • Tor Exit Relay
    • CIFS fileserver for my CD collection

    Using this as the "Linux machine I can ssh to" means I'm not running a 4 core Mac Pro keeping all those disks spinning all the time anymore. This works out great, and the Pro can hibernate 95% of the time now, which should do good things for the electric bill.

    I'm doing the laziest mail filtering ever. I'm running X11VNC with a Thunderbird instance doing spam filtering on my IMAP account. I don't care how lame, that was just easiest, and it works.

    I decided a few weeks ago at the start of the Egyptian uprising that the good that can be done by providing a Tor exit relay is worth the risk of people using it for bad things, and the risk of a knock on my own door for activity originating from my IP. Now that feeling is stronger since people in more and more countries are standing up and trying to topple dictators, and are getting slaughtered in the streets for it. These governments might permit access to Twitter and FB and Google, but believe they're only doing so so they can track activity and target individual Twitter users. If you're in danger from your government, and more importantly, if your government is in danger from you, always use Tor.

    So there it is, it took six months to find a niche for this machine, but once found, it's filling the niche perfectly.

    I have a bunch of Amex gift cards which amount to about 2/3 the price of a Mac Mini. I'm on the fence about whether a Mini, even at 2/3 off, is worth it. My T60 solution seems to be running great for the time being.

    Find LDAP groups with obsolete users

    OpenLDAP has a nice "feature" that allows for group members to continue to exist, even if the user does not exist any more. Really handy! Problem is, if you, say, have a user in the "Domain Admins" group, and you delete that account, and then some normal user comes along with the same username, they will end up with unexpected elevated privileges.

    So I created a script that I run weekly that finds group members that no longer exist, and sends me a report. It also tells me which groups are empty.

    This relies on my toolbox... Find it here.

    Using some of our new tools

    Ok... Now that we have our toolbox Let's do something with it. Today we'll look at a simple solution to an everyday problem. Resetting a password.

    Part 4: Wrapping up the foundations

    Just to wrap up, and in case you are lazy like me, give you a whole file worth of subroutines. It's my toolbox and I'm giving it to you. I put this in a secure location and just call it from my other scripts. This makes the code much shorter in my other scripts, nearly auto-commenting, and avoids bugs because if it works in one, it will work in others.

    NOTE: This uses the foundations in parts 1, 2 and 3. You can find them here: Part 1 Part 2 Part3

    Part 3: The SubRoutines

    Now for the tools. There's a lot here, but in further articles you will see how this can be useful. I'll go through each tool with what it does, how to call it, and then the code itself.

    NOTE: This uses the foundations in parts 1 and 2. You can find them here: Part 1 Part 2

    Syndicate content