Continue reading »]]> Michal Zalewski (aka lcamtuf) has just announced that google is changing the terms of its vulnerability purchase program. The google announcement says:

Today, to celebrate the success of [the program] and to underscore our commitment to security, we are rolling out updated rules for our program — including new reward amounts for critical bugs:

• $20,000 for qualifying vulnerabilities that the reward panel determines will allow code execution on our production systems.
• $10,000 for SQL injection and equivalent vulnerabilities; and for certain types of information disclosure, authentication, and authorization bypass bugs.
• Up to $3,133.7 for many types of XSS, XSRF, and other high-impact flaws in highly sensitive applications.

Interestingly, the earlier part of the announcement says that the existing program resulted in:

“over 780 qualifying vulnerability reports that span across the hundreds of Google-developed services, as well as the software written by fifty or so companies that we have acquired. In just over a year, the program paid out around $460,000 to roughly 200 individuals.”

So, depending upon how you do the arithmetic, over the last year google paid out around $590 per vulnerability, or around $2300 per researcher. Whatever your views on the merits or otherwise of paying for vulnerabilities, that strikes me as pretty cheap, in all senses of the word.

As an aside, I found it amusing that the first commenter on the google posting was one Andrew Wallace, who styles himself an “Independent Consultant”. Wallace has been making a nuisance of himself around various security related mail lists and web fora for a while now. He used to post as “n3td3v” or latterly, as “Andrew from n3td3v”. Back in July 2010, Wallace labelled the google researcher Tavis Ormandy a “cyber terrorist” following Ormandy’s rather public disclosure of a nasty vulnerability he believed Microsoft were trying to hide. Interested (or bored) readers are invited to search the ‘net for Andrew Wallace, n3td3v.

It is also worth recording that as a result of Ormandy’s (some may say “premature”) disclosure in June 2010, after an initial furious response from Mike Reavey, Head of MSRC, Microsoft went on to devise and publish a new “Coordinated Vulnerability Disclosure” policy (warning, MS docx format document) covering the disclosure of “zero day” vulnerabilities in other vendor’s products.

Continue reading »]]> Bugtraq can be an interesting list. Back in June 2008 I noted that one Craig Wright had posted an advisory about a vulnerability in an Oral B toothbrush. Well, just over a week ago a chap called Gabriel Menezes Nunes posted a proof of concept remote denial of service attack on a Sony Bravia television set. He had discovered that a packet flood attack to any port on his TV using the tool “hping” would cause a denial of service. In his post he says:

“After 35 seconds the TV stop working and back. This happens 3 times. At fourth time, the TV shuts down. In less than 3 minutes, the TV is off remotely. It is necessary to turn on the TV physically.”

I can’t help thinking that using the normal remote control would have been easier.

Continue reading »]]> This week the guardian, my newspaper of choice, is running a week long series of articles under the theme “battle for the internet“. The reporting looks set to be interesting and is due to cover the following themes: “the militarisation of cyberspace”, “the new walled gardens”, “IP wars”, “civilising the web”, “open resistance”, and (doomladen prophecy) “the end of privacy”. Personally I find the terms “cyberspace/cyberwar/cyberjihad/cyberwhatever” a horrible americanisation, but unfortunately the labels seem to have gained some traction even here in the UK. Whatever, it is at least refreshing that a mainstream newspaper (the guardian is mainstream, right?) should be taking a look at the issues rather than leaving it to the specialist press.

Yesterday’s reporting though was a hoot. The paper led with a front page article reporting an interview with Sergey Brin. Brin is reported to have said:

“there are very powerful forces that have lined up against the open internet on all sides and around the world”. and “I am more worried than I have been in the past, it’s scary.”

OK – I can see how there could be a number of possible threats to the continued existence of the sort of open and collaborative ‘net that I so admire. But the guardian article went on to say:

“The threat to the freedom of the internet comes, he claims, from a combination of governments increasingly trying to control access and communication by their citizens, the entertainment industry’s attempts to crack down on piracy, and the rise of “restrictive” walled gardens such as Facebook and Apple, which tightly control what software can be released on their platforms.”

“He said he was most concerned by the efforts of countries such as China, Saudi Arabia and Iran to censor and restrict use of the internet, but warned that the rise of Facebook and Apple, which have their own proprietary platforms and control access to their users, risked stifling innovation and balkanising the web.”

and moreover

“There’s a lot to be lost,” he said. “For example, all the information in apps – that data is not crawlable by web crawlers. You can’t search it.”"

