API Security

It’s Complicated.@dberlind

Disclaimers• I don’t necessarily have all the answers. I can and will make some

recommendations. But ultimately, I’m a journalist. I interview people. I make observations. This presentation comes from those interviews and observations.

• I think I’m pretty up to date. But, there may be new observations or information that make some of my information obsolete. It’s a huge ocean to boil.

• Despite what I’m about to share with you, I do not consider myself a security expert. There may be some technical inaccuracies.

• This presentation only scratches the surface. But it’s a good conversation starter

• By the end, you may think the Internet is doomed. It could be. Unless you do something about it.

• I’m terrible at PowerPoint

Anatomies of Recent API-related Attacks

Anatomy of Attack

Anatomy of Attack

• 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints

Anatomy of Attack• 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints• Oct-2013

• Hackers get busy “reverse engineering” passwords

Anatomy of Attack

Anatomy of Attack• 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints• Oct-2013

• Hackers get busy “reverse engineering” passwords• Hackers target Github accounts of Buffer’s developers

Anatomy of Attack• 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints• Oct-2013

• Hackers get busy “reverse engineering” passwords• Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code repository through shared passwords

Anatomy of Attack• 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints• Oct-2013

• Hackers get busy “reverse engineering” passwords• Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code repository through shared passwords• From source code, hackers discover Buffer’s API keys for Twitter and Facebook

Anatomy of Attack• 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints• Oct-2013

• Hackers get busy “reverse engineering” passwords• Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code respository through shared passwords• From source code, hackers discover Buffer’s API keys for Twitter and Facebook• Hackers target MongoHQ tech support personnel through shared passwords

Anatomy of Attack• 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints• Oct-2013

• Hackers get busy “reverse engineering” passwords• Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code repository through shared passwords• From source code, hackers discover Buffer’s API keys for Twitter and Facebook• Hackers target MongoHQ tech support personnel through shared passwords• Hackers gain access to MongoHQ tech support app which has access to Buffer’s data

Anatomy of Attack• 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints• Oct-2013

• Hackers get busy “reverse engineering” passwords• Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code repository through shared passwords• From source code, hackers discover Buffer’s API keys for Twitter and Facebook• Hackers target MongoHQ tech support personnel through shared passwords• Hackers gain access to MongoHQ tech support app which has access to Buffer’s data• Via MongoHQ’s tech support app, hackers find Buffer’s users’ OAuth tokens for

Twitter, Facebook, probably develop ScrAPI to harvest them 1000 records per screen

Anatomy of Attack• 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints• Oct-2013

• Hackers get busy “reverse engineering” passwords• Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code respository through shared passwords• From source code, hackers discover Buffer’s API keys for Twitter and Facebook• Hackers target MongoHQ tech support personnel through shared passwords• Hackers gain access to MongoHQ tech support app which has access to Buffer’s data• Via MongoHQ’s tech support app, hackers find Buffer’s users’ OAuth tokens for

Twitter, Facebook, probably develop ScrAPI to harvest them 1000 records per screen• Hackers develop code that can pose as Buffer and cycle through all the tokens making

posts to Facebook and Twitter via API.

Anatomy of Attack• 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints• Oct-2013

• Hackers get busy “reverse engineering” passwords• Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code repository through shared passwords• From source code, hackers discover Buffer’s API keys for Twitter and Facebook• Hackers target MongoHQ tech support personnel through shared passwords• Hackers gain access to MongoHQ tech support app which has access to Buffer’s data• Via MongoHQ’s tech support app, hackers find Buffer’s users’ OAuth tokens for

Twitter, Facebook, probably develop ScrAPI to harvest them 1000 records per screen• Hackers develop code that can pose as Buffer and cycle through all the tokens making

posts to Facebook and Twitter via API. • 26-Oct-2013

• Adobe Database published on AnonNews.org

Anatomy of Attack• 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints• Oct-2013

• Hackers get busy “reverse engineering” passwords• Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code respository through shared passwords• From source code, hackers discover Buffer’s API keys for Twitter and Facebook• Hackers target MongoHQ tech support personnel through shared passwords• Hackers gain access to MongoHQ tech support app which has access to Buffer’s data• Via MongoHQ’s tech support app, hackers find Buffer’s users’ OAuth tokens for

Twitter, Facebook, probably develop ScrAPI to harvest them 1000 records per screen• Hackers develop code that can pose as Buffer and cycle through all the tokens making

posts to Facebook and Twitter via API. • 26-Oct-2013

• Database published on AnonNews.org• Tens of thousands of Twitter/Facebook accounts spammed with weight-loss posts

Example of Attack

Anatomy of Attack• 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints• Oct-2013

• Hackers get busy “reverse engineering” passwords• Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code repository through shared passwords• From source code, hackers discover Buffer’s API keys for Twitter and Facebook• Hackers target MongoHQ tech support personnel through shared passwords• Hackers gain access to MongoHQ tech support app which has access to Buffer’s data• Via MongoHQ’s tech support app, hackers find Buffer’s users’ OAuth tokens for

Twitter, Facebook, probably develop ScrAPI to harvest them 1000 records per screen• Hackers develop code that can pose as Buffer and cycle through all the tokens making

posts to Facebook and Twitter via API. • 26-Oct-2013

• Database published on AnonNews.org• Tens of thousands of Twitter/Facebook accounts spammed with weight-loss posts• More than likely malware, but too late to know

Anatomy of Attack• 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints• Oct-2013

• Hackers get busy “reverse engineering” passwords• Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code repository through shared passwords• From source code, hackers discover Buffer’s API keys for Twitter and Facebook• Hackers target MongoHQ tech support personnel through shared passwords• Hackers gain access to MongoHQ tech support app which has access to Buffer’s data• Via MongoHQ’s tech support app, hackers find Buffer’s users’ OAuth tokens for

Twitter, Facebook, probably develop ScrAPI to harvest them 1000 records per screen• Hackers develop code that can pose as Buffer and cycle through all the tokens making

posts to Facebook and Twitter via API. • 26-Oct-2013

• Database published on AnonNews.org• Tens of thousands of Twitter/Facebook accounts spammed with weight-loss posts• More than likely malware, but too late to know• Buffer discloses

