Reports are saying cell phones and Internet connections are off in egypt at the moment. Can a country really shut off its Internet connection?

China, who has placed restrictions on its Internet infrastructure from day 1 (meaning, the whole infrastructure for connecting to the Internet was built with government control in mind) and that develops a lot of its own networking equipment, is unable to really block users. When I’m in China, twitter and facebook are blocked in the hotel and in the office, but not on the blackberry. Most anonymizers work, and some twitter-over-instant messenger bots work as well. Most of the time, I can find the new list of working anonymizers on google, while I’m there – so there’s no special preparation involved. On my last visit I was introduced to a free VPN service that enables unrestricted access to facebook, twitter and other blocked sites, that seems to be quite popular in the country.

Egypt is not as big and certainly not as advanced as China, but is fairly big. As anyone who worked for a large company knows – it’s difficult if not impossible to track all incoming and outgoing connections. We know the DNS servers are refusing to resolve .eg domains – but what if we go into the inner-works. Are some of the IP’s inside Egypt reachable?

One glaring example is the Egyptian stock exchange. Its IP rotates, but at least some connections point to  217.139.183.2, which belongs to the ISP “the Noor group”, in Cairo. Other times it points to 41.222.175.2 that belongs to “Misr Information Services and Trading” in down-town Cairo. Both are clearly reachable and pingable; is every router on the way configured to route communication only to those IPs? Are there other routers, IP’s or servers that are still open for communication? I would imagine that some emergency lines run on IP-based infrastructure that must be kept on; some devices – military ones perhaps – might rely on IP infrastructure. Dial-ups might still exist. Speaking of which: can one dial from Egypt into a modem in Germany?
Also, one has to wonder about internal communication. Blocking the country’s gateways is one thing; but blocking all internal communication is extremely hard to do. If internal communication is available, is there a way to piggyback into those few holes in the dam to get external communication? Taking the egyptse.com example: if the perimeter routers only allow communication to/from the Noor network, can I route my connection through them?

We all know the Internet was designed to be resilient; and forty years after its initial deployment, it’s proving to be very hard to kill, even by those who believe they have their hand on the cut-off switch.

This was sent to me by a friend who wanted to stay anonymous:

There’s a utility called SetFSB which tweaks the clock speed for overclocking stuff.
It was written in Japan, and is used for many years already.
Recently it came to me that I can speed up my old machine by 25% so I dl’ed it as well,
however, when running, I discovered that upon termination, the .exe creates 2 files,
1 batch file and 1 executable.
The batch file is being spawned, and starts a loop trying to delete the original executable, and continues indefinitely until it’s deleted. after that it will rename the new .exe to the be the same name as the old one.
Now, isn’t that suspicious?
I’ve tried googling it, and just found 1 reference in PCTool’s ThreatFire, but the shmucks just got the threat and couldn’t see the .exe and .bat, so they just decided it’s a false alarm and whitelisted the utility.
I thought it would be a good idea to contact the author, give him a chance to explain, and this is message train, which I find very funny:

there’s a uility called SetFSB which tweeks the clock speed for overclocking stuff.
It was written by some Jap, and is used for many years already.
Recently it came to me that I can speed up my old machine by 25% so I dl’ed it as well,
however, when running, I discovered that upon termination, the .exe creates 2 files,
1 batch file and 1 executable,
the batch file is being spawned, and starts a loop trying to delete the original executable, and continues indefinitely until it’s deleted. after that it will rename the new .exe to the be the same name as the old one.
Now, isn’t that suspicious?
I’ve tried googling it, and just found 1 reference in PCTool’s ThreatFire, but the shmucks just got the threat and couldn’t see the .exe and .bat, so they just decided it’s a false alaram and whitelisted the utility.
I thought it would be a good idea to contact the author, give him a chance to explain, and this is message train, which I find very funny:

ME>>>

Dear Mr.

Why after exiting SetFsb, it will create a .bat and new .exe
the .bat will loop to try delete the old .exe, and rename the new .exe to old .exe ?

Thanks!

HIM>>>

Hi,

Yes,

abo

ME>>>

Hello.

Yes… good…

but WHY???
is it a VIRUS?

thanks!

HIM>>> (here comes the good part )

I do not have a lot of free time too much.
Why do you think that i support you free of charge?

ME>>>

to make viruses?

HIM>>> (this is the original font color and size he used!!!)

I do not have a lot of free time too much!

ME>>> (trying to hack his japanese moralOS v0.99)

Please, dear Abo,

