Crackers active in Finland

Background for international readers:

November 5th a list of 16.000 names, street addresses, email addresses and id numbers was leaked and finnish yellow press was spreading panic. Later some organizations admitted that their systems were cracked.

November 12th a new list of half a million email addresses belonging to finnish users was leaked. Yellow press making big headers.

November 13th a partial list of passwords was leaked, list was claimed to belong to the leaked email addresses. CERT-FI confirmed that passwords are real and finnish news services are now full of discussions about the situation.

Any ideas where some of the email addresses and potentially also passwords are coming from? Yes.

List has 52535 addresses from gmail.com domain and 86 of the users use the same trick that I do: append some additional text to the email address using address alias. I've done that myself to track how my email address potentially spreads, but this time we can read hints about the cracked sites cleanly from the address list. There are not many sites that can be discovered this way, but certainly something related to ice hockey, cars, calorie counting and personal finance management.

//Harri

I hope mobile identity won’t fail in Finland

Later this year - maybe - there will be mobile identity infrastructure setup to Finland, operators are ready to issue certificates to users and service providers are starting to offer the benefits of this ecosystem to the end users.

This all sounds similar to the situation that was in Finland at late 90’s when PKI (Public Key Infrastructure) was setup with high hopes. Later this system has been documented as a failure. I hope mobile identity project will not become yet another failed technology driven infrastructure project in Finland, but I can see some dark clouds.

User expectations will not be met

During last six months I’ve heard a handful of presentations about the new mobile identification system and all have included an idea that users will love the system because they no longer must remember tens of passwords to access their accounts in numerous systems. Passwords will be replaced by “secure and easy” mobile login. Unfortunately I’m afraid that it will not happen and users will be disappointed. Reason for my doubt is that MobileID transactions will cost for service providers and they can’t see the reason why they should pay for operators for every single login event. Instead of password replacement, MobileID will be used during registration to ensure user’s identity and after registration user will be authenticated with username and password, just like before. Also for special cases like password recovery MobileID can be used, but user who has hoped that passwords will not be required anymore, will feel fooled.

About user expectations: does somebody really think that most of the services will start using MobileID and developers for example in Silicon Valley are just waiting to get their hands-on experiences about MobileID? No, MobileID is a domestic system that will (or will not) be used by domestic solutions. Don’t expect to get rid of passwords anytime soon!

No exact information available

The system should be available next fall, but technical and economical information is not yet available. Operators cowardly refuse to say anything about the cost of joining and using the system, they only agree that using the solution will of course cost something. In Finland the price will most probably compare to Tupas-pricing, that is approx. 0.20€ per request.

Only for individual users with good income

In presentation slides the certificate issuing process looks nice, but that is only the case if you are a person who has signed a direct contract with the operator. If you are a business user and contract is made by your employer, what will happen? Nobody seems to know.

What if you are using a prepaid account and don’t have an agreement with the operator? Nobody seems to know.

Future proof until...?

When personal identification number was launched in Finland nobody was paying much attention to how it was used and stored - after all it’s just your birthday and some additional bytes. That was the case until it was understood that personal identification number identifies person in almost every system and that information can be abused.

Now with MobileID we are no longer talking about personal identification code but about FINUID (Finnish Unique Identifier) that is “just a piece of data that identifies the user, so nothing very confidential and it can be stored in systems everywhere to identify the user” (and also mapped to personal ID). Someday the same happens as with personal identification and the use of FINUID will be strictly governed and hence the use of MobileID authentication will require careful reasoning and so on... So please, don’t come saying that this infrastructure manages “only” FINUIDs that are stored to multiple transactions logs during the identification process.

My humble request for MobileID providers is: please, don’t create a WAP-like expectation gap between the hype and reality, publish pricing information ASAP, make system available for business and prepaid users and be more exact right from the beginning about allowed FINUID handling.

//Harri

Nokia's statement about the Nokiagate

I just received Nokia's official statement about the case I reported earlier.

Nokia's statement begin.

A Finnish blogger recently posted on his blogsite that Nokia stores users' credentials in Nokia when they try to configure their email account on their Nokia device using direct IMAP/POP access.

For the mobile email account to be created and for the user to enjoy a seamless mobile email experience, his email credentials (namely email address and password) need to be sent to the mail provider's server. In some cases, the user's credentials are sent directly to the mail provider's server, but in other cases, they securely pass through the Nokia mail server, without actually being stored.