Anatomy of Attack• 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints• Oct-2013

• Hackers get busy “reverse engineering” passwords• Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code repository through shared passwords• From source code, hackers discover Buffer’s API keys for Twitter and Facebook• Hackers target MongoHQ tech support personnel through shared passwords• Hackers gain access to MongoHQ tech support app which has access to Buffer’s data• Via MongoHQ’s tech support app, hackers find Buffer’s users’ OAuth tokens for

Twitter, Facebook, probably develop ScrAPI to harvest them 1000 records per screen• Hackers develop code that can pose as Buffer and cycle through all the tokens making

posts to Facebook and Twitter via API. • 26-Oct-2013

• Database published on AnonNews.org• Tens of thousands of Twitter/Facebook accounts spammed with weight-loss posts• More than likely malware, but too late to know• Buffer discloses• MongoHQ discloses (not as much)

Anatomy of Attack• 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints• Oct-2013

• Hackers get busy “reverse engineering” passwords• Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code respository through shared passwords• From source code, hackers discover Buffer’s API keys for Twitter and Facebook• Hackers target MongoHQ tech support personnel through shared passwords• Hackers gain access to MongoHQ tech support app which has access to Buffer’s data• Via MongoHQ’s tech support app, hackers find Buffer’s users’ OAuth tokens for

Twitter, Facebook, probably develop ScrAPI to harvest them 1000 records per screen• Hackers develop code that can pose as Buffer and cycle through all the tokens making

posts to Facebook and Twitter via API. • 26-Oct-2013

• Database published on AnonNews.org• Tens of thousands of Twitter/Facebook accounts spammed with weight-loss posts• More than likely malware, but too late to know• Buffer discloses• MongoHQ discloses (not as much)

• Nov-2013: Adobe sends out password reset emails

Adobe Password Reset Email

Other facts and notes● Hackers also looked for Buffer’s AWS credentials on Github

Other facts and notes● Hackers also looked for AWS credentials on Github● IP address in common across access of GitHub, MongoHQ, and Buffer… the Buffer

logs showed the Twitter account associated with the IP address.. that account known to be associated with Anonymous.

Other facts and notes● Hackers also looked for AWS credentials on Github● IP address in common across access of GitHub, MongoHQ, and Buffer… the Buffer

logs showed the Twitter account associated with the IP address.. that account known to be associated with Anonymous.

● That twitter account also tweeted a question about thwarting security after Buffer moved to Google-based Two-Factor Authentication on Github

Other facts and notes● Hackers also looked for AWS credentials on Github● IP address in common across access of GitHub, MongoHQ, and Buffer… the Buffer

logs showed the Twitter account associated with the IP address.. that account known to be associated with Anonymous.

● That twitter account also tweeted a question about thwarting security after Buffer moved to Google-based Two-Factor Authentication on Github

● Other companies hacked due to Mongo breach: Sunrise Calender

Other facts and notes● Hackers also looked for AWS credentials on Github● IP address in common across access of GitHub, MongoHQ, and Buffer… the Buffer

logs showed the Twitter account associated with the IP address.. that account known to be associated with Twitter.

● That twitter account also tweeted a question about thwarting security after Buffer moved to Google-based Two-Factor Authentication on Github

● Other companies hacked due to Mongo breach: Sunrise Calender● Could have been much worse: Buffer had Stripe credentials in their code as well.

Hacker could have charged charges to Buffer’s customers.

Other facts and notes● Hackers also looked for AWS credentials on Github● IP address in common across access of GitHub, MongoHQ, and Buffer… the Buffer

logs showed the Twitter account associated with the IP address.. that account known to be associated with Twitter.

● That twitter account also tweeted a question about thwarting security after Buffer moved to Google-based Two-Factor Authentication on Github

● Other companies hacked due to Mongo breach: Sunrise Calender● Could have been much worse: Buffer had Stripe credentials in their code as well.

Hacker could have charged charges to Buffer’s customers.● Able to identify incursions on Github by IP address (didn’t belong to anybody on

the team).

Other facts and notes● Hackers also looked for AWS credentials on Github● IP address in common across access of GitHub, MongoHQ, and Buffer… the Buffer

logs showed the Twitter account associated with the IP address.. that account known to be associated with Twitter.

● That twitter account also tweeted a question about thwarting security after Buffer moved to Google-based Two-Factor Authentication on Github

● Other companies hacked due to Mongo breach: Sunrise Calender● Could have been much worse: Buffer had Stripe credentials in their code as well.

Hacker could have charged charges to Buffer’s customers.● Able to identify incursions on Github by IP address (didn’t belong to anybody on

the team).● Buffer moved to Google-based 2FA across other services. But many of those

services (eg: Dropbox) offer no way of managing that (eg: no enforcement.. You have to trust employees).

Other facts and notes● Hackers also looked for AWS credentials on Github● IP address in common across access of GitHub, MongoHQ, and Buffer… the Buffer

logs showed the Twitter account associated with the IP address.. that account known to be associated with Twitter.

● That twitter account also tweeted a question about thwarting security after Buffer moved to Google-based Two-Factor Authentication on Github

● Other companies hacked due to Mongo breach: Sunrise Calender● Could have been much worse: Buffer had Stripe credentials in their code as well.

Hacker could have charged charges to Buffer’s customers.● Able to identify incursions on Github by IP address (didn’t belong to anybody on

the team).● Buffer moved to Google-based 2FA across other services. But many of those

services (eg: Dropbox) offer no way of managing that (eg: no enforcement.. You have to trust employees).

● Another issue: How do you store credentials that admins must share? Put them on Dropbox where you lack enterprise controls?

Pinterest Auto-Post Preference

The “Fappening”(Not All Details Confirmed By Apple)

• Apple’s “cloud” (everything from iTunes to iCloud) relies on one Apple ID and password per user• Allegedly involved the undocumented Find My iPhone API (FMI API) – undocumented APIs are

easy to reverse engineer• FMI API required only user name and password for authentication (no other forms of

authentication like OAuth tokens)• FMI API had no rate limiting on it, allowing for an infinite number of attempts or what is