You must understand. People start to be VERY worried about your software,
because it behave like a virus.
If you will not give a good explanation to WHY it behave like this,
then people will stop using it, and stop trusting you forever.
Then your name will become bad, and you will have a lot of shame.
I only try to help you.

I hope you understand!

HIM>>>

It is unnecessary. Please do not use SetFSB if you are worried.

Personally, I’m not sure who’s more weird: my friend, overclocking his computer in 2011, or the Japanese programmer not willing to explain if his downloadble program is a Trojan or not.

Not sure what to make of this yet:

“FBI Added Secret Backdoors to OpenBSD IPSEC”

Theo De Raadt seems to be ambiguous about this:

It is alleged that some ex-developers (and the company
they worked for) accepted US government money to put backdoors into
our network stack, in particular the IPSEC stack.  Around 2000-2001.

[...]

I refuse to become part of such a conspiracy, and
will not be talking to Gregory Perry about this.

There is something special about Berlin. Just a feeling that can’t be fully explained, that the cold and snowy weather enhances well. But I also can’t help thinking about the Len Deighton cold-war-espionage books, checkpoint Charlie, east and west clashing in this city that was like an explosive tip of a gun powder barrel.

When I grew up, Sting sang “I hope the Russians love their children too” and what he meant was love them enough to not annihilate the entire planet. War was serious, and war between world powers was scary. Remember War Games? You’d think people will be afraid of Kevin Mitnick’s hacking skills, but what they were more afraid of was him starting world war III that would potentially wipe out hundreds of millions of people.

So I must admit I’m slightly amused by the threats of ‘cyberwar’. Lets assume for a minute John Lennon was wrong and there will never be ‘peace on earth’. Lets assume that whether it’s because of testosterone, ego, or some other reason taught in psychology 101, nations will continue to fight each other. If that’s the case, what better way to do that than on the Internet? Have them hack each other Ad Nauseam; bring down computers or networks, plant Trojan Horses and steal sensitive data. Assuming the current superpowers are China and the US, isn’t cyberwar the perfect way to ventilate mutual aggression without human casualties?

Of course, there’s a worse case scenario where that stops being funny: if cyberwar can be used to shut down critical infrastructure, people will get killed. But that doesn’t seem to be the direction this “war” is going. Nations fighting on the Internet? I say bring it on.

On a related note, check out Richard Stiennon’s new book about Cyberwar. And if you are in DC, go hear him speak on Thursday about Google Aurora, Stuxnet, and the wikileaks DoS attacks. Really fascinating stuff.

Despite what Dilbert Comic Strips may teach you, our job as security professional is to enable information services – not prevent them.

The bad guys do evil: we try to prevent it (or clean-up after) so that users can continue and use systems as if there is no evil in the world. If IT security had a Hippocratic oath, it would probably be along those lines.

Here’s a recent example. This morning I got a call from my credit card company asking me if I’d done some transactions that seem suspicious. I hadn’t, and so they will cancel the transactions (and unfortunately, cancel my credit card and send me a new one). I’m not going to stop using my credit card, and will probably completely forget about this incident. I didn’t lose any money, and the inconvenience was minimal: this is all thanks to the people that chase up the credit card fraud and enable customers around the world to use their cards despite countless attacks on credit card users, some (as my example shows) successful.

Things are not so simple in the email war front. When SMTP was introduced, it described a simple, reliable, scalable system for communication. Almost 30 years after that, we stripped email of some of its most important features. By we, I mean the IT security world. In fact, we’re slowly doing to SMTP what TSA is doing to air travel.

First, the major feature of SMTP: sending and receiving emails. This is probably our biggest failure today: There is no guarantee you will be able to send or receive emails. In fact, if you communicate with the external world, it is almost guaranteed that you will not receive a certain percentage of your emails, and that some emails you send will not arrive. Sure, there are legitimate reasons: we need to protect from spam, viruses and phishing. But the bottom line is that SMTP was designed to reliably deliver an email from point A to point B. Today, we send an email and then call to verify it was received (or send a second email which mysteriously arrives after the first one was blocked).

Next, we kill useful SMTP features. Remember the days when you got an email ‘bounce’ when mistyping the email recipient’s address? Forget about it; those days are long gone. I’m not sure what Spamcop’s exact mission statement is, but it might as well be “make email unuseful”. They have outlawed email bounces (which, by the way, are required by the SMTP RFC) and continued to take out all auto-responders.

Remember read-receipt? Gone. The postal service had this feature in 1841, but we can’t have it in 2010. Do you want to know if a certain email exists? You can’t.  Want to send email directly from your computer without using a mail relay? A non-starter. Ever heard of email fragmentation? This is an awesome feature of SMTP but don’t waste time learning it – it won’t work on the Internet today (and this time we share some of the blame).

