(949) 777-6959

Blog
Home > The Attack on Mat Honan’s “iCloud Account” – And How SecureAuth Can Prevent
Free Trial

The Attack on Mat Honan’s “iCloud Account” – And How SecureAuth Can Prevent

Written on August 12, 2012 at 4:06 pm, by Garret

Lots of writing’s on the account victimization occurred by Mat Honan‘s (Wired Tech Writer) – specifically his iCloud account. (Here is Mat Honan’s original article and a good summary article, of the details, by CNN Money.)

This SecureAuth article is structured in the following manner:

1) The “iCloud Hack” of Matt Honan’s account
2) Key Take-Aways of Attack – An Enterprise IT Perspective
3) SecureAuth IdP Allows Enterprise to retain “Keys to Kingdom” for Cloud Access
4) Details of How SecureAuth IdP could mitigate the Mat Honan account hack

1) The “iCloud Hack” of Mat Honan’s account

In essence it was a well-executed social-engineering hack,leveraging a 3rd Party user databstore (Amazon) to obtain information used to attack and reset the TARGET user datastore: (Apple iCloud).

Key steps in the attack:

Image #1: This step-by-step process reveals how cloud IdPs (in this case Amazon and Apple) can be manipulated into accommodating identity fraud.

2) Key Take-Aways of Attack – An Enterprise IT Perspective

The key take-aways for enterprise IT is:

The weakness in cloud Identity Providers (IdPs)

Important: – This is NOT saying that the wonderful services provided by Google, Salesforce, SuccessFactors, Workday, Taleo, WebEx, ADP and others – should NOT be utilized. These cloud resources are often, because of their technical and business model, superior offerings to their on-premise counterparts.

What is true for an enterprise who has obligations on identities:

e.g. PCI DSS, NCUA, FFIEC, HIPAA/HITECH, Pharmaceuticals

These enterprises must:

Retain the “Keys to the kingdom”:
1. Retain the identities (ID/Passwords)
2. Conduct the Authentication (ID/Password, 2-Factor, AD-SSO, etc)
3. Federate the Identitiy
4. Log the Access

Please see image #2 for the proper infrastructure model for enterprises deploying SaaS resources.

Image #2: An enterprise needs to retain the “keys to the kingdom” by (1) Retaining the identites (2) Conducting the authentication (3) Federating the identity and (4) Logging the Access for secure cloud usage.

3) SecureAuth IdP Allows Enteprises to Retain “Keys to Kingdom” for Cloud Access

The key to AVOIDING a Matt Honan type “iCloud Hack” is to retain the cloud credentials (the “keys to the kingdom”) and then federate the login to the SaaS provider. In the SecureAuth IdP model:

The passwords are NOT stored in the cloud
Thus the passwords are never STOLEN from the cloud

It’s really that simple: it’s called “Cloud Infrastructure,” and it’s what the DoD has just mandated in its deployments.

SecureAuth allows the enterprise to:

Accept Identity from Local Store (AD, LDAP, SQL, ODBC, REST)
Authenticate Accordingly:
- Internal: AD SSO
- External: 2-Factor, SMS, Telephony, X.509, Yubikey, Help Desk , CAC/PIV, KBA, PIN
Assert to the SaaS provider
- SAML, OpenID, OpenID Connect, OAUTH
Audit user locally

Please see Image #3 for how SecureAuth allows an enterprise to retain identities and avoid Matt Honan type attacks:

Image #3: SecureAuth IdP becomes the the “Identity Provider” for the enterprise – providing secure access to the cloud resources without synching the password to those cloud resources.

4) Details of How SecureAuth IdP could mitigate the Mat Honan attack

A consensus among security experts is, the attacker was able to obtain the relevant information to “fake out” the Amazon and Apple help desks because:

The identity information was stored at too many locales
The identity information was too easily obtained through social methods
Password reset was conducted through easily-penetrable (human) methods

#1 SecureAuth IdP allows an enterprise to centralize identity information

Because SecureAuth IdP conducts BOTH authentication and federation from a single data store, without replicating user data, SecureAuth IdP mitigates the problem Matt Honan experienced with his data being stored at multiple locations; and thus, being used against him.

This propagation of identity data should throw up red flags to an IT enterprise security admin. Any solution that claims security, but moves identities and credentials off premise is a security risk. (See image #4)

Image #4: SecureAuth IdP utilizes the enterprise-controlled datastore for authentication and federation of the enterprise controlled identity- to ensure that user credentials are not manipulated in the cloud.

#2 SecureAuth IdP uses data and mechanisms not easily “foiled” through social hacking methods

The “Mat Honan” cloud attack was premised on the attacker “proving” his identity to the respective Amazon (the affiliate) and Apple (the target) help desk via discovery of weak identity information.

SecureAuth IdP’s model is NOT based on weak, “socially obtained” authentication information. The SecureAuth IdP solution employs a secure Out-of-Band authentication system that features Telephony and SMS services to deliver a 1-time password that the user will use to identify himself- anywhere in the world.

And the information is NOT pulled from cloud IdPs which can be hacked via sociallyengineered mechanisms. Instead the identity information is pulled from ENTERPRISE controlled data. E.G. the “Keys to the Kingdom” are kept under the secure domain and control of the enterprise.

SecureAuth IdP supports the following 2-Factor authentication methods:

SMS One-Time-Registration codes
Telephony One-Time-Registration codes
E-mail One-Time-Registration codes
X.509 Validation
CAC/PIV identity cards
Yubikey
KBA/KBQ – based on enterprise held information
Help Desk Authentication
Kerberos/IWA (AD-SSO Auth)

Image #5: SecureAuth IdP has multiple types of authentication ingrained into its authentication workflow and federation to cloud sources.

#3. SecureAuth IdP Automates Password Reset with quantifiable 2-Factor mechanisms.

One of the recognized problems of the Matt Honan attack was the human element utilizing socially obtained information.

SecureAuth IdP addresses this Security flaw with a built-in, 2-Factor password reset mechanism that is automated. It has selectable web pages, which can be referenced via a URL on the enterprise portal. Upon invocation of the user, the user is stepped through a 2-factor authentication based on information in the enterprise directory (AD and others)

E-mail addresses (up to 4 different e-mail addresses)
SMS phone #’s (up to 4 different phone numbers)
Telephony phone #’s (up to 4 different phone numbers)
KBA/KBQ
Static PIN

In addition, SecureAuth IdP can force the user to provide other security measures before changing password, including:

X.509 Certificates
CAC/PIV Cards
Yubikey
Kerberos/IWA (forcing a password reset when domain connected)

Please see a sample of the integrated password reset, image #4.

Image #4: SecureAuth IdP has built-in 2-Factor password that is automated and based on information store and managed by the enterprise.

———————————————————————————————–

To learn more you can download this whitepaper , listen to this webinar or you can just contact us. we will tell you more.

All the best!

—

Garret Grajek is CTO and a co-founder of SecureAuth. SecureAuth is a single appliance solution that delivers configurable 2-Factor and SSO authentication for Web, VPN and SaaS based solutions.

Comments: 1 l Leave a Comment

Categories: Blog

Author: Garret

One thought on “The Attack on Mat Honan’s “iCloud Account” – And How SecureAuth Can Prevent”

Kelly on August 14, 2012 at 9:38 pm said:

Garret, how do you deal with Authentication with Mobile Apps on a device though? For example, those that require a Google username and password – like the Google Drive App. Google doesn’t provide Delegated Authentication like Salesforce, so how do we get around that without breaking the rule of don’t give the cloud provider your usernames and passwords?

Reply ↓