otherwise known in security circles as a brute force attack.• Just needed a bit of code that loops and loops and loops• They called that bit of code iBrute and published it to Github• For passwords, hackers allegedly used the infamous RockYou database; a big sample listing the

passwords for 14 million accounts that were compromised when the social gaming service was compromised in 2009

• Once the passwords were discovered, they used Elcomsoft Phone Password Breaker (EPPB) to handle the bulk downloads and from there the photos are being published.

• Within hours, Apple installed rate limiting on the API.• The phishing attacks preying on the media-induced fear started almost immediately• Apple claimed:

– There was no breach of its systems– The hackers gained access through phishing or answering password recovery questions (but that involves rate

limiting, no?) on targeted accounts– Advised all users to activate its two factor authentication (already known not to protect all entry points into the

Apple kingdom)

The “Fappening”(Not All Details Confirmed By Apple)

• Apple’s “cloud” (everything from iTunes to iCloud) relies on one Apple ID and password per user• Allegedly involved the undocumented Find My iPhone API (FMI API) – undocumented APIs are

easy to reverse engineer• FMI API required only user name and password for authentication (no other forms of

authentication like OAuth tokens)• FMI API had no rate limiting on it, allowing for an infinite number of attempts or what is

otherwise known in security circles as a brute force attack.• Just needed a bit of code that loops and loops and loops• They called that bit of code iBrute and published it to Github• For passwords, hackers allegedly used the infamous RockYou database; a big sample listing the

passwords for 14 million accounts that were compromised when the social gaming service was compromised in 2009

• Once the passwords were discovered, they used Elcomsoft Phone Password Breaker (EPPB) to handle the bulk downloads and from there the photos are being published.

• Within hours, Apple installed rate limiting on the API.• The phishing attacks preying on the media-induced fear started almost immediately• Apple claimed:

– There was no breach of its systems– The hackers gained access through phishing or answering password recovery questions (but that involves rate

limiting, no?) on targeted accounts– Advised all users to activate its two factor authentication (already known not to protect all entry points into the

Apple kingdom)

The “Fappening”(Not All Details Confirmed By Apple)

• Apple’s “cloud” (everything from iTunes to iCloud) relies on one Apple ID and password per user• Allegedly involved the undocumented Find My iPhone API (FMI API) – undocumented APIs are

easy to reverse engineer• FMI API required only user name and password for authentication (no other forms of

authentication like OAuth tokens)• FMI API had no rate limiting on it, allowing for an infinite number of attempts or what is

otherwise known in security circles as a brute force attack.• Just needed a bit of code that loops and loops and loops• They called that bit of code iBrute and published it to Github• For passwords, hackers allegedly used the infamous RockYou database; a big sample listing the

passwords for 14 million accounts that were compromised when the social gaming service was compromised in 2009

• Once the passwords were discovered, they used Elcomsoft Phone Password Breaker (EPPB) to handle the bulk downloads and from there the photos are being published.

• Within hours, Apple installed rate limiting on the API.• The phishing attacks preying on the media-induced fear started almost immediately• Apple claimed:

– There was no breach of its systems– The hackers gained access through phishing or answering password recovery questions (but that involves rate

limiting, no?) on targeted accounts– Advised all users to activate its two factor authentication (already known not to protect all entry points into the

Apple kingdom)

The “Fappening”(Not All Details Confirmed By Apple)

• Apple’s “cloud” (everything from iTunes to iCloud) relies on one Apple ID and password per user• Allegedly involved the undocumented Find My iPhone API (FMI API) – undocumented APIs are

easy to reverse engineer• FMI API required only user name and password for authentication (no other forms of

authentication like OAuth tokens)• FMI API had no rate limiting on it, allowing for an infinite number of attempts or what is

otherwise known in security circles as a brute force attack.• Just needed a bit of code that loops and loops and loops• They called that bit of code iBrute and published it to Github• For passwords, hackers allegedly used the infamous RockYou database; a big sample listing the

passwords for 14 million accounts that were compromised when the social gaming service was compromised in 2009

• Once the passwords were discovered, they used Elcomsoft Phone Password Breaker (EPPB) to handle the bulk downloads and from there the photos are being published.

• Within hours, Apple installed rate limiting on the API.• The phishing attacks preying on the media-induced fear started almost immediately• Apple claimed:

– There was no breach of its systems– The hackers gained access through phishing or answering password recovery questions (but that involves rate

limiting, no?) on targeted accounts– Advised all users to activate its two factor authentication (already known not to protect all entry points into the

Apple kingdom)

The “Fappening”(Not All Details Confirmed By Apple)

• Apple’s “cloud” (everything from iTunes to iCloud) relies on one Apple ID and password per user• Allegedly involved the undocumented Find My iPhone API (FMI API) – undocumented APIs are

easy to reverse engineer• FMI API required only user name and password for authentication (no other forms of

authentication like OAuth tokens)• FMI API had no rate limiting on it, allowing for an infinite number of attempts or what is

otherwise known in security circles as a brute force attack.• Just needed a bit of code that loops and loops and loops• They called that bit of code iBrute and published it to Github• For passwords, hackers allegedly used the infamous RockYou database; a big sample listing the

passwords for 14 million accounts that were compromised when the social gaming service was compromised in 2009

• Once the passwords were discovered, they used Elcomsoft Phone Password Breaker (EPPB) to handle the bulk downloads and from there the photos are being published.

• Within hours, Apple installed rate limiting on the API.• The phishing attacks preying on the media-induced fear started almost immediately• Apple claimed:

– There was no breach of its systems– The hackers gained access through phishing or answering password recovery questions (but that involves rate

limiting, no?) on targeted accounts– Advised all users to activate its two factor authentication (already known not to protect all entry points into the

Apple kingdom)

The “Fappening”(Not All Details Confirmed By Apple)

• Apple’s “cloud” (everything from iTunes to iCloud) relies on one Apple ID and password per user• Allegedly involved the undocumented Find My iPhone API (FMI API) – undocumented APIs are