Nokia takes security seriously in all phases of the mobile communication systems development process, and will further investigate this case using our normal processes and comprehensive testing. Also, based on the feedback that we have received, we will look into the possibility of amending the on-device email set-up instructions to ensure that end-user information handling in our devices and services is accurate.

Nokia's statement end.

My comment on that statement:

• I completely understand and accept the need to ease the email account creation. Despite that, I still feel that sometimes sending credetials to email provider and sometimes sending those to Nokia's server is not acceptable. I want to be in control who gets my credentials.
• I haven't claimed that Nokia stores user's credentials. I have written that credentials are sent to Nokia - I don't have any idea what happens to credentials after that.
• I asked if credentials are stored. Now we got a clear answer that credentials are not stored. That's good.

If I may suggest a solution to Nokia, would you consider a solution that

• tells to user exactly what's going on during the account creation
• allows user to decide wheter wizard is used or not
• if wizard is not used, no communications is done to Nokia's servers
• if wizard is used, only domain part (e.g. gmail.com) is sent to Nokia server

//Harri

Info about the "Nokiagate"

Today has been an extremely busy day here at Mobilitics and lots of questions have been asked about the Nokiagate, both in post comments and private mail. Let me answer all of those at once.

Yes, Nokia is very much aware of this. I have made a report and they are working on this. Someday they will come out and give comment.

I am not talking here about Nokia Messaging or any other service they are providing. This case is about acessing your mailbox using IMAP without any extra middleware. You input information to connect to your email account and that information goes to Nokia's server. When the deployment server has tested that your account details are OK, information comes back to your terminal and the account is created. Now communication happens between your terminal and the actual email server just as it should.

Having said that, now it must be clear to everybody that Nokia's server is actually logging in to the email account when verifying the credentials. Test sequence includes logging in to both incoming and outgoing services - if that fails, client will prompt you to check credentials. If you want to verify this, you must be able to investigate traffic coming to your email servers.

Yes, according to my tests the verification server is located outside of the European Union, which means that your credentials are also there.

//Harri

Information about Nokia email case

Quick answers for the impatient readers:

1. “Yes”
2. “Yes”
3. “It’s easy”

---

Below are my comments to some reactions I have seen regarding this "Nokiagate".

1) You are stupid! Don’t you know there is a new service called “Nokia Messaging”? It has to be able to retrieve your messages from the server!

Yes, I know there is a solution called Nokia Messaging (read more from here), but maybe I wasn’t clear enough in my initial post: I am configuring direct IMAP/POP access to my own/company/organization/whatever email service and I am not using nor planning to use Nokia’s messaging proxy.

Messaging proxy is a piece of software that you can use if you wish, there’s nothing wrong about that. If you want to use that, then you understand and accept that your credentials must be available to proxy - otherwise things will not work. When you signup for such a service, that is made clear to the user and he accepts it. However, this wasn’t the case in my email issue.

After email wizard has finished with the email configuration, all network connections are done from my terminal directly to the IMAP/POP email server, not to any messaging proxy. When I use email, data traffic doesn’t go via Nokia. There is no reason why my credentials should be sent anywhere else than to my email server.

2) Is the data encrypted?
Yes, the data is encrypted. Read next sentence aloud using ironic voice: “When I configure private email account into my phone, my email credentials are sent to Nokia in a secure way.”

3) Can’t believe this! Can I verify this myself?
It’s easy. First of all, you need some solution to intercept all network traffic originating from your terminal. For this purpose I used WebScarab and Wireshark. WebScarab is a tool that creates an HTTP proxy which will allow you to control both HTTP requests and responses. Install, configure and run it in your desktop. Check your desktop’s IP address and port that WebScarab is listening.

Because sniffing cellular network is beyond my skills, I used WiFi as a data bearer (email wizard will silently use cellular network if that is available). To enforce WiFi connection, put your terminal into offline mode and/or remove SIM card. Then configure a WiFi access point that will use your WebScarab desktop as a proxy (you need the IP address and port here).

When you think you are done, launch browser in phone and try to open some site. If you see the request in WebScarab, the configuration is correct. If not....well, I’dont provide support for this setup.

After configuration is working, run email wizard and see what happens.

---

