The Daily WTF has a good story that may sound a little too familiar to some:

How the aptly-named Super Hacker had managed to shut down the system remotely and provide a fix so quickly intrigued Kiefer. After poking around the network, he finally found the Python file that contained the Super Hacker’s fix:
#!usr/bin/python
# Paying someone $10 to pull a power cord for $3500
print “(C) [Name Removed] 2008.”

The moral of the story: when all else fails, use social engineering.

Anyone who has ever done serious security research reached the line that separates good from evil. If you are working with phishing emails you get links to kiddie porn. If you research security holes you deal with exploits. If you are researching botnets you are up to your neck in sensitive information that was obtained illegally.

I’m sometimes asked if we ever get ‘tempted’ to cross over. The answer is simple: we may think like criminals and sometimes emulate their work, but it never ever enters our mind to do something malicious. Finding an SQL injections that gives you full access to the database is fun; using this information to steal money or order items for free is light years away from what we do.

But not everyone understands that, and that’s scary. A member of the THC got pulled over at Heathrow airport by the UK government. The story has a happy ending, but it must have been scary, not to mention frustrating. My good friend Zvi Gutterman found weaknesses in the Windows and Linux PRNG. Breaking the PRNG has consequences - while top-secret crypto systems will not use the standard Windows or Linux random number generators, who knows if there is a simple Linux based basic communication device used in one of the governments? An applicable weakness in the PRNG may have a serious impact and they might decide that shutting up Zvi is easier than replacing all their units.

If you think the previous paragraph is a paranoid conspiracy theory, lets talk about kiddie porn links. These pop up whenever we deal with botnets, phishing and malware. The police is trying to demonstrate zero tolerance for kiddie porn, usually by arresting anyone who has visited such an illegal web site. How will you explain to your family, when they see you on the 8 o’clock news arrested for kiddie porn charges, that you are not a dangerous paedophile but you had no idea the link you clicked was to a kiddie porn site?

There will be more incidents like the THC one. We can all tell the difference between a proof of concept device to show how vulnerable GSM encryption is and an illegal wiretapping device. But the law officials can’t, and often don’t seem to care about the difference. Some of the time it’s not even law officials: Fyodor had his site shut down to prevent spreading his nmap ‘hacking tool’. Dmitry Sklyarov was arrested in Las Vegas for breaking the PDF encryption. In the Fyodor incident the decision was made by godaddy. In the Dmitry Skylarov case it was Adobe who got the court order.

I wouldn’t want to see security research being a licensed profession (like a private detective license or a license to carry a firearm) - I’ve seen brilliant teenagers who think out of the box and find vulnerabilities no one else can, but are not old enough to drive a car. So what else can we do to make sure we hold a ‘get out of jail’ card?

This Hebrew post in linmagazine describes what first sounds like a typical Vishing attack. The author’s mother receives a phone call telling her there’s been a terrible accident and she needs to call the hospital for the details. They give her the ER’s number but tell her to use only her land line. The number is *7200526671955. Strange, but not unusual in Israel where dialing *pizza connects you to Dominos and *mortgage to your local sub prime pusher.
So she calls and calls but there’s no answer, and she rings her son to tell him to try and call.

He rings, and gets a voicemail. Getting suspicious he dial his phone company’s information directory and finds they were conned: *720 is the code for call forwarding, and 052-667-1955 is a local cell number. It’s a clever scheme, actually. All the for-pay phone numbers (sex hotlines, etc) are opt-in which means they are blocked by default (to prevent scams like this, among other things).
However, calls to cellular phones are more expensive (in Israel the caller pays the charge and not the receiver) and so it is possible to cut a deal with the cellular company for revenue sharing and open your own ‘recipe tips’ hotline which should bring in many incoming cellular calls and make everybody (especially the mobile operator) happy. If instead of recipes you make people call because their friend’s phone lines are automatically forwarded to your number, well that doubles the fun.