easy to reverse engineer• FMI API required only user name and password for authentication (no other forms of

authentication like OAuth tokens)• FMI API had no rate limiting on it, allowing for an infinite number of attempts or what is

otherwise known in security circles as a brute force attack.• Just needed a bit of code that loops and loops and loops• They called that bit of code iBrute and published it to Github• For passwords, hackers allegedly used the infamous RockYou database; a big sample listing the

passwords for 14 million accounts that were compromised when the social gaming service was compromised in 2009

• Once the passwords were discovered, they used Elcomsoft Phone Password Breaker (EPPB) to handle the bulk downloads and from there the photos are being published.

• Within hours, Apple installed rate limiting on the API.• The phishing attacks preying on the media-induced fear started almost immediately• Apple claimed:

– There was no breach of its systems– The hackers gained access through phishing or answering password recovery questions (but that involves rate

limiting, no?) on targeted accounts– Advised all users to activate its two factor authentication (already known not to protect all entry points into the

Apple kingdom)

Source Code to iBrute on Github

The “Fappening”(Not All Details Confirmed By Apple)

• Apple’s “cloud” (everything from iTunes to iCloud) relies on one Apple ID and password per user• Allegedly involved the undocumented Find My iPhone API (FMI API) – undocumented APIs are

easy to reverse engineer• FMI API required only user name and password for authentication (no other forms of

authentication like OAuth tokens)• FMI API had no rate limiting on it, allowing for an infinite number of attempts or what is

otherwise known in security circles as a brute force attack.• Just needed a bit of code that loops and loops and loops• They called that bit of code iBrute and published it to Github• For passwords, hackers allegedly used the infamous RockYou database; a big sample listing the

passwords for 30M accounts that were compromised when that social gaming service was compromised in 2009

• Once the passwords were discovered, they used Elcomsoft Phone Password Breaker (EPPB) to handle the bulk downloads and from there the photos are being published.

• Within hours, Apple installed rate limiting on the API.• The phishing attacks preying on the media-induced fear started almost immediately• Apple claimed:

– There was no breach of its systems– The hackers gained access through phishing or answering password recovery questions (but that involves rate

limiting, no?) on targeted accounts– Advised all users to activate its two factor authentication (already known not to protect all entry points into the

Apple kingdom)

The “Fappening”(Not All Details Confirmed By Apple)

• Apple’s “cloud” (everything from iTunes to iCloud) relies on one Apple ID and password per user• Allegedly involved the undocumented Find My iPhone API (FMI API) – undocumented APIs are

easy to reverse engineer• FMI API required only user name and password for authentication (no other forms of

authentication like OAuth tokens)• FMI API had no rate limiting on it, allowing for an infinite number of attempts or what is

otherwise known in security circles as a brute force attack.• Just needed a bit of code that loops and loops and loops• They called that bit of code iBrute and published it to Github• For passwords, hackers allegedly used the infamous RockYou database; a big sample listing the

passwords for 30M accounts that were compromised when the social gaming service was compromised in 2009

• Once the passwords were discovered, they used Elcomsoft Phone Password Breaker (EPPB) to handle the bulk downloads and from there the photos are being published.

• Within hours, Apple installed rate limiting on the API.• The phishing attacks preying on the media-induced fear started almost immediately• Apple claimed:

– There was no breach of its systems– The hackers gained access through phishing or answering password recovery questions (but that involves rate

limiting, no?) on targeted accounts– Advised all users to activate its two factor authentication (already known not to protect all entry points into the

Apple kingdom)

The “Fappening”(Not All Details Confirmed By Apple)

• Apple’s “cloud” (everything from iTunes to iCloud) relies on one Apple ID and password per user• Allegedly involved the undocumented Find My iPhone API (FMI API) – undocumented APIs are

easy to reverse engineer• FMI API required only user name and password for authentication (no other forms of

authentication like OAuth tokens)• FMI API had no rate limiting on it, allowing for an infinite number of attempts or what is

otherwise known in security circles as a brute force attack.• Just needed a bit of code that loops and loops and loops• They called that bit of code iBrute and published it to Github• For passwords, hackers allegedly used the infamous RockYou database; a big sample listing the

passwords for 30M accounts that were compromised when the social gaming service was compromised in 2009

• Once the passwords were discovered, they used Elcomsoft Phone Password Breaker (EPPB) to handle the bulk downloads and from there the photos are being published.

• Within hours, Apple installed rate limiting on the API.• The phishing attacks preying on the media-induced fear started almost immediately• Apple claimed:

– There was no breach of its systems– The hackers gained access through phishing or answering password recovery questions (but that involves rate

limiting, no?) on targeted accounts– Advised all users to activate its two factor authentication (already known not to protect all entry points into the

Apple kingdom)

The “Fappening”(Not All Details Confirmed By Apple)

• Apple’s “cloud” (everything from iTunes to iCloud) relies on one Apple ID and password per user• Allegedly involved the undocumented Find My iPhone API (FMI API) – undocumented APIs are

easy to reverse engineer• FMI API required only user name and password for authentication (no other forms of

authentication like OAuth tokens)• FMI API had no rate limiting on it, allowing for an infinite number of attempts or what is

otherwise known in security circles as a brute force attack.• Just needed a bit of code that loops and loops and loops• They called that bit of code iBrute and published it to Github• For passwords, hackers allegedly used the infamous RockYou database; a big sample listing the

passwords for 30M accounts that were compromised when the social gaming service was compromised in 2009

• Once the passwords were discovered, they used Elcomsoft Phone Password Breaker (EPPB) to handle the bulk downloads and from there the photos are being published.

• Within hours, Apple installed rate limiting on the API.• The phishing attacks preying on the media-induced fear started almost immediately• Apple claimed:

– There was no breach of its systems– The hackers gained access through phishing or answering password recovery questions (but that involves rate

limiting, no?) on targeted accounts– Advised all users to activate its two factor authentication (already known not to protect all entry points into the

Apple kingdom)

The “Fappening”(Not All Details Confirmed By Apple)

• Apple’s “cloud” (everything from iTunes to iCloud) relies on one Apple ID and password per user• Allegedly involved the undocumented Find My iPhone API (FMI API) – undocumented APIs are