So: along with restrictive regimes and an entertainment industry fighting to retain a lost business model, according to the world’s largest infringer of personal privacy, one of the biggest threats to the internet is the fact that apple and facebook won’t let google search the data they have gathered.

Is it just me? Or is this bonkers?

Continue reading »]]> Today I received two (make that four now – must sort out my spam filters) phishing emails from a source new to me. Each email purported to come from “linkedin” and each invited me to login to respond to “invitations from your work colleague”. Since a) I have never been a member of linkedin, and b) am retired, the invitations immediately looked suspect, but the return address looked real at first sight. That is, until I looked more closely. The actual address used was linkedln.com (with a second letter “l”) rather than the correct linkedin.com.

Nice try.

Continue reading »]]> When I logged on to my new bank site this morning, I tried the “help” offered on the opening screen just to see what they had to say about the range of options available. I was not best pleased to be greeted by the message “Flash is not installed, is not enabled or is not up to date” together with a nice big button marked “Get Adobe Flash Player”. No – I don’t think so.

Adobe products have an unfortunate history of critical vulnerabilities. Indeed, only a couple of weeks ago they released a patch for a critical vulnerability in Adobe Flash Player 11.1 and earlier for Windows, Macintosh, Linux and Solaris. It wasn’t the first, and it certainly won’t be the last. There are probably a whole bunch of zero days out there primed and ready for use.

I do not want to see flash on one of the most critical sites I use. And I have told my new bank exactly that. Watch this space.

Continue reading »]]> I have recently moved my bank current and short term savings accounts. Partly this is a political statement in support of the move your money campaign, and partly because I feel that my money might actually be a bit safer (if only slightly) in a small UK Mutual than with the UK arm of a large Spanish Bank. However, my reason for mentioning this here is that the move gave me the opportunity to compare the on-line mechanisms of both my old and new providers and it also got me thinking again about the way I actually do my on-line banking.

As you would expect, I do all my on-line financial transactions from my linux desktop. Given the prevalence of sophisticated banking trojans (PDF file) such as ZeuS, I really don’t see how anyone could comfortably use a windows based machine, even one fully patched, with up to date virus protection and firewall in place. But I go further than just using my desktop, I actually only log on from a second desktop within a virtualbox VM. Further, the browser I use in that VM is as stripped of functionality as is possible (no addons, no plugins, defaults to block cookies etc.) and only ever connects to my bank(s) and no other sites. Unfortunately, the banks insist on cookies and javascript so I have to enable those selectively.

The thinking here is that my browser is the least secure (and probably most targeted) application on my desktop. So if I use a browser which I know has not connected to anything other than the two or three financial sites I trust, I should be relatively safe. Shouldn’t I? (OK, DNS poisoning could have redirected the browser to fake sites, but you get the drift I’m sure). And the best way to be sure that the browser I use is nailed down, and uncorrupted, is to run that browser from a separate machine. However, separate physical machines are expensive and it is tedious to have to fire up another box just to handle my banking when I could do it all from a VM.

But if my main desktop is already compromised (with say a key logger) how safe am I? One of the nice features of virtualbox is its ability to capture both the keyboard and the mouse automatically whenever the guest OS is in focus. For example, on starting a new guest OS, virtualbox says “You have the auto capture keyboard option turned on. This will cause the VM to automatically capture the keyboard every time the VM window is activated and make it unavailable to other applications running on your host machine.” So theoretically, all keypresses will be intercepted by virtualbox and will be invisible to the underlying host OS and its applications. But does this apply to a keylogger trojan already in the host OS? I guess that depends on the trojan and where within the complex stack of kernel, kernel modules, virtualbox and applications it actually hooks itself. But after revisiting and pondering upon my previous assumptions during the move of my accounts, I can’t help feeling that my (rather elaborate) security mechanisms are actually no more than a nice warm security blanket.

But they do make me feel safer…..

Continue reading »]]> As I have mentioned in other posts here, I run my own mail server on one of my VMs. I do this for a variety of reasons, but the main one is that I like to control my own network destiny. Back in October last year I noticed an interesting change in my mail experience with my HTC mobile (actually my wife first noticed it and blamed me, assuming that I had “twiddled with something” as she put it). Heaven forfend.

My mail setup is postfix/dovecot with SASL authentication and TLS protecting the mail authentication exchange. My X509 certs are self generated (and so not signed by any CA). I pick up mail over IMAPS (when mobile) and POP3S (at home – for perverse reasons of history I like to actually download mail to my main desktop over POP3 and archive it to two separate NAS backups). I send via the standard SMTP port 25 but require authentication and protect the exchange with TLS.