So these guys figured call forwarding to international numbers won’t work, and chose the mobile option. Although it’s a bit risky (you need to be able to collect the money from the cellular operator before the cookie jar slams shut) but sounds lucrative. Now comes the final step in a Vishing scam like this; you need to convince a lot of people to do the call forwarding, and for that you usually use a Voice-over-IP line with a pre-recorded message. But not these guys: the post’s author confirmed to me that his mother spoke to a flesh-and-blood voice who actually answered her questions, had a perfect Hebrew accent (it wasn’t a Nigerian who went to Jewish Sunday school) and told her the number to call twice (and even waited until she grabbed a pen).

Calling manually is risky: people can trace back the call and find out where you were. Hiring telemarketing is typically out of the question (lets just try to imagine the brief to the telemarketing team) and manually calling hundreds of people is really not cost effective.

So why the manual call? The only thing that comes to mind is they were beta testing or watching to see the response from the cellular company or law agencies. Maybe they are even using Israel as a beta site for an international Vishing attack? When the FBI or secret Service (or Israeli Police) catch them, I hope they ask. With a bit of luck they’ll post a hint here in the comments.

I’d love to hear the background story behind this one:

[CiscoWorks IPM] version 2.6 for Solaris and Windows contains a process that causes a command shell to automatically be bound to a randomly selected TCP port.

Why on earth? And why a random port?

And if you’re still wondering, yes - it’s a remote root shell with no authentication

Remote, unauthenticated users are able to connect to the open port and execute arbitrary commands with casuser privileges on Solaris systems and with SYSTEM privileges on Windows systems.

Cisco is being cruel and only disclosing the technical info. Common Cisco, share the juicy parts! We want Full Disclosure!

My wife has just received this email via linkedin:

Subject: Equity Needed

LinkedIn
[name deleted] has sent you a message.
Date: 3/01/2008
Subject: Equity Needed
May I kindly accept a donation of $100 on your behalf? [url to donation page]

Thank you for understanding.

Visiting the donation page brings up the following explanation:
“With the new status update feature on LinkedIn I thought we should have some fun and in the process help me make my first million to jump start my new companies. I would like you to set your status on LinkedIn to “wants you to help [me] make [my] 1st million via LinkedIn: [url]””

I remember hearing a lecture circa 1995-6 about Ipv6 and how the Internet world will come to an end if we don’t adopt it soon. The crisis was a dwindling allocation of IP’s (the early Internet version of a carbon footprint). The fear was that “In 10 years, every man on the planet will have between 10 to 20 IP addresses on him”. But when I heard that, I didn’t really think about the poor IP forests that are taken down every year to accommodate the greedy globalization economy, I thought of privacy.

The end of that discussion is now clear: shortly after I heard the lecture Network Address Translation (NAT) became popular, and IP allocation was no longer a problem. Not only that, but IPv6 went from a “must have” to “we’ll get around to it some day” and is still in the process of being rolled out (slowly) to this day. But the privacy issue still remains.

If every person has an IP (or more than one IP, although that seems less likely nowadays) then we know everything about him. Unlike the virtual world, where we no longer can connect a person with an IP address without correlating half a dozen logs, in the physical world an IP will likely be more like a phone number – something unique and personal.

I thought about this when I read about a Nokia experiment where people transmitted their location to a Nokia center to enable traffic monitoring. Nokia says data is sent anonymously, and I believe them; but even if not, every Nokia device has a private (NAT’ed) address changed almost randomly by DHCP. So tracking again requires long and tedious log correlation and privacy is difficult to compromise.

What, then, will happen with IPv6? If DHCP and NAT increase privacy, is IPv6 a threat? Not an imminent threat, of course, but it is definitely ‘creeping’ in, and some day if there are enough addresses and NAT is not necessary, perhaps every blackberry in the world will have a unique IP address that will be with it forever. That’s a scary thought – if you comment in this blog post using your real name, I can take this information with me and give it to a friend of mine that works in Nokia who will tell me where you are right now. Think about the scene in “Jay and Silent Bob” where they go and beat up the people who posted bad comments about their movie; it suddenly becomes a whole lot easier to do…

My bank forced me to change the login password again; they claim it’s an automated procedure that happens every 90 days, but I know that it actually waits for me to remember the password and then immediately forces me to change it.

When I went in to change it, I was reminded of the draconic rules: it has to be at least 6 characters, with at least 2 numbers and at least 2 uppercase and 2 lowercase. These guys went to the security by obstruction school, no doubt.