easy to reverse engineer• FMI API required only user name and password for authentication (no other forms of

authentication like OAuth tokens)• FMI API had no rate limiting on it, allowing for an infinite number of attempts or what is

otherwise known in security circles as a brute force attack.• Just needed a bit of code that loops and loops and loops• They called that bit of code iBrute and published it to Github• For passwords, hackers allegedly used the infamous RockYou database; a big sample listing the

passwords for 30M accounts that were compromised when the social gaming service was compromised in 2009

• Once the passwords were discovered, they used Elcomsoft Phone Password Breaker (EPPB) to handle the bulk downloads and from there the photos are being published.

• Within hours, Apple installed rate limiting on the API.• The phishing attacks preying on the media-induced fear started almost immediately• Apple claimed:

– There was no breach of its systems– The hackers gained access through phishing or answering password recovery questions (but that involves rate

limiting, no?) on targeted accounts– Advised all users to activate its two factor authentication (already known not to protect all entry points into the

Apple kingdom)

Common Breach Patterns• Hackers seek potential for scale (APIs are sitting ducks!)• Original transgression often targeted and undetected• Leverages trusted relationships (the downside of social nets)• Publication or black market sale of content• Publication of source code• Media coverage, useless expert advice• Official company disclosure (sometimes)• News goes viral on social media (usually negative)• Partners get sucked inn• Phishing attack (the second wave), invariably malware• Additional transgressions• Additional “publications”

Common Breach Patterns• Hackers seek potential for scale (APIs are sitting ducks!)• Original transgression often targeted and undetected• Leverages trusted relationships (the downside of social nets)• Publication or black market sale of content• Publication of source code• Media coverage, useless expert advice• Official company disclosure (sometimes)• News goes viral on social media (usually negative)• Partners get sucked inn• Phishing attack (the second wave), invariably malware• Additional transgressions• Additional “publications”

Common Breach Patterns• Hackers seek potential for scale (APIs are sitting ducks!)• Original transgression often targeted and undetected• Leverages trusted relationships (the downside of social nets)• Publication or black market sale of content• Publication of source code• Media coverage, useless expert advice• Official company disclosure (sometimes)• News goes viral on social media (usually negative)• Partners get sucked inn• Phishing attack (the second wave), invariably malware• Additional transgressions• Additional “publications”

Common Breach Patterns• Hackers seek potential for scale (APIs are sitting ducks!)• Original transgression often targeted and undetected• Leverages trusted relationships (the downside of social nets)• Publication or black market sale of content• Publication of source code• Media coverage, useless expert advice• Official company disclosure (sometimes)• News goes viral on social media (usually negative)• Partners get sucked inn• Phishing attack (the second wave), invariably malware• Additional transgressions• Additional “publications”

Common Breach Patterns• Hackers seek potential for scale (APIs are sitting ducks!)• Original transgression often targeted and undetected• Leverages trusted relationships (the downside of social nets)• Publication or black market sale of content• Publication of source code• Media coverage, useless expert advice• Official company disclosure (sometimes)• News goes viral on social media (usually negative)• Partners get sucked inn• Phishing attack (the second wave), invariably malware• Additional transgressions• Additional “publications”

Common Breach Patterns• Hackers seek potential for scale (APIs are sitting ducks!)• Original transgression often targeted and undetected• Leverages trusted relationships (the downside of social nets)• Publication or black market sale of content• Publication of source code• Media coverage, useless expert advice• Official company disclosure (sometimes)• News goes viral on social media (usually negative)• Partners get sucked inn• Phishing attack (the second wave), invariably malware• Additional transgressions• Additional “publications”

Common Breach Patterns• Hackers seek potential for scale (APIs are sitting ducks!)• Original transgression often targeted and undetected• Leverages trusted relationships (the downside of social nets)• Publication or black market sale of content• Publication of source code• Media coverage, useless expert advice• Official company disclosure (sometimes)• News goes viral on social media (usually negative)• Partners get sucked inn• Phishing attack (the second wave), invariably malware• Additional transgressions• Additional “publications”

Common Breach Patterns• Hackers seek potential for scale (APIs are sitting ducks!)• Original transgression often targeted and undetected• Leverages trusted relationships (the downside of social nets)• Publication or black market sale of content• Publication of source code• Media coverage, useless expert advice• Official company disclosure (sometimes)• News goes viral on social media (usually negative)• Partners get sucked inn• Phishing attack (the second wave), invariably malware• Additional transgressions• Additional “publications”

Common Breach Patterns• Hackers seek potential for scale (APIs are sitting ducks!)• Original transgression often targeted and undetected• Leverages trusted relationships (the downside of social nets)• Publication or black market sale of content• Publication of source code• Media coverage, useless expert advice• Official company disclosure (sometimes)• News goes viral on social media (usually negative)• Partners get sucked in• Phishing attack (the second wave), invariably malware• Additional transgressions• Additional “publications”

Common Breach Patterns• Hackers seek potential for scale (APIs are sitting ducks!)• Original transgression often targeted and undetected• Leverages trusted relationships (the downside of social nets)• Publication or black market sale of content• Publication of source code• Media coverage, useless expert advice• Official company disclosure (sometimes)• News goes viral on social media (usually negative)• Partners get sucked in• Phishing attack (the second wave), invariably malware• Additional transgressions• Additional “publications”

Common Breach Patterns• Hackers seek potential for scale (APIs are sitting ducks!)• Original transgression often targeted and undetected• Leverages trusted relationships (the downside of social nets)• Publication or black market sale of content• Publication of source code• Media coverage, useless expert advice• Official company disclosure (sometimes)• News goes viral on social media (usually negative)• Partners get sucked inn• Phishing attack (the second wave), invariably malware• Additional transgressions• Additional “publications”

Common Breach Patterns• Hackers seek potential for scale (APIs are sitting ducks!)• Original transgression often targeted and undetected• Leverages trusted relationships (the downside of social nets)• Publication or black market sale of content• Publication of source code• Media coverage, useless expert advice• Official company disclosure (sometimes)• News goes viral on social media (usually negative)• Partners get sucked inn• Phishing attack (the second wave), invariably malware• Additional transgressions• Additional “publications”