My mail had been working fine ever since I set it up some years ago, but as I said, back in October my wife complained that she could no longer send email from her HTC mobile (we both use t-mobile as the network provider). She was at work at the time so away from my home network. Both our phones are setup to use use wifi for connectivity where it is available (as it is at home of course). When my wife complained I checked my phone and it could send and receive without problem. But when I switched wifi off, thus forcing the data connection though the mobile network, I got the same problem as my wife reported. On checking my mail server logs I read this:

postfix/smtpd[28089]: connect from unknown[149.254.186.120]
postfix/smtpd[28089]: warning: network_biopair_interop: error reading 11 bytes from the network: Connection reset by peer
postfix/smtpd[28089]: SSL_accept error from unknown[149.254.186.120]:-1
postfix/smtpd[28089]: lost connection after STARTTLS from unknown[149.254.186.120]
postfix/smtpd[28089]: disconnect from unknown[149.254.186.120]

(the ip address is one of t-mobile’s servers on their “TMUK-WBR-N2″ network)

Everything I could find about that sort of message suggested that the client was tearing down the connection because there was something wrong with the TLS handshake and it was not trusted. Checking earlier logs, I found that t-mobile’s address had apparently changed (to the address above) recently. So I assumed that some recent network change following the Orange/T-mobile merger had been badly managed and all would be well again as soon as the problem was spotted. Wrong. It persisted. So I had to investigate further. As part of my investigation of the error, I tried moving mail from port 25 to 587 (submission) because that sometimes gets around the problem of ISPs blocking, or otherwise interfering, with outbound connections from their networks to port 25, No deal. In fact it looked as if t-mobile were blocking all connections to port 587 (I assumed a whitelisting policy block, or again, a cockup).

So, the scenario was: mail works when connecting over wifi and using my domestic ISP’s network, but doesn’t when using t-mobile’s 3G network. Symptoms point to a lack of trust in the TLS handshake. Tentative conclusion? There is an SSL/TLS proxy somewhere in the mobile operator’s chain. That proxy sucessfully negotiates with our phones, but when it gets my self certified X509 cert from the server. it can’t authenticate it and decides that the connection is untrusted so tears it down. My server sees this as the client (my phone) tearing down the connection. [As it turns out, this conclusion was completely wrong, but hey].

I said in an email at the time to a friend whose advice I was seeking, “I suspect cockup rather than outright conspiracy, but if my telco is dumb enough to stick a MITM ssl proxy in my mail chain, they really ought to have thought about handling self signed certs a little better. Otherwise it sort of gives the game away.”

In response, he very sensibly suggested that I should run a sniffer on the server and check what was going on. At that time, I was busy doing something else so I didn’t. And because the problem was intermittent (and my wife stopped complaining) I never got around to properly investigating further. (I should explain that I rarely send mail from my mobile nowadays. I just read mail there and wait until I get home to a decent keyboard and can reply to whatever needs handling from there. My wife just gave up bothering to try).

I should have persisted because of course I wasn’t the only one to experience this problem.