I decided to fight back. As I finally got around to remembering this awkward strange password I had to pick 90 days ago, I decided I’m staying with it. So I changed it to something else, which I had to write on a piece of paper for fear of forgetting within 30 seconds (if you saw memento, that movie is about me. And I try to always order beers in bottles since seeing it), and I then went to the ‘change password’ section to change it back to my awkward-but-conditioned-to-memory password.

Naturally, the bank was trying to set me straight. “You can’t change back to any of your last 5 passwords” it told me with a grinning smile, giving me the solution right there. As you can undoubtedly guess, I returned the favor by changing the password 5 times to different things and then changed it back to my old one. I win. Next round in 3 months.

People will always outsmart security systems that try to force them into making the ‘right’ decision. What I’ve done today (and I’m quite proud of it, thank you) is being done every day by people who use their CD-ROMs as coffee trays and have never used any
program that didn’t automatically run when double clicking an icon.

But here’s what is really bothering me: What exactly is the attack scenario here? I would like to see the statistics that show how many attackers actually manage to capture a username and password and only fail because they try to use it after 90 days. While these huge numbers are crunched, please put on the Y-axis how many attackers found the password on a post-it stuck to the monitor because the password is so complicated to remember.

Or maybe so many attackers brute force the password, obviously hundreds of millions of times every day for a single account since there is a clear an immediate need for a long and complicated password (BTW, if this attack is possible, someone should tell me how to do it. I’ve been locked out a few times for failing to type the password correctly within a few guesses. I need a few guesses because I didn’t remember which was the current password, which, as you remember, changes every 90 days).

Being the cynic that I am, and having read enough security policy documents, I can guess why the password policy is the way it is: it’s easy to explain and justify, and it makes sense when showing in a powerpoint slideshow. I once heard from a high-profile organization that due to a successful break-in to their network they decided to tighten up security: all passwords now had to be 9 characters instead of 8. I’m guessing someone was promoted for this genius action, and there’s still enough room to increase it further when the next break-in comes (now that’s thinking ahead).

How is a complex password policy bad? Let me count the ways; It makes your user you enemy instead of your ally. It distracts the security people from the real threat. It gives a false sense of security. It encourages your users to find flaws in your security system and use them. What else? I had more, but somebody just came in the door and I forgot.

Ophir put together a nice analysis on how much it would cost to break the security system of SmugMug.com.
This, in response to a bounty that is advertised on their web site.

I think he’s being generous. The really bad guys (people who make money from cybercrime) have access to countless of “free” machines; the crackers can easily break into a few boxes to use them for the attack Ophir describes. But mainly he’s being generous because he is giving them free security consulting, which is what they really need. Hey, SmugMug guys: a security contest is not a cheap replacement to an actual security audit (or consulting with an expert) just like bug bounties are not replacements for QA.

And only god knows why in 2007 the notion of my-url-is-so-long-nobody-will-guess-it is still alive. What do they teach in CS anyway?

The last week of December is sometimes an interesting week in our industry.

IT security is often pictured as a fight between the ‘good guys’ and the ‘bad guys’. Well, from December 25th to January 1st, the battlefield is noticeably skewed in favor of the bad guys.

It’s not too difficult to see why - the CSO’s are on vacation. The IT staff is minimal. Nobody would risk deploying a patch that would affect the entire company come January 1st (and who wants his boss to come back to work after a New Year’s party and find out her computer doesn’t boot). On the vendor side, things are similar; you better not find a critical exploitable buffer overflow in this critical week - they’ll be no one to fix it. Or deploy a workaround.

Last year, Determina reported the .ANI buffer overflow to Microsoft in December, but the acknowledgment from MS only came in early January (not to mention the patch itself came in March).
Two years ago the WMF exploit made noise and since the Microsoft engineers were on vacation Ilfak and ZERT had to pitch in and release 3rd party patches for this problem.

In Christmas 2004, Ironically enough, Microsoft was busy with the first .ANI vulnerability (this one reported by eeye) almost identical to the one that followed 2 years after and again a patch that waited until after the MS QA team had time to recover from the New Year’s hangover.