Look at HTTP. You click on a link, and you get to the page. If you get an error, you know it’s the web site’s fault. An attack on NCSA’s httpd server is one of the first documented buffer overflow attacks, and yet attacks on modern HTTP servers are practically non-existent. SQL injection and XSS are everywhere and yet users surf dynamic pages all the time without being blocked. We’re doing a good job fixing up HTTP without being a “Mordac”. Too bad we couldn’t do it with SMTP.

Is there hope for SMTP? I think there is. Last decade the doctors were ready to pull the plug on email: spam and viruses were so frequently in the users’ inbox that email was on the verge of being unusable: You had to spent a noticeable percentage of your day clicking the ‘del’ button. These days are over: you rarely see spam in your inbox today, and if you’re like me, you get more irritating chain letters from family members you can’t block (hi mom) than shady ads for pills.

This war can be won. We just need to remember the Hippocratic oath for the IT security world and enable reliable communication again.

Stuxnet is a worm that focuses on attacking SCADA devices. This is interesting on several levels.

First, we get to see all of those so-called isolated networks get infected, and wonder how that happened (here’s a clue: in 2010, isolated means in a concrete box buried underground with no person having access to it).

Then, we get to see how weak SCADA devices really are. No surprise to anyone who has ever fuzzed one.

After that, we get to theorize on who’s behind it and who is the target. What’s your guess?

The recently discovered LNK exploit; using the way Microsoft parses link or shortcut icons for display in order to get something else executed; may be a tempest in a teapot.  It is technically sophisticated, but so far we don’t appear to have seen it used widely.

Probably a good thing.

This exploit could be used in a wide variety of ways.  You can use it in removeable media, so that any time you shove a CD in a drive, or connect a USB stick/thumb drive (or any other USB device, for that matter) to a computer, it results in an infection or some malicious payload.

And remember that OLE stands for object *LINKING* and embedding.  Since it is trivially easy to embed a virus in any Windows OLE format data file, it should be just as easy to create malicious links in any such files.

Microsoft’s own information on the issue seems to indicate that there is a related, but separate, issue with Microsoft Office components, related to Web based activities.  (By the way, when accessing that site, the information about how to protect against the exploit is hidden under the “Workarounds” link, rather than being explicit on the page.)

Some of the potential effects are discussed by Randy Abrams at http://blog.eset.com/2010/07/19/it-wasn%E2%80%99t-an-army

This is depressing, but probably true.  Ethan Zuckerman, at the current TED, notes that the Internet makes us think we being exposed to, and learning from, differing world views, but that, particularly in relation to social networking, we are usually simply seeking out similar views to our own, and reinforcing our existing viewpoints.

You can read a report from the BBC or see the actual talk at TED.

(I like the “imaginary cosmopolitanism” phrase.  It reminds me of being in NYC.)

(If you can’t see the security implication in broadening your outlook, there is no hope for you.)

Did you wonder what this is used for? The following FAQ may give a hint:

Hi! I want to bypass captcha from my bots. Bots have different IPs. Is it possible to use your service from many IPs?

We have no restrictions about IP: with DeCaptcher you can bypass CAPTCHA from as many IPs as you need.

In other words: Just used a Virus to break into thousands of botnet computers and now you are not sure what to do? These guys will help you take the next step and set up myspace/facebook/gmail/twitter accounts while bypassing the CAPTCHA and you can then use that to spam the world. Thank you DeCaptcher for giving the Internet such a valuable service.

BKSSLTTP.RVW   20091129

“SSL and TLS: Theory and Practice”, Rolf Oppliger, 2009, 978-1-59693-447-4
%A   Rolf Oppliger rolf.oppliger@esecurity.ch
%C   685 Canton St., Norwood, MA   02062
%D   2009
%G   978-1-59693-447-4 1-59693-447-6
%I   Artech House/Horizon
%O   617-769-9750 800-225-9977 artech@artech-house.com
%O   http://books.esecurity.ch/ssltls.html
%O  http://www.amazon.com/exec/obidos/ASIN/1596934476/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1596934476/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/1596934476/robsladesin03-20
%O   Audience i+ Tech 3 Writing 2 (see revfaq.htm for explanation)
%P   257 p.
%T   “SSL and TLS: Theory and Practice”

The preface states that the book is intended to update the existing literature on SSL (Secure Sockets Layer) and TLS (Transport Layer Security), and to provide a design level understanding of the protocols.  (Oppliger does not address issues of implementation or specific products.)  The work assumes a basic understanding of TCP/IP, the Internet standards process, and cryptography, altough some fundamental cryptographic principles are given.