Request to readers
I don’t have any idea which terminals have this email wizard - and if it exists does it work the same way when configuring an email account. If you find terminals behaving this way (sending passwords), please send terminal information to this post’s comments. Include terminal type and software version (you can see that by going to telephony screen and typing *#0000#).

Update

These are the devices and software versions I've tested and verified password leak:

5800 (20.0.0.12)

N79 (11.049)

E75 (110.48.78)

//Harri

Why Nokia wants my email password?

Many new Nokia S60 terminals seem to have an "email wizard" that helps the user to configure an email account to the terminal. Wizard prompts the user to give some basic information and then in most cases wizard is able to create account with all the correct settings.

Lets use Nokia 5800, an iconic device that has sold over 1.000.000 units. When you start the email wizard, you will see a screen like this

If I click "Back", wizard closes and email account is not created. Clicking "Start" will continue the wizard, but was that answer also consent to store the personal information? Anyway, there doesn't seem to be a way to create an account without this wizard.

Let's create an account for user test.user@mycompany.com (his password is "topsecret" but I will not tell it to anybody). After you have entered this information, the wizard will open a network connection and make an HTTP request to URL

https://ccds.serviceactivation.ext.nokia.com:443/api/v1/rest/?operation=ccds.provider.determineAccount&applicationCode=email&

address=test.user@mycompany.com&password=topsecret&

mcc=244&mnc=91&carrier=sonera

Nice! I just sent to Nokia my email address, password, operator information and terminal type (in HTTP headers, not visible here). All you Nokia 5800 users around the world: did you know that? I didn't know that, nor did I like it.

Today I had an opportunity to play with a new Nokia E75, phone that's supposed to be THE email device of all business users. First impression with the device is very good, it's solid and snappy. When I checked the email client, it was behaving just as in 5800. When you create an account, wizard will send your sensitive data over the internet to Nokia's server.

When I create an email account that has absolutely nothing to do with Nokia's email services, my user credentials are sent to Nokia's server. I guess that this feature can be a show-stopper in some business environments - "hey, let's create email accounts and send our usernames and passwords to Nokia" doesn't sound that good.

According to my tests it seems that if you want to create an email account without giving your credentials to Nokia, you have two options:

• you should give a dummy information to the wizard when it is asking for email address and password. Wizard will try to fetch settings from the internet but finally gives up and you can input the data safely.
• put phone to offline mode when creating the account. That way phone cannot connect to any servers and when wizard notices it, you will be able to enter the email account data without sending it to the Nokia servers.

So finally, here are my questions to Nokia:

• Why you have created an email wizard that by default sends user's email login information to your server without making that very clear and asking explicit permission to do so?
• Why there is no option available to create an email account manually, without any wizards?
• When user starts the wizard and continues from the first screen, does that give permission to Nokia to store my personal information?
• If my personal information was stored to Nokia's servers because I've used email wizard to create an email account, how can I get my data removed from the server?
• How do you use my personal data, collected from email wizard?

Update: Read also my follow up post.

Update 2: I'm trying to give answers to readers' questions here.

Update 3: Nokia's official statement is here.

//Harri

Historic perspective to mobility security problems

When I was reading an excellent performance audit report about Finland’s failed PKI-project (more about that later) I remembered an old project where I was once working. At late 90’s web applications were extremely hot and new thing and the project’s target was to create a browser solution that citizens could use to change their contact details. Somebody had made a decision earlier that the web solution must be very secure and all transactions must be strongly authenticated to ensure that no false data could ever be entered to the system. Because of this security requirement, project had to use PKI solution with Finland’s brand new certificates, identity cards and card readers. Obviously that ensured that the browser solution was very well secured.

However, browser access wasn’t the only channel to change person’s contact data. Instead of using the high-secure browser solution, citizen could pick up the phone and call to customer care center and ask them to change the data. No passwords asked, no certificates needed; just give them new address and change was done.

The thing that I didn’t understand at that time (and I still don’t) was that browser access was ranked very insecure and potentially dangerous, but at the same time the old channel was completely lacking user authentication and still there were no problems because of false data or similar. What made browser so dangerous at late 90’s?

I have a strong feeling that browser was once dangerous because it was a new thing and all risks related to that were overrated. What potentially could happen was interpreted that it must happen. Now ten years have passed and situation is much better regarding browser’s risk assessment; of course the risks still exist but browser itself is not seen so dangerous anymore.

What has taken browser’s place as the very-dangerous-new-thing? Mobility of course! So many times I have been in the situation that the possible mobile solution has been ranked very dangerous to the organization - but at the same time the data is already available in the internet from a password protected browser page. What mobility would mean in this case is that the data would be rendered in a different way to ensure usability in a small device. The risk of loosing the mobile device is real, but properly encrypting local data and/or using mobile browser is a good real life solution. 

Now mobile solutions are suffering from this same “new solution’s handicap” that the browser faced at the late 90’s - if you don’t have time to wait until mobility becomes mainstream you’d better work with your arguments and tell customers honestly what the real risks with mobility are. Perhaps the risk is that the competitor integrates mobility smartly into their processes and performs better than you?

//Harri

Phone as a security token?

It is a good thing to notice that other people have got same ideas and even more, implemented those.  When that happens, idea probably isn't totally useless.

This came to my mind when I today started to think mobile phone as a security token that could add "something you have" dimension to the login process of a desktop terminal. In short my idea was that desktop computer could be constantly "pinging" a certain bluetooth hardware address, and when that device no longer is available then desktop will automatically lock itself. Think about following use case and you will get the idea: you are sitting at your office working with your desktop. Your colleague arrives and reminds you that the meeting is about to begin and you must rush. You grab your mobile phone and run to the meeting. Probably you forgot to lock your desktop and now anybody can use your user account. 

An easy solution to this would be that if desktop were pinging your terminal, the desktop would lock itself when the connection is lost. With Google I found  some applications that are able to do this: LockItNow and BTWatcher.

Because the simple use case (locking terminal when bluetooth connection is lost) is already implemented, I began to think about the reverse: unlock desktop when mobile phone becomes available. Obviously that shouldn't be done just by discovering some device (about bluetooth security issues, check this document).

What do you think about this idea: unlock the desktop when identification is done with bluetooth so that desktop sends a challenge to the terminal, terminal signs that challenge with PIN-locked client certificate and sends the response back to desktop. This way would be possible to implement a "poor man's secure id" system that adds an additional security to desktop environment. In addition to username and password, user must also carry a bluetooth device with a known hardware address, that bluetooth device must be able to accept and sign desktop's challenge and user's client certificate must be correct.

Did I just reinvent the wheel - has this already been done?

//Harri

JoikuSpot and MSISDN authentication

Some weeks ago a JoikuSpot application was launched - this is an application that allows users to turn their 3G/WIFI enabled terminals to WIFI hotspots. Application is currently in beta phase but it is still very usable; when you launch the application in your smartphone, you can connect to new Joiku hotspot with any WIFI enabled laptop, internet tablet, iPod Touch ... whatever you use. Nice and easy. 

For those who have been working with mobile applications know that user authentication is a big problem. Usernames and passwords are difficult to type with small keyboard, client-side certificates are not trivial to implement and so on. One solution that is used (if operator allows) is that user is authenticated with terminal's MSISDN. This is nice solution, because user is effectively authenticated with PIN code: if user can turn on the terminal, that identity is used when he opens a connection to back-end server. 

What you get if you combine JoikuSpot and MSISDN authentication? Security hole.

Today I tried this combination and result was just as expected. I installed Joiku to my terminal and let it publish a WIFI hotspot. Then I connected to that hotspot with a laptop and tried to access an MSISDN authenticated service. As you might guess, service authenticated me (or the Joiku terminal user) and let me in without any passwords asked.

Luckily this is quite difficult security hole to exploit. In order to do that following criteria must be met:

• Joiku is running in a terminal that belongs to user who has access to MSISDN authenticated services
• Attacker is close enough to connect to Joiku hotspot
• Attacker knows which resource to access through the hotspot

Good news is also that Joiku people have announced that final version of Joiku will include WEP/WPA/WPA2 encryption. Hopefully all over 15.000 users who have downloaded Joiku will update when final version is available!

Update 25.2.2008

Just caught my mind that this same security hole applies also if somebody has Mobile VPN installed and connection opened from terminal to enterprise back-end systems. Then Joiku will publish this connection to everybody who is close enough, right? At the moment I don't have a VPN enabled device to verify this, but I can't see any reason why this wouldn't work. Scary.

//Harri