Six years ago, David Litchfield turned Oracle’s then marketing tagline “Unbreakable” into pure mockery by discovering a serious of remotely exploitable vulnerabilities which of course were not patched in time for Santa Claus season.

These stories remind me of the Christmas party at the Nakatomi building in “Die Hard”, only in our case the attackers have the additional benefit of the “out of office” messages telling them who left their post (not to mention not all companies have John McLain to save them from imminent doom).

Will this holiday season be quiet? So far there aren’t any clouds on the horizon, so lets hope it stays that way for another 10 days or so. After all, even us security folks need our R&R…

Happy holidays everyone!

I’ve said it before - some vendors just don’t get it. Security culture isn’t something you can fake.

Well, according to theregister, beThere customers are still vulnerable to the security flaw Sid reported here back in February. When you think about the fact this has been reported to beThere long before Sid published the details, you can see how embarrassing the situation is.
Some companies think security advisories should be handled by the PR department. Well, it shouldn’t. And if you’re a beThere customer, fix your system pronto, and take note of your ISP’s attitude when it comes to your security.

Joe has a nice write up on the inner working of the Pushdo Trojan.

Pushdo is interesting since it was written for “future use” - i.e. it updates itself to obey his master’s latest needs and requests. It also has intelligence-collecting routines and in general shows how sophisticated the bad guys are getting.

According to several Israeli newspapers google has exposed the IP address of a blogger that was using the “blogger” service.

You might think he was posting instructions on how to prepare a nuclear bomb or the secret Coca Cola formula. It’s much much worse. He was defaming officials in the “Sha’arei Tikva” municipality, which most Israelis can’t even place on a map, and needless to say have little to no interest on the intrigues and political wars there.

My point is, there is no benefit to anyone for exposing the blogger’s IP except to let these officials take him to court, and while google gave a weak legal fight, the decision was reached by out of court settlement, which means they didn’t even try to go the distance in order to block this request.

I think the main issue is not the blogger’s right for anonymity; it’s more about google’s unclear policy on what they do with the information they have. We know google save search data. We know that they have access to deleted emails on gmail (for who knows how long). We don’t know what they do on google talk, but we can guess. What we already know is scary; the fact that we don’t know the rest is even scarier.
It’s clear to everyone that google has information about us and our private life more than any other Internet entity (we had a securitoon about it a while back). Now it’s clear they are playing loose cannon with that information.

Update: Someone identifying herself as “google employee” writes in the talkback comments to the article that google only handed the IP, but the ISP gave the complete identifying information from that IP, and that the press’s picking on google is unjustified. If that google worker is reading this, feel free to email me your version of the story and it will be posted here anonymously (or just leave a comment below).

You all remember cybersquatting, a popular sport in the late 90s, right?
McDonalds.com, JenniferLopez.com, Hertz.com and Avon.com thankfully all point to the right web sites today, but thaiairline.com, mcdonald.com, luftansa.com, gugle.com, barnesandnobles.com and other misspellings are fake web sites intended to trap the casual surfer with a hand that’s a bit too much quicker than the eye.

These web site traps are successful because web sites are so easy to remember, people don’t bother bookmarking them. It used to be that if you wanted to know the weather in Minnesota you had to go to http://www.geocities.com/Athens/rubytuesday71/weatherinminnesota281007.html . Today you go to weather.com (or type “weather for Minnesota” in google) and get an immediate response.
If you want to go to the McDonalds web site, you don’t even spend the 10 seconds to look it up – you will type McDonalds.com and expect to see the latest dollar meal menu.
But the same is true for the other popular form of communication – email. If I know the person’s name and company (or free email system) I will generally just type it up rather than look it up on my address book.
Of course, back in the hotmail days when John was john_sm1th253@hotmail.com I couldn’t rely on my memory alone. But today, if your name isn’t John Smith, it’s probably not too difficult to get a decent first name/last name combination on gmail, yahoo or some other free mail system, and certainly on your corporate email system.