Chapter one is a basic introduction to security and some related concepts.  The author uses the definition of security architecture from RFC 2828 to provide a useful starting point and analogy.  The five security services listed in ISO 7498-2 and X.800 (authentication, access control, confidentiality, integrity, and nonrepudiation) are clearly defined, and the resultant specific and pervasive security mechanisms are mentioned.  In chapter two, Oppliger gives a brief overview of a number of cryptologic terms and concepts, but some (such as steganography) may not be relevant to examination of the SSL and TLS protocols.  (There is also a slight conflict: in chapter one, a secure system is defined as one that is proof against a specific and defined threat, whereas, in chapter two, this is seen as conditional security.)  The author’s commentary is, as in all his works, clear and insightful, but the cryptographic theory provided does go well beyond what is required for this topic.

Chapter three, although entitled “Transport Layer Security,” is basically a history of both SSL and TLS.  SSL is examined in terms of the protocols, structures, and messages, in chapter four.  There is also a quick analysis of the structural strength of the specification.
Since TLS is derived from SSL, the material in chapter five concentrates on the differences between SSL 3.0 and TLS 1.0, and then looks at algorithmic options for TLS 1.1 and 1.2.  DTLS (Datagram Transport Layer Security), for UDP (User Datagram Protocol), is described briefly in chapter six, and seems to simply add sequence numbers to UDP, with some additional provision for security cookie exchanges.  Chapter seven notes the use of SSL for VPN (virtual private network) tunneling.  Chapter eight reviews some aspects of
public key certificates, but provides little background for full implementation of PKI (Public Key Infrastructure).  As a finishing touch, chapter nine notes the sidejacking attacks, concerns about man-in-the-middle (MITM) attacks (quite germane, at the moment), and notes that we should move from certificate based PKI to a trust and privilege management infrastructure (PMI).

In relatively few pages, Oppliger has provided background, introduction, and technical details of the SSL and TLS variants you are likely to encounter.  The material is clear, well structured, and easily accessible.  He has definitely enhanced the literature, not only of TLS, but also of security in general.

copyright Robert M. Slade, 2009    BKSSLTTP.RVW   20091129

Xyberpix described how difficult it is to disclose vulnerabilities to ZDI and iDefense. But even after you sold it, the process is just beginning. Sure, the researcher gets paid and he is free to resume his work, but the work us, the vulnerability coordinator, just begins.

We recently received 2 disclosures to our SecuriTeam Secure Disclosure program for Sonicwall and google vulnerabilities. We received sponsors for both vulnerabilities which means there is a commercial organization out there that was willing to pay the researcher for their efforts. That part ended well for the researchers.

Now both organizations want the vendors to patch up. Sounds easy, right? We are giving Sonicwall and google free information about security holes in their products, and want nothing in return except for them to fix it.

Well, it’s damn difficult.

Google is always difficult when it comes to security. When I reported an information disclosure vulnerability in google calendar they ignored me, then sent their PR person to say “it’s a feature”, then silently fixed it claiming it was never there. Dealing with google on security issues is like talking to a girl that speaks a foreign language. But more on that later – lets start with Sonicwall.

Wouldn’t you be expect security vendors to be more aware of security problems in their products? Well, for the last few weeks we’ve tried to bang every door, calling in personal favors to tell Sonicwall (for free, let me remind you) about a security hole in their product.
Why bang every door? Because they won’t talk to us since “we’re not Sonicwall customers”. We can’t open a support ticket and they won’t give “us” support. security@sonicwall? yeah, right. Even good friends couldn’t help. The system will not accept a report from non-customers.

I guess our only course of action is to pay Sonicwall money to let them know about their vulnerabilities. I wonder if that’s Sonicwall’s long term strategy for profit? BTW, if you work for Sonicwall and can help, please contact me – but keep in mind paying Sonicwall for telling them about their own security issues is not a part of our plan.

Back to google. The story there is simple and boring. It’s not a bug, it’s a feature. In fact, every browser has this problem, errm I mean feature. In fact, it’s been proven you can execute javascript on the chrome user’s browser so we’ll leave this open as well. If the stupid web app developers can’t solve this we certainly aren’t going to help them.
But why am I boring you with the broad strokes, go read the discussion:
http://code.google.com/p/chromium/issues/detail?id=46795. Nothing we haven’t seen with previous google security bug handling, just ask this guy.

Yes, it is 2010, and we are still talking about Vulnerability Disclosure to vendors. I guess next we’ll be arguing if heap overflows are exploitable.