• Of those individuals, 38 percent said they no longer did business with the organization because of the data breach. A larger number, 46 percent, said they ‘advised friends and family to be careful of sharing data with the organization (Economist Intelligence Report).

• Possible account suspensions (eg: Twitter, etc.)• Loss of developer confidence• Micro financial impact (loss of revenues, customers, partners, costly reconciliation)• Legal financial impact (lawsuits, fines, etc.)• Meta financial Impact (on stock of company, upcoming public offering, or on entire

stock market)• Lives are forever changed• Business shutdown

Consequences of Breaches

• Of those individuals, 38 percent said they no longer did business with the organization because of the data breach. A larger number, 46 percent, said they ‘advised friends and family to be careful of sharing data with the organization (Economist Intelligence Report).

• Possible account suspensions (eg: Twitter, etc.)• Loss of developer confidence• Micro financial impact (loss of revenues, customers, partners, costly reconciliation)• Legal financial impact (lawsuits, fines, etc.)• Meta financial Impact (on stock of company, upcoming public offering, or on entire

stock market)• Lives are forever changed• Business shutdown

Consequences of Breaches

• Of those individuals, 38 percent said they no longer did business with the organization because of the data breach. A larger number, 46 percent, said they ‘advised friends and family to be careful of sharing data with the organization (Economist Intelligence Report).

• Possible account suspensions (eg: Twitter, etc.)• Loss of developer confidence• Micro financial impact (loss of revenues, customers, partners, costly reconciliation)• Legal financial impact (lawsuits, fines, etc.)• Meta financial Impact (on stock of company, upcoming public offering, or on entire

stock market)• Lives are forever changed• Business shutdown

Consequences of Breaches

• Of those individuals, 38 percent said they no longer did business with the organization because of the data breach. A larger number, 46 percent, said they ‘advised friends and family to be careful of sharing data with the organization (Economist Intelligence Report).

• Possible account suspensions (eg: Twitter, etc.)• Loss of developer confidence• Micro financial impact (loss of revenues, customers, partners, costly reconciliation)• Legal financial impact (lawsuits, fines, etc.)• Meta financial Impact (on stock of company, upcoming public offering, or on entire

stock market)• Lives are forever changed• Business shutdown

Consequences of Breaches

“Breaches due to malware or spyware represented only 11% by number of breaches in 2013 and 2014, but they have been increasing, with the total number of breaches in this category growing by 20% between 2013 and 2014. Due to heavy forensics costs (money spent to find out exactly how the breach occurred) these breaches are on average 4.5 times more costly than the largest loss category, unintended disclosure.” (source: Beazley)

Post Intrusion Costs (Malware)

* Malware is smallest group with biggest impact

• Of those individuals, 38 percent said they no longer did business with the organization because of the data breach. A larger number, 46 percent, said they ‘advised friends and family to be careful of sharing data with the organization (Economist Intelligence Report).

• Possible account suspensions (eg: Twitter, etc.)• Loss of developer confidence• Micro financial impact (loss of revenues, customers, partners, costly reconciliation)• Legal financial impact (lawsuits, fines, etc.)• Meta financial Impact (on stock of company, upcoming public offering, or on entire

stock market)• Lives are forever changed• Business shutdown

Consequences of Breaches

• Of those individuals, 38 percent said they no longer did business with the organization because of the data breach. A larger number, 46 percent, said they ‘advised friends and family to be careful of sharing data with the organization (Economist Intelligence Report).

• Possible account suspensions (eg: Twitter, etc.)• Loss of developer confidence• Micro financial impact (loss of revenues, customers, partners, costly reconciliation)• Legal financial impact (lawsuits, fines, etc.)• Meta financial Impact (on stock of company, upcoming public offering, or on entire

stock market)• Lives are forever changed• Business shutdown

Consequences of Breaches

1 Tweet Sends Dow Down By 140

• Of those individuals, 38 percent said they no longer did business with the organization because of the data breach. A larger number, 46 percent, said they ‘advised friends and family to be careful of sharing data with the organization (Economist Intelligence Report).

• Possible account suspensions (eg: Twitter, etc.)• Loss of developer confidence• Micro financial impact (loss of revenues, customers, partners, costly reconciliation)• Legal financial impact (lawsuits, fines, etc.)• Meta financial Impact (on stock of company, upcoming public offering, or on entire

stock market)• Lives are forever changed• Business shutdown

Consequences of Breaches

• Of those individuals, 38 percent said they no longer did business with the organization because of the data breach. A larger number, 46 percent, said they ‘advised friends and family to be careful of sharing data with the organization (Economist Intelligence Report).

• Possible account suspensions (eg: Twitter, etc.)• Loss of developer confidence• Micro financial impact (loss of revenues, customers, partners, costly reconciliation)• Legal financial impact (lawsuits, fines, etc.)• Meta financial Impact (on stock of company, upcoming public offering, or on entire

stock market)• Lives are forever changed• Business scuttled

Consequences of Breaches

• An Economist Intelligence Unit study conducted among consumers in 24 countries in March 2013 found that 18 percent of respondents had been a victim of a data breach (2014)

• Adobe: 150 million userIDs, email addresses, pwd hashes, password hints(2013)• eBay: 145 million userIDs, email addresses, pwd hashes, birthdates, addresses, first, last,

phone numbers, targeted eBay employees (2014)• RockYou: 30 million user IDs, Passwords (2009)• TJX: 90 million credit/debit cards• Target: 100 million credit/debit cards, PoS malware; “BlackPOS” a.k.a. Kaptoxa” (2013)• Home Depot: 56 million credit/debit cards, same (forked) malware as Target (2014)

Reaches of Breaches

Someone will build and publish a database that maps user IDs to actual people and all of their data (creating a bigger problem for shared passwords)

Eventually…

Malware Case Study: Pony BotNet

Malware Case Study: Pony BotNet

Pony summary stats

• A total of nearly 650,000 website credential stolen, with the top sites being:• ~90,000 credentials for Facebook accounts• ~25,000 credentials for Yahoo accounts• ~20,000 credentials for Google accounts