Back in November, a member of the t-mobile discussion forum called “dpg” posted a message complaining that he could not connect to port 587 over t-mobile’s 3G network. In response, a member of the t-mobile forum team suggested that dpg might reconfigure his email so that it was relayed via t-mobile’s own SMTP server. Not unreasonably, dpg didn’t think this was an acceptable response – not least because he would then have to send his email in clear. He then posted again saying that “the TLS handshake fails when the mail client receives a TCP packet with the reset (RST) flag set.” (This is a bad thing (TM). Further, he posted again saying that he had set up his own mail server and repeated earlier tests so that he could see both ends of the connection. At the client side he posted mail from his laptop tethered to his phone which was connected to the t-mobile 3G network. By running sniffers at both ends of the connection he was able to prove to his own satisfaction that something in the t-mobile network was sending a RST and tearing down any connection when a STARTTLS was seen. Again, in a later post in response to one from another poster who apparently manages several mail servers and had been looking at the same issue for a client, dpg says:

“I must say I’m not too pleased to discover that T-Mobile may be snooping all traffic to check for SMTP messages. I have demonstrated that they may be doing this by running a SMTP server on a non-standard port and finding that they still sent TCP reset packets during TLS negotiation – so they must be examining all packets and not just those destined for TCP ports 25 and 587.

I’m also not that keen on T-Mobile spoofing/forging TCP resets. This is the sort of tactic resorted to by the Great Firewall of China (http://www.lightbluetouchpaper.org/2006/06/27/ignoring-the-great-firewall-of-china/) and also by Comcast back in 2007 (https://www.eff.org/wp/packet-forgery-isps-report-comcast-affair) until the US FCC told them to stop (http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-08-183A1.pdf).”

Then 9 days ago, dpg posted this message:

“I finally got to the bottom of this. I was contacted by T-Mobile technical support today and was told that they are now actively looking for and blocking any TLS-secured SMTP sessions. So, it is a deliberate policy after all, despite what the support staff have been saying on here, twitter and on 150. They told me it is something they have been rolling out over the last three months – which explains why it was intermittent and dependent on IP address and APN to begin with.

So, the only options for sending email over T-Mobile’s network are:
- unencrypted but authenticated SMTP (usually on port 25)
- SSL-encrypted SMTP (usually on port 465)
- unauthenticated and unencrypted email to smtp.t-email.co.uk

TLS-encrypted SMTP sessions are always blocked whether or not they are on the default port of 587.”

(As an aside, there is, of course, another alternative. You can ditch t-mobile as your provider and pick one which doesn’t use DPI to screw your connections. You pays your money….)

Following this, a new poster called “mickeyc” said this:

“I’ve been experiencing this exact same problem. I run my own mail server which has SSL on port 465 and also uses TLS on port 587. I used wireshark to confirm that the RST packets are being spoofed. This is the exact same technology used by “The Great Firewall of China”. I have two t-mobile sims. One is about a year old and doesn’t experience this problem (yet), one is a few weeks old and does.”

He went to say that he had also experienced problems with his OpenVPN connections and would be blogging about the problem (damned bloggers get everywhere) and sure enough, Mike Cardwell did so at grepular.com. That blog post is worth reading because it has an interesting set of comments and responses from Mike appended.

Mike’s post seems to have been picked up by a few others (El Reg has one, and as Mike himself has pointed out, boingboing.net has a particularly OTT post which seems to say that he is accusing t-mobile of something he clearly isn’t.

Finally, two days ago, dpg posted this:

“I’m pleased to report that T-Mobile is no longer blocking TLS-secured email on port 587. As a follow-up to an email exchange over the Christmas period I was contacted today to say that, contrary to what I had been told previously, it was never a deliberate policy to block TLS-secured outgoing email. There was a problem with some equipment after all, which was resolved yesterday.”

I tried again myself today. Initially, I got the same old symptoms (“lost connection after STARTTLS”) then I rebooted my ‘phone and lo and behold I could send email.

Like Mike, I tend to the cockup over conspiracy theory, it’s more likely for one thing. IANAL, but it seems to me that it would be in breach of RIPA part I, Unlawful Interception, for the telco to intercept my SMTP traffic in the way it seems to have been doing. That is not likely to be a deliberate act by a major UK mobile network provider.

But I’ll still keep an eye on things.

Continue reading »]]> OK, yes, I know there are probably already a gazillion web pages on the ‘net explaining exactly how to do this, but I got caught out by a silly gotcha when I tried to do this a couple of days ago, so I thought I’d post a note.

Firstly, X is not exactly a secure protocol, nor is it easy to filter at NAT firewalls, so the ability to tunnel it over ssh is hugely welcome. In fact, ssh can be used to tunnel practically any other protocol you care to name, so it should be your first port of call should you wish to connect to a remote system using an insecure protocol. (I use it to wrap rsync for example).

I don’t run X on my VMs (there is no need, they don’t run desktop software) and I had not previously seen the need to run X based graphical programs on those servers. However, a couple of days ago I thought it would be really useful to run etherape on one particular remote server so that I could watch the traffic patterns. Normally I use iptraf (which is ncurses based) when I want to monitor network traffic in real time, but etherape is pretty cool and gives a nice graphical view of your network connections. But it runs on an X based gui.

So. I changed the remote server’s sshd_config to enable X forwarding (“X11Forwarding no” becomes “X11Forwarding yes”) and restarted sshd. On my desktop I similarly changed my local ssh_config file to allow X forwarding (“ForwardX11 no” becomes “ForwardX11 yes”) to obviate the need to use the -X switch on the command line. I then installed etherape on the remote server and fired it up only to get the message “Error: no display specified”. Sure enough “echo $DISPLAY” showed nothing. But I had thought (and everything I had read confirmed) that ssh should take care of setting the appropriate display when X11 forwarding was set.

So I then tried setting a display manually (export DISPLAY=localhost:10.0 on the remote server) and then got the response “Error: cannot open display: localhost:10.0″. So, still no deal. I spent some time scratching my head (and reading man pages) and sent off a query to my local Linux User group in parallel asking for advice. They were gentle with me.

The first, and rapid, response, said:

On the server:

sudo apt-get install xauth

Then disconnect and reconnect the client.

Jobs a good un.

Thank you Brett.

So the moral is, make sure that you have X authorisation working properly on the remote system (check for the existence of $HOME/.Xauthority) if you experience the same symptoms I did.

Continue reading »]]> I am normally pretty careful about my on-line security and privacy. I take a lot of care to ensure that my home network is nailed down tightly and all the clients and servers on it are also nailed down as well as I know how. I don’t use software which is susceptible to the majority of the malware out there; my browser is nailed down as tightly as I can get it whilst still allowing it to be useful (roll on HTML5, I hate flash, but it is so damned useful); I do some, very specific, browsing (such as on-line banking) from within a VM and do not use that browser or machine for anything except that specific activity; I routinely bin cookies and flash LSOs (in fact I find it better to disallow all LSOs in the first place); this blog does not include any email addresses harvestable by ‘bots; my email client is a niche (i.e. minority) product and is configured only to allow text (no HTML or embedded images or webbugs); I use tor when I want to be as anonymous as possible; my local DNS server blocks access to a whole range of addresses I don’t like; and I never respond to unsolicited email.