Update: We were contacted by Sonicwall and the bug will be looked at. Hopefully security@sonicwall will start accepting submissions from non-customers.

There is no possible way this could potentially go wrong, right?

Doesn’t the phrase “Identity Ecosystem” make you feel all warm and “green”?

It’s a public/private partnership, right?  So there is no possibility of some large corporation taking over the process and imposing *their* management ideas on it?  Like, say, trying to re-introduce the TCPI?

And there couldn’t possibly be any problem that an identity management system is being run out of the US, which has no privacy legislation?

The fact that any PKI has to be complete, and locked down, couldn’t affect the outcome, could it?

There isn’t any possible need for anyone (who wasn’t a vile criminal) to be anonymous, is there?

Hi,

In light of the KHOBE story, it seems a “darker” truth has been uncovered. Apparently the researchers have published their advisory in order to sell their research material to anyone who wants to know more than their limited technical details.

Why is this important? Well, it shows that when publishing their research, their intent was to:
1) Scare
then
2) Sell their software

While there might be legit reasons to check out their research, these new facts do bring the “KHOBE” paper into question, especially whether it is more noise than signal.

More details on the story can be seen here: KHOBE – no problem.

BTW, a bit of exaggeration by our colleague Aviram got him this week’s medal for PR scandal assistant.

In the last 20 years, practically all the large software vendors came out with Single-Sign-On (previously “PKI”) products that were supposed to give a single login that would give you access to all the resources on the network. As good as this idea sounds, in practice that almost never works. Why Single Sign On constantly fails in corporate environments is a mystery wrapped in an Enigma. But it just doesn’t.

On the web, it seems even more logical that a single login will give you access to all the resources, and yet the situation is even worse. Microsoft, google, yahoo, AOL, and now facebook have all tried their Single Sign On initiatives that ended up having users signing up to 4-5 different ‘single sign on’ services and typically just opting for the only single sign on method that works: Using the same username and password everywhere.

Before you ask, OpenID is not a single sign on solution – it’s an identification service. So with that out of the way, are we doomed to never have a workable option to web single sign on?

Well, it seems the solution was always there: in fact, most of us have been using it for a while. Your browser.

Done well, the browser can keep the username/password combination in a secure place, protected by a single password and encrypted on your hard drive. The only risk is a Trojan using your browser to log into web sites without your knowledge – but that’s a risk you have today with keylogger rootkits, so you are not worse off letting your browser save the password for you.

The only two challenges facing the browsers to truly provide an SSO experience were web sites like paypal that refused to let the browser save username/password information (though you could bypass that restriction with bookmarklets such as “Password Saver” on firefox) and the second challenge was just the convenience of needing to login instead of having the browser login for you, as you’d expect in a “real” SSO.

It seems that firefox has picked up the glove. In a recent blog post (http://hacks.mozilla.org/2010/04/account-manager-coming-to-firefox/) firefox announced an add on that will handle account management; likely not much different than what is done today, perhaps a bit more extended and automated. Facebook, google and some others won’t be happy about this move, but who cares. The best thing about this method of SSO is that you don’t need the site’s cooperation for it to work. In fact, as long as they don’t actively resist (e.g. by adding CAPTCHA’s) firefox can be the de-facto standard for account management in the not-too-far future.

Interesting story about collecting data from Facebook.  I wonder if he would have had the same trouble if he had written the utility as a Facebook app, since apps are able to access all data from any user that runs them.  Maybe he could talk to the Farmville people, and collect everthing on pretty much every Facebook user.

All kinds of intriguing questions arise:

Has Facebook threatened to sue Google?  If they did, who has the bigger legal budget?

With all the embarrassing leaks, why doesn’t Facebook simply do some decent security, and set proper permissions?  (Oh, sorry.  I guess that’s a pretty stupid question.)

Does the legal concept of “community standards” apply to assumed technical standards such as robots.txt?  If nobody tests it in court, does any large corporation with a large legal budget get to rewrite the RFCs?

If you don’t get noticed, is it OK?  Does this mean that the blackhats, who try hard to stay undetected, are legally OK, and it’s only people who are working for the common good who are in trouble?

I am not a huge fan of Wikipedia, in terms of tech accuracy, as I’ve noted before.  For a quick idea of a new term it’s great: beyond that, watch out.

However, Charles Muller has pointed out something I hadn’t considered:  that, given it’s popularity, Wikipedia is a prime vector for losing control of your intellectual property.  As one who has had masses of work ripped off by others, I have to be sympathetic to his argument.  He’s got a couple more good points in this quick little piece.