• And many more with lower individual numbers, but still amounting to the remaining 515,000 accounts

• Next in numbers were email accounts, with 17,000 compromised• And for the frosting on this credential cake are 7,000 stolen FTP

credentials.

Source: http://blog.spiderlabs.com/2013/06/look-what-i-found-its-a-pony-1.html

Fork of Pony

• Approximately 2MM total• ~1,580,000 website login credentials stolen• ~320,000 email account credentials stolen • ~41,000 FTP account credentials stolen• ~3,000 Remote Desktop credentials stolen• ~3,000 Secure Shell account credentials stolen

Source: http://blog.spiderlabs.com/2013/12/look-what-i-found-moar-pony.html

More recently

“Cyber criminals have also developed botnets that force enslaved computers to create, or "mine", digital currencies, which the fraudsters then claim as their own.”

http://www.reuters.com/article/2014/02/24/us-bitcoin-security-idUSBREA1N1JO20140224

Challenges in API Security(work that we, the API industry must do)

• Massive proliferation of APIs where security was after-thought or non-thought• User ID / password absurdity

– Shared passwords (really no solution)– Weak passwords– Discoverable Passwords– Horrendous Best Practices

• Non-uniform implementations of – App Secrets– Callback URLs

• Good security is expensive– Talent– Resources like HSM

• Administrative tools for key/OAuth management limited– Analytics– Revocation/Reissue

• Unknown possibilities for 2FA with APIs• Internet of Things• Standards still in the works• Disclosure / Collaboration

Challenges in API Security