But I got phished. Damn.

Here’s what happened.

I advertised an unwanted mobile phone on gumtree. I chose gumtree in preference to ebay because a) adverts are free, and b) gumtree allows you to target the advertising to a specific location. I like this idea because it means you can say “I’ve got a doohickey for sale in South London. Come and see it and pay cash if you want it”. My ad gave details of the item for sale and, as is recommended, I chose to have responses emailed to me. Here I made mistake number one – I used my normal email address rather than a disposable one. To be fair, gumtree don’t expose any of your private details, they just forward any responses to the address you give. Here’s where I made mistake number two, I responded to queries about the ad from the address given to gumtree. Damn. Idiot. So stupid.

So why do I think the responses weren’t kosher? Well there were a number of giveaways. Firstly the requests were for information already in the ad (“how much do you want?”); secondly, there were a suspiciously high number of “spilling misteaks” in the emails; thirdly, the correspondent wanted me to mail the ‘phone to a location outside the UK (“Thanks for your quick respond actually i will love to buy the Ad for my Daughter who is currently studying at British international college (BIC) in West Africa so am willing to pay you additional £48.76 for the shipping via Express Air Mail.” (sic)); fourthly, the respondents all seemed desperately keen for me to accept paypal as the preferred payment option. I’m normally quicker on the uptake than this, but sadly it took me four or five emails to realise that there was a pattern here and that the people after the phone seemed to be following a script and were completely ignoring my responses. Here’s a sample:

Someone calling him or her self “Janet Mason”:

“Hello Seller,
Can I know the condition of the item? I think you will accept PayPal. And I will pay the postage and packing cost for the item. If you can send me paypal payment request now and I will make the payment straight away without any delay. Hope to hear from you very soon.”

My response:

“Janet

As the ad say, the phone is in “as new condition”. This means what it says. The phone is completely clean and has no visible markings or scratches.”

“Janet’s” reply:

“Ok send me your paypal Payment request now so that I can make the payment now.”

My response:

“I’d like a bit more detail first please.

Where are you? (Full address and telephone mumber so that I can confirm that I am sending to “Janet Mason”.

Details of your confirmed paypal account (so that I know that Paypal have verifed you).

If you want to know why I am concerned please read the paypal guidance for sellers – particularly the bit about sending only to UK or US based addresses and getting signatures on receipt of goods.

I have received several requests to send the phone to “my daughter/son/nephew” or whatever in various Countries outside the EU. I am naturally suspicious.”

“Janet” then says:

“Hello, 
Am in London right now but due to the nature of my work here in London I will not be able to post the item to my Business Partner Daughter in Nigeria as a New Year Gift. But I will pay for the postage and packing cost via FedEX. Get back to me with your paypal payment request now so that I can make the payment now and get the item posted out tomorrow Morning.”

Correspondence ends…..

Now whilst I have not lost the ‘phone, I have verified a usable email address to a bunch of scammers. I expect my spam volume to that address to increase dramatically. Never mind though, I’m not alone in losing out to the bad guys, and at least I haven’t lost any passwords in the process.

Still, I’m pretty pissed off.