So will we start seeing cyber-squatting on email addresses? Maybe we already do. There is no real way to know who’s behind a certain email address and while it’s merely funny if a guy names Roo Taylor gets the email root@aol.com, it could actually be dangerous if some bad guy owns john@gmail.com, johnsmith@gmail.com, johns@gmail.com, etc. Imagine how much legitimate mail is accidentally sent to those accounts by people who send the latest budget figures to their boss at work and also CC his personal address so he can watch it from his home machine too.

I have first-hand experience of this ‘attack’. Luckily for me I’ve got the login to aviram@gmail.com (piece of cake. All you need is to have a “google-in-law”. For me it was as simple as my office neighbor’s wife having a cousin that works for google. Then they sign you up for a new experimental beta google product called “google mail” and you get not only to pick your first name as login, but send invites to a bunch of envying friends). As gmail becomes more popular I’m receiving invitation to birthday parties of people I don’t know, detailed minutes of brainstorming meetings I’ve never been to and last week a bunch of emails with the list of hospital equipment and inventory, all sent to some other ‘aviram’. I can’t imagine what would have happened if my first name was more common. I’m also pretty sure it’s still possible to register gmail accounts with common misspellings and dig out some of the emails that come out.

At the very least, this would give the bad guys get a fresh harvest of active email addresses. But if they’re lucky, they may receive an email that carries a personal story that can be exploited further. Think about a young guy sending his parents pictures from an Internet cafe about his Africa safari trip. A simple typo sends the email to our bad guy who then forges a follow-up email to the parents telling them his wallet was stolen and that they need to wire money to help their stranded son.

Cybersquatting is easy to identify and is usually settled in court. With “email-squatting” I don’t see a clear and obvious solution; in the meanwhile, be sure to only use your address book…

If there’s anyone out there who wants to take down SecuriTeam blogs once and for all, here’s your chance.
On Thursday Gadi, Noam and I will be on the same airplane flying to trsec in Istanbul. In case of an airplane crash, the root password will be lost forever and save for the daily post from Juha-Matti the blogs will go dark with no one else writing (yes fellow SecuriTeam bloggers, I *am* looking at you).

Anyway, if you’re in the area, Istanbul is a great place to visit this time of year. Mail us for an invitation (we’ve got a bunch of “SecuriTeam” tickets reserved) and come by on Friday to Profilo Alışveriş Merkezi to say hello and we’ll buy you a beer^H^H^H^H coke (Turkey is a Muslim country).

I got the following email from Ameritrade on Friday. If anyone has more details about this story please comment below.

Let me tell you why I am sending you this email. While investigating client reports about the industry-wide issue of investment-related SPAM, we recently discovered and eliminated unauthorized code from our systems. This code allowed certain client information stored in one of our databases, including email addresses, to be retrieved by an external source.

Please be assured that UserIDs and passwords are not included in this database, and we can confirm that your assets remain secure at TD AMERITRADE.

What we want you to know:

• Once we discovered the unauthorized code, we took immediate action to eliminate it. We are confident that we have identified the means by which the information was accessed and have taken appropriate steps to prevent this from reoccurring.
• You continue to be covered by our Asset Protection Guarantee, which protects you and your assets from any unauthorized activity that may occur in your account through no fault of your own. If you lose cash or securities as a result of such activity, we will reimburse you for the cash or shares of securities you lost.

While Social Security Numbers are stored in this particular database, we have no evidence to establish that they were retrieved or used to commit identity theft. To further protect you, we have hired ID Analytics, which specializes in identity risk, to investigate and monitor potential identity theft. ID Analytics provides identity risk services to many of the country’s largest banks and telecommunication companies, as well as government agencies. Following its initial evaluation, ID Analytics found no evidence of identity theft as a result of this data breach. We will retain its services on an ongoing basis to support your TD AMERITRADE accounts and to monitor for evidence of identity theft. We will alert and advise you if any is found. As always, we encourage you to remain alert in guarding your personal information, regularly review your account statements and monitor your credit activity from the major reporting agencies.

For more information on protecting yourself against the possibility of security threats, please visit our online Security Center.

We sincerely apologize to you for this situation and want to assure you that protecting the security and privacy of your assets and information remains a top priority. We have made and will continue to make significant investments in security software, systems and procedures, and we will remain vigilant about protecting you.