"There are far too many APIs being cranked out in such a short period of time... there is no way that they have all been properly secured and built. There will definitely be new attack vectors in an API-centric Internet, but we are still too early to know the pervasiveness of such attacks." - Evident.io founder and former Adobe Creative Cloud Architecture & Security Team Lead Tim Prendergast (http://twitter.com/auxome)

Challenges in API Security(work that we, the API industry must do)

• Massive proliferation of APIs where security was after-thought or non-thought• User ID / password absurdity

– Shared passwords (really no solution)– Weak passwords– Discoverable Passwords– Horrendous Best Practices

• Non-uniform implementations of – App Secrets– Callback URLs

• Good security is expensive– Talent– Resources like HSM

• Administrative tools for key/OAuth management limited– Analytics– Revocation/Reissue

• Unknown possibilities for 2FA with APIs• Internet of Things• Standards still in the works• Disclosure / Collaboration

Challenges in API Security(work that we, the API industry must do)

• Massive proliferation of APIs where security was after-thought or non-thought• User ID / password absurdity

– Shared passwords (really no solution)– Weak passwords– Discoverable Passwords– Horrendous Best Practices

• Non-uniform implementations of – App Secrets– Callback URLs

• Good security is expensive– Talent– Resources like HSM

• Administrative tools for key/OAuth management limited– Analytics– Revocation/Reissue

• Unknown possibilities for 2FA with APIs• Internet of Things• Standards still in the works• Disclosure / Collaboration

Challenges in API Security(work that we, the API industry must do)

• Massive proliferation of APIs where security was after-thought or non-thought• User ID / password absurdity

– Shared passwords (really no solution)– Weak passwords– Discoverable Passwords– Horrendous Best Practices

• Non-uniform implementations of – App Secrets– Callback URLs

• Good security is expensive– Talent– Resources like HSM

• Administrative tools for key/OAuth management limited– Analytics– Revocation/Reissue

• Unknown possibilities for 2FA with APIs• Internet of Things• Standards still in the works• Disclosure / Collaboration

Discoverable Password Recovery Information

Challenges in API Security(work that we, the API industry must do)

• Massive proliferation of APIs where security was after-thought or non-thought• User ID / password absurdity

– Shared passwords (really no solution)– Weak passwords– Discoverable Passwords– Horrendous Best Practices

• Non-uniform implementations of – App Secrets– Callback URLs

• Good security is expensive– Talent– Resources like HSM

• Administrative tools for key/OAuth management limited– Analytics– Revocation/Reissue

• Unknown possibilities for 2FA with APIs• Internet of Things• Standards still in the works• Disclosure / Collaboration

Horrendous Password Practices

Horrendous Password Practices

Challenges in API Security(work that we, the API industry must do)

• Massive proliferation of APIs where security was after-thought or non-thought• User ID / password absurdity

– Shared passwords (really no solution)– Weak passwords– Discoverable Passwords– Horrendous Best Practices

• Non-uniform implementations of – App Secrets– Callback URLs

• Good security is expensive– Talent– Resources like HSM

• Administrative tools for key/OAuth management limited– Analytics– Revocation/Reissue

• Unknown possibilities for 2FA with APIs• Internet of Things• Standards still in the works• Disclosure / Collaboration

Twitter Requires App Secret

Facebook Doesn’t

https://gist.github.com/rhenium/3878505

Keys and Secrets Sold/Published

Challenges in API Security(work that we, the API industry must do)

• Massive proliferation of APIs where security was after-thought or non-thought• User ID / password absurdity

– Shared passwords (really no solution)– Weak passwords– Discoverable Passwords– Horrendous Best Practices

• Non-uniform implementations of – App Secrets– Callback URLs

• Good security is expensive– Talent– Resources like HSM

• Administrative tools for key/OAuth management limited– Analytics– Revocation/Reissue

• Unknown possibilities for 2FA with APIs• Internet of Things• Standards still in the works• Disclosure / Collaboration

Callback URL Not Always Required

Challenges in API Security(work that we, the API industry must do)

• Massive proliferation of APIs where security was after-thought or non-thought• User ID / password absurdity

– Shared passwords (really no solution)– Weak passwords– Discoverable Passwords– Horrendous Best Practices

• Non-uniform implementations of – App Secrets– Callback URLs

• Good security is expensive– Talent– Resources like HSM

• Administrative tools for key/OAuth management limited– Analytics– Revocation/Reissue

• Unknown possibilities for 2FA with APIs• Internet of Things• Standards still in the works• Disclosure / Collaboration

Challenges in API Security(work that we, the API industry must do)

• Massive proliferation of APIs where security was after-thought or non-thought• User ID / password absurdity

– Shared passwords (really no solution)– Weak passwords– Discoverable Passwords– Horrendous Best Practices

• Non-uniform implementations of – App Secrets– Callback URLs

• Good security is expensive– Talent– Resources like HSM (Hardware Security Module)

• Administrative tools for key/OAuth management limited– Analytics– Revocation/Reissue

• Unknown possibilities for 2FA with APIs• Internet of Things• Standards still in the works• Disclosure / Collaboration

It’s Expensive to Secure Secrets

Challenges in API Security(work that we, the API industry must do)

• Massive proliferation of APIs where security was after-thought or non-thought• User ID / password absurdity

– Shared passwords (really no solution)– Weak passwords– Discoverable Passwords– Horrendous Best Practices

• Non-uniform implementations of – App Secrets– Callback URLs

• Good security is expensive– Talent– Resources like HSM (Hardware Security Module)

• Administrative tools for key/OAuth management limited– Analytics– Revocation/Reissue

• Unknown possibilities for 2FA with APIs• Internet of Things• Standards still in the works• Disclosure / Collaboration

Challenges in API Security(work that we, the API industry must do)

• Massive proliferation of APIs where security was after-thought or non-thought• User ID / password absurdity

– Shared passwords (really no solution)– Weak passwords– Discoverable Passwords– Horrendous Best Practices

• Non-uniform implementations of – App Secrets– Callback URLs

• Good security is expensive– Talent– Resources like HSM (Hardware Security Module)

• Administrative tools for key/OAuth management limited– Analytics– Revocation/Reissue

• Unknown possibilities for 2FA with APIs• Internet of Things• Standards still in the works• Disclosure / Collaboration

Challenges in API Security(work that we, the API industry must do)

• Massive proliferation of APIs where security was after-thought or non-thought• User ID / password absurdity

– Shared passwords (really no solution)– Weak passwords– Discoverable Passwords– Horrendous Best Practices

• Non-uniform implementations of – App Secrets– Callback URLs

• Good security is expensive– Talent– Resources like HSM (Hardware Security Module)

• Administrative tools for key/OAuth management limited– Analytics– Revocation/Reissue

• Unknown possibilities for 2FA with APIs• Internet of Things• Standards still in the works• Disclosure / Collaboration

Challenges in API Security(work that we, the API industry must do)

• Massive proliferation of APIs where security was after-thought or non-thought• User ID / password absurdity

– Shared passwords (really no solution)– Weak passwords– Discoverable Passwords– Horrendous Best Practices

• Non-uniform implementations of – App Secrets– Callback URLs

• Good security is expensive– Talent– Resources like HSM (Hardware Security Module)

• Administrative tools for key/OAuth management limited– Analytics– Revocation/Reissue

• Unknown possibilities for 2FA with APIs• Internet of Things• Standards still in the works• Disclosure / Collaboration

The IoT Exacerbation

• 50 billion devices by 2020• Proliferation of miniaturized but battle-untested

platforms and operating systems• Security and usage patterns barely understood• Non-standard protocols involving less-evolved

security • Endpoints sprinkled across devices, proxies, and

the cloud• Involving massive amount of sensitive data

Challenges in API Security(work that we, the API industry must do)

• Massive proliferation of APIs where security was after-thought or non-thought• User ID / password absurdity

– Shared passwords (really no solution)– Weak passwords– Discoverable Passwords– Horrendous Best Practices

• Non-uniform implementations of – App Secrets– Callback URLs

• Good security is expensive– Talent– Resources like HSM (Hardware Security Module)

• Administrative tools for key/OAuth management limited– Analytics– Revocation/Reissue

• Unknown possibilities for 2FA with APIs• Internet of Things• Standards still in the works• Disclosure / Collaboration

Challenges in API Security(work that we, the API industry must do)

• Massive proliferation of APIs where security was after-thought or non-thought• User ID / password absurdity

– Shared passwords (really no solution)– Weak passwords– Discoverable Passwords– Horrendous Best Practices

• Non-uniform implementations of – App Secrets– Callback URLs

• Good security is expensive– Talent– Resources like HSM (Hardware Security Module)

• Administrative tools for key/OAuth management limited– Analytics– Revocation/Reissue

• Unknown possibilities for 2FA with APIs• Internet of Things• Standards still in the works• Documentation / Disclosure / Collaboration

Lax Docsstated here https://developer.linkedin.com/documents/getting-oauth-token

"You now have an access token and can make LinkedIn API calls. Please ensure to keep the user access tokens secure, as agreed upon in our APIs Terms of Use."

But the terms of use: http://developer.linkedin.com/documents/linkedin-apis-terms-use

Do not say or suggest that tokens must be stored or encrypted and how to do that.

Could even more be done?

Indecent Disclosure?

Protect Your API & Adjacencies• API security not just about securing the API itself• Do not rely on user credentials (user ID / password) for authentication• When issuing tokens, refresh frequently• Require app key and secret (not a silver bullet, but a barrier)• Require call-back URLs to go with application keys and secrets• Secure as much as possible via HSM or reasonable alternatives• Encrypt data in transit and at rest• Require 2FA-based authentication for all developers• Develop and regression test against known security patterns (make Apple’s problem your

problem) for all APIs (documented/undocumented)• Require/Reject User Settable Recovery Questions (where credentials are required)• Include Email address of record for recovery workflow?• Better more prescriptive documentation• Developer and end-user testing• Better Disclosure (for your users/customers, for the industry)• Monitor OAuth WG Proof of Possession (PoP) Standard

Protect Yourselves

• Only use password protected WiFi• Use a VPN if possible• Use 2FA-supported Federated Login when Possible

(reduce reliance on user ID/password combinations)• Examine email links before clicking through• Force token resets on a regular basis:

– Example: go to Twitter settings revoke client app access (eg: Buffer), grant it access again (forces re-issue of token)

• Check known sites for PWNage• Setup a Google Alert?

https://isleaked.com/action/check/

https://www3.trustwave.com/support/labs/check-compromised-email.asp

Pwned?

http://www.haveibeenpwned.com/

API Security < Internet Security