Hi,
Today after logging on to LinkedIn, I was greeted with a new screen I found rather worrying. It is commonplace for services like LinkedIn and Facebook to scan through your address book, and ask for credentials to do so (which is rather concerning already), but a new option has popped up:
This is asking for your work username and password. No 3rd party should be asking for corporate credentials like this, even more so a company that’s been hacked before http://www.pcworld.com/article/257045/6_5m_linkedin_passwords_posted_online_after_apparent_hack.html . I tried this with a test account, entering the username and temporary password. It then asked for further information, which was the address for the Outlook webmail link and then connected and started showing contacts.
LinkedIn on this page says “We’ll import your address book to suggest connections and help you manage your contacts. And we won’t store your password or email anyone without your permission.” which is a start, but it’s just such a bad practise to get into, and encouraging people to do this is irresponsible of LinkedIn in my opinion. On top of this, it’s providing an easy mechanism for staff to mass extract their contacts outside the company, which many companies frown upon or even have strict policies in place.
You can’t stop people from entering in these details of course, but you can block the connection from working at the Exchange end, as long as you have at least Exchange 2010 SP1.
There are a few settings to check. First, under the Set-OrganizationConfig area, you’ll need to check that EwsApplicationAccessPolicy is set to ‘EnforceBlockList’. If it’s not, it’s going to be “EnforceAllowList” and you’re probably OK, as it’s using a whitelist for access to only what’s listed rather than a blacklist, to only block what’s listed.
Next, you need to add LinkedIn into the BlockList. This is done with the command “Set-OrganizationConfig -EwsBlockList LinkedInEWS”
How do we know it’s the string “LinkedInEWS” to block? The IIS log files from Exchange will reveal this. After doing your test of trying LinkedIn (or any other Exchange Web Services connection) there will be a log entry. You can read this blog post from Microsoft for some great details http://blogs.technet.com/b/matabra/archive/2012/08/23/block-mobile-apps-that-use-exchange-web-services.aspx but the abbreviated version is to look at what’s connecting fir POST /EWS/Exchange.asmx, and you’ll see the username you used to test, then the named connection. Here’s an example (with domain, username and IP changed):
2013-06-02 10:37:48 192.1.1.135 POST /EWS/Exchange.asmx – 443 domain\testusername 192.168.1.1 LinkedInEWS+(ExchangeServicesClient/0.0.0.0) 200 0 0 296
After applying, I retested and it seemed to still connect, but couldn’t find any contacts. My guess is that it’s authenticating OK, but then refusing to do much else. If anyone else would like to test this and post the results, I’d be very happy to find out update this.
Funnily enough, after writing this I found that LinkedIn had posted a very short version of the above:
From: http://help.linkedin.com/app/answers/detail/a_id/5025
Disabling Contact Import Process – Corporate IT Managers Instructions
How do I disable the ability for employees at my company to import contacts from their work email account?
If you’re a Corporate IT manager, you can disable an employee’s ability to import contacts from their work email accounts.
Use Set-OrganizationConfig cmdlet to:
- Set the value of config parameter EwsApplicationAccessPolicy to EnforceBlockList.
- Add value LinkedInEWS to config parameter EwsBlockList.
For more information on using Set-OrganizationConfig cmdlet, please refer to Microsoft’s Managing Access for EWS Managed API Applications.
Further reading is available here:
http://thoughtsofanidlemind.wordpress.com/2010/08/12/controlling-ews-access-in-exchange-2010-sp1/
Update:
Paul Cunningham has done a great writeup about this with some extra investigation and details, have a read: http://exchangeserverpro.com/blocking-linkedin-access-to-your-exchange-server-organization/
Update 2:
This story had now been picked up by The Register, have a read here: http://www.theregister.co.uk/2013/06/06/linkedin_snarfing_contacts_from_exchange/
Update 3:
Seems to be getting picked up all over the place, so I’ll just keep updating this point as I find other articles. There’s some good discussion and opinions on this out there, such as why is Exchange configured to allow everything by default?
http://securencrypt.com/blog/linkedin-has-major-privacy-issue/
http://webwereld.nl/beveiliging/78036-linkedin-slurpt-data-van-zakelijke-exchange-servers
So, what about Exchange 2007?
Perfect way for DOS – change your password and LinkedIn may lock you out …
Thanks for this helpful post.
So this will form a huge challenge for those customers that have moved to Office365 or a sortlike offering, where control over settings like these are not available to the customer.
I have two Exchange 2010 SP2 Ru6 environments and have attempted to block the LinkedInEWS application but it is still connecting and is able to pull new added contacts from the Exchange environment. This is a test environment so I rebooted all of the CAS servers in the one environment, still could pull the contacts. Anyone get it to successfully block? Is there any log entry that it did block it?
I haven’t been able to find this out either. After trying when blocked, the log file I referred to shows the same information. Hoping someone can answer this for us.
Hello,
Same here. I still can access the contacts of my test-user.
Did anybody get it working?
Regards,
Ron
I’d suggest taking the discussion over here: http://exchangeserverpro.com/blocking-linkedin-access-to-your-exchange-server-organization/#comment-19131
I’ll add in my 2c there, but there will be a lot more Exchange pros to ask this.
You may also want to look at iqtell.com which stores your exchange username and password on their server so it can synchronize your email, calendar and contacts to their server.
That’s rather worrying. Haven’t heard of that one, but just goes to show that having a whitelist approach is probably safer than a blacklist. The problem still is someone giving their enterprise credentials to a 3rd party which you can’t stop, only have policies and announcements.