We want to answer any questions and address any concerns that you may have about this matter. For more information, including a list of Frequently Asked Questions (FAQs) and an additional message from me, please go to www.amtd.com or contact Client Services. Please note that we are anticipating increased call volume during this period, which may lead to long wait times. We encourage you to review the FAQs and, if you have a question, to log on to your account and send us a secure email. Once again, please be assured that your assets are secure at TD AMERITRADE.

Sincerely,

Joe Moglia
CEO
TD AMERITRADE

Update: Here’s some more information by Ed Falk at CircleID. It seems that Ameritrade either sold the list or someone hacked in and stole it. I’m not sure which option I prefer…

Tomorrow is Rosh Hashana, the Jewish new year. Ten days after is “Yom Kippur”, a day of fasting (not for me, though. I will be spending Yom Kippur speaking at the CNASI conference in Sao Paulo and the local “Churrascarias” are just too good to miss. God will have to forgive me this time, but I’m sure she understands - there has to be a Churrascaria in heaven.
By the way, if you are in Sao Paulo on Thursday or Friday next week drop me a note and I’ll buy you a caipirinha).

This period between Rosh Hashana and Yom Kippur is when every Jew should summarize the year that ended and think of all the faults that he has done to his fellow men, so that he can fix those or at least ask them for forgiveness. When it comes to providing security to their users, most organizations need to ask for forgiveness. So to help you, even if you not Jewish, here’s a quick check list of bad things you may have done to your users this year.

* Not provide a useful service.
A common fallacy is that security is the opposite of usability. In fact, there’s very little correlation between usability and security and anyone who says otherwise is using security as an excuse to not do something.
The worse offenders are those who prevent you from a certain service in the name of “security”. Lets see: I can buy online anything that I wish using only a credit card (amazon, ebay). I can transfer money to people and have them transfer money to me (paypal). I can buy plane tickets and print my boarding pass (all airlines). I can buy and sell stock. Order food. File my taxes. Consult with my doctor.
Whatever the service you think of providing through a computer, it’s probably not as sensitive as my medical information, not as expensive as a first-class airline ticket, not as financial as a money transfer and not as fresh as a hot pizza. All of these can, and are, done over the Internet every day - so what’s your excuse?

* Not giving your users the best security possible
Here’s a common line: “We’re not a target for hackers, so lets use a fixed password that is hidden in the HTML page inside a HIDDEN form field. What are the real chances of anyone finding out?”. There is no excuse for not using the basic, common, proven security measures. Putting a decent security for just about any system is not an expensive task and just like you lock your door even though you’re not fort knox, you should protect your system with something that is not trivial to break by someone who knows the system design. By the way, sometimes all it requires is a little thinking - some of the most effective security measures are just clever design ideas.

* Not solving other system’s problems.
So you’ve implemented a nifty challenge-response system but your password is stored plaintext in a backup database that sits on an open share. The fact that you are not responsible for the backups does not relieve you from the obligation to ensure the system is secure end-to-end.

* Not thinking “how can I improve my system’s security”.
Maybe you have an excellent security in your system. It might even be tested regularly and comes up with a great score. But what can you do to further secure it? Maybe there’s a new feature in the framework you’re using, or a new plugin/widget/component that can help your users be a little more secure (while not compromising on usability!). I don’t like to use clichés like “security is a process”, so I won’t. But you get the idea.

* Not helping your users protect themselves against your system.
When doing threat analysis designers commonly forget an important part: your users should be able to defend against attacks from your system. It’s the ethical thing to do: what if some day someone hacks into your system? What can they then do?
But it’s also the practical thing to do. If your system is potentially dangerous to users, they won’t use it. Forcing ActiveX usage is an example where many systems fail: some enterprises disable ActiveX in browsers as part of their security policy (some even go the extra mile and disable Internet Explorer completely). These organizations will not be able to use your service. The same goes for dangerous client-side scripts, needing admin privileges to do stuff and replacing vital system files.

The good thing about security is that like with Yom Kippur, you always get a second chance. No matter how many of the above mistakes you’ve made, it’s not too late to fix it. And when you do, most people will forgive you - that’s a sure way to pile up your karma and go to heaven (you can later exchange the karma points for whatever your religion keeps score in).

aviram@beyondsecurity.com