June 5, 2024 • 48 mins
We've got more data breaches and leaks to talk about. From an attack that targeted Microsoft corporate customers to one affecting three billion accounts, we look at how hackers and poor data security practices put people and their information at risk.
See omnystudio.com/listener for privacy information.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:04):
Welcome to tech Stuff, a production from iHeartRadio. Hey there,
and welcome to tech Stuff. I'm your host Jonathan Strickland.
I'm an executive producer with iHeart Podcasts and how the
tech are you? So? In our last episode, I started
covering some of the largest data breaches in US history,
(00:25):
and as a refresher, I'm using a list that was
compiled by Kyle Chen of upguard dot com, and you know,
biggest data breaches. That's an interesting adjective biggest, because the
scope of the attack isn't always a case where the
data breach affected more people than, say, the previous one
on the list. There are cases in which fewer people
(00:46):
were affected, but the types of information made the breach
more severe. For example, in our last episode, I talked
about al hackers stole information from millions of FriendFinder Networks customers.
So friend Fighter Networks op rates lots of different businesses,
including some that fall into the adult entertainment and adult
lifestyle categories. So for some customers, the revelation that they
(01:10):
were patronizing such a business could be embarrassing or damaging
due to the taboo nature of the services, and so
they're less likely to put up a big fuss about
a data breach, because if they did, it would be
admitting that they were using the service. And if you're
a hacker, that kind of target is really tempting because
your victims are incentivized to not come forward. Now, we
(01:35):
left off in the last episode talking about the Cambridge
Analytica scandal with Facebook. That scandal was a doozy and
was hitting right around the time when Facebook, now known
as Meta, was in the US government's crosshairs for multiple reasons.
In fact, I'd argue that those events are in part
what led to Facebook changing its name to Meta in
the first place. It was an attempt to kind of
(01:55):
distance itself from a brand that was being associated with
lacks security and other shady maybe not shady shade is
the wrong word, but ethically questionable actions. But as I
mentioned in the last episode, the Cambridge Analytica scandal was
just a little side quest in the real Number five
(02:15):
on our top ten list of largest data breaches in
US history. Chen's main target for number five was just
Facebook in general, because the site has been a massive
target for hackers looking to harvest a mountain of data,
and that makes sense. Most estimates put the number of
Facebook users in the neighborhood of three billion people billion
with a B. So, if you're a hacker and if
(02:38):
your goal is to steal as much personal information as
you can, you're likely balancing a few different things when
you're figuring out who you're going to attack. How valuable
is the information you're going to get hold of. How
much of that information do you think you can potentially
get away with? How secure is the system? You know
you might be able to infiltrate a relatively small target
(02:59):
without much trouble. On the flip side, you're not likely
going to end up with a ton of useful stuff
in the process. But Facebook, well, Facebook has just about
everyone's data on it, and heck, if you wanted to
see if you could compromise specific accounts and use those
to boost a misinformation campaign, that's a possibility too. It
may be that you're not looking to sell information. You
(03:19):
may want to sell a narrative, and in doing so,
what you're doing is borrowing accounts that aren't yours to
elevate a message. The main data breach that Chen mentions
with Facebook actually happened with Facebook in twenty twenty one.
You know, that's years after the Cambridge Analyticus scandal, and
that's when someone posted to a black market site on
(03:41):
the dark Web that they had data records including personal
information of more than half a billion Facebook users, so
more than five hundred million, like five hundred and thirty
million user accounts essentially, so this information would include things
like user names, the actual names, the data, birth location data,
and more, all from people who were on the platform
(04:03):
between twenty eighteen to twenty nineteen. How much data was
available per person depended upon the individual and the settings
that they used on Facebook, because this was another case
of hackers using data scraping tools to pull publicly available
information off a platform. So no different than if you
were to visit each person's account and then just note
(04:25):
down all the information that was visible to you. And
you might remember from our last episode that a hacker
with a handle Tomliner was offering similar information that someone
presumably Tomliner themselves whoever they are, had scraped off of LinkedIn.
So this Facebook instance is a similar case, except it
(04:46):
appears that the hacker exploited a vulnerability in the Facebook
platform to harvest information from profiles. Until Facebook fixed the
vulnerability in late twenty nineteen, and this is based off
Facebook's own statements about the data reach. The company claimed
initially that the April twenty twenty one data was the
same as a similar breach that happened in January, also
(05:08):
of twenty twenty one. Now Motherboard reported in January twenty
twenty one that quote a user of a low level
cyber criminal forum is selling access to a database of
phone numbers belonging to Facebook users and conveniently letting customers
look up those numbers by using an automated Telegram bot
end quote. So this person had created a database in
(05:29):
which you could search for specific names and see if
you've got a hit with a relevant phone number. But
the April revelation showed more than just phone numbers, which
you know already. Just the phone numbers is bad enough,
But the hack that happened later in twenty twenty one
included lots more stuff like that geolocation data if it
was in fact part of the account. Now companies like
(05:50):
Meta Slash Facebook typically have policies prohibiting the mass scraping
of data. As I said in the last episode, data
is effectively the currency of the Internet, and when you
really get down to it. User data is the commodity
that Meta relies upon for its revenue. Meta's whole business
model is primarily centered on advertising, and user data allows
(06:12):
Meta to work with ad companies to target specific customer bases.
So you'd better believe Meta would prefer to maintain dominion
over that information rather than having someone else get a
hold of it. Plus, by not keeping user information under
tight control, Meta opens itself up to lawsuits and regulatory
finds that sort of thing, and that certainly happened in
(06:32):
twenty twenty one. So, for example, the Data Protection Commission
or DPC, which is a regulatory agency in Ireland and
thus part of the European Union, found Facebook at fault
for failing to comply with the quote GDPR obligation for
data protection by design and default in the quote. So
as a quick reminder for those of y'all who live
(06:54):
outside the EU like me, GDPR stands for General Data
Protection Regulation and it's part of a much larger piece
of legislation regarding fundamental rights. So here in the United
States we have relatively little protection with regard to our
private information. That may be changing, but it's long overdue.
(07:14):
The same is not true in the EU, where citizens
are supposed to have authority over their own personal information.
In the wake of hackers releasing personal information about more
than five hundred million Facebook users, the DPC conducted an
investigation into Facebook. The DPC determined that Facebook failed to
embed proper data privacy and protection measures in place, and
(07:35):
that gave the hackers the opportunity to scrape all that data.
So just having a policy saying hey, don't do that,
that wasn't enough. They had to have things that actually
would prohibit the practice, and that was where the failure was.
The DPC then ruled that Facebook would owe a fine
of two hundred and sixty five million euros, which at
the time equalled to around two hundred and seventy five
(07:56):
million dollars, And that was actually the third fine DPC
levey to get Meta just that year. The first fine
was for eighteen point six million dollars that related to
Meta keeping really poor records that contributed to a data
leak that exposed the information of around thirty million Facebook users,
so a much smaller leak in that case. The second
(08:17):
of the fines was actually the largest because this two
hundred and sixty five million euros. That wasn't the most.
The most was four hundred two million, and that had
to do with how Facebook, well really Meta was handling
data that belonged to teenage users of the app Instagram.
So yeah, it was a very expensive year for Meta
in terms of fines paid to the EU. I mean
(08:37):
keep in mind that Facebook had also had to face
a five billion dollar fine in the United States earlier
due to other issues. So yeah, Facebook was no stranger
to having to pay out hundreds of millions and even
billions of dollars in fines for how the company handles information.
In Chen's blog post, he also points out a few
other incidents involving Meta and data security or lack of
(09:02):
data security. So, for example, in twenty nineteen, Upguard researchers
found a database of five hundred and forty million Facebook
user data records on quote public Amazon S three cloud
servers end quote. Now, arguably you could say this really
wasn't Facebook's fault, This was the fault of a third
party company that was working with Facebook. That third party
(09:24):
company was Cultura Collectiva, which was a media and app
developer company. So you could say that, you know, Cultura
Collectiva was a customer for Facebook, and they had this
massive database of Facebook user data, presumably so that they
could develop the apps or whatever that they were working on,
(09:45):
and they were storing this database on an Amazon S
three cloud server, but they failed to actually secure that
information on the cloud. They didn't put protections in place
to prevent unauthorized people from being able to access, which
is a big old whoopsie. But I think it's fair
to say that it was not Meta's direct fault for
(10:06):
this one. It sounded to me like this was the
third party that arranged to have the database on that server.
But I don't know if Facebook had done that, Like
if Meta had made it available on that server and
then gave access to Cultura Collectiva but failed to secure
that access appropriately, then yes, it would have been Meta's fault.
(10:27):
I honestly don't know the details where I can make
a determination in that regard. Anyway, That's really just the
tip of the iceberg when it comes to data breaches
with Meta slash Facebook. And given the reach of platforms
like Facebook and Watsapp and Instagram, you know, all these
different meta properties, it really should come as no surprise
(10:47):
that any data breach that targets Meta is going to
end up being one of the largest in US history
simply because they have such a huge user base, right like,
just by definition, if it's an effective attack, it's going
to be one of the largest ever. So again, it's
one of those things that you know, it makes Meta
such an attractive target for attackers, the fact that it's
(11:10):
this huge. Okay, we've got lots more to go through,
and rather than start the next entry and then just
have to take a break in the middle, let's take
a break. Now, we'll be back with numbers four and three.
I think, okay, we're back. So number four on our
(11:34):
list of largest data breaches in US history is another
financial institution. So in the last episode, I mentioned how
a twenty fourteen hack on JP Morgan Chase demonstrated that
it wasn't just web based companies that were at risk.
In May twenty nineteen, that lesson was reinforced when poor
data security practices meant the first American financial corporation inadvertently
(11:57):
made it possible for anyone with a particular weblink and
able to access some really sensitive financial information. There was
no hacking required. Literally, all you needed was the URL
and boom you could view a whole bunch of files,
and by whole bunch, I mean nine hundred million files almost,
so you know, more than eight hundred billion. I think
(12:18):
it was like eight hundred and eighty million something along
those lines. So what the heck happened? Well, whomever first
American financial corporation hired to do web design made a
major boo boo, And I'd like to think it was
an honest but dumb mistake and not you know, some
sort of malicious or premeditated attempt to gain access to
sensitive information. So essentially, the web developer failed to include
(12:40):
any sort of authorization or verification process to access this
list of files. So maybe the thought was just that,
you know, the URL for the web directory wouldn't be
published anywhere, so the only people who would even have
access to it were the ones who knew what the
UURL was. And if that was the thought, like if
it was like, oh, we don't need to institute anything
(13:02):
else because this is a private web address, who's going
to see it? That would be a practice that's called
security through obscurity, which by the way, is not very
secure at all. And as the name implies, the hope
is that by flying below the radar of attackers, no
one takes notice of you, so you remain safe, not
because you're practicing really good security, but because no one
(13:24):
has spotted you, and so no one has decided to
target you. Sometimes this isn't something that you're actively practicing,
it's just kind of in effect. I have argued in
the past that Apple enjoyed security through obscurity. For many years,
you didn't see much malware targeting Apple systems. Apple fans
(13:44):
would argue this was because Apple was just better at
security than companies like Microsoft or IBM. In fact, some
of Apple's own ads seemed to me at least to
imply that one advantage Apple computers had over Windows based
PCs is that they were more secure. Now, I would
counter that I don't think Apple was necessarily so much
(14:06):
better at security. I mean, granted, they were using proprietary systems,
including proprietary software and hardware, which does make it harder
to develop malware for those platforms. It doesn't make it impossible,
but it makes it harder. But I think that the
vast majority of people, I don't think this this is true.
The vast majority of people were not using Apple computers.
(14:26):
They were on Windows based machines. So, yeah, there were
people using Apple computers, but if you looked at the percentages,
I mean, Apple was just dwarfed by Windows machines. So
if you are a hacker and you're going to dedicate
the time and effort into developing malware, and you have
a specific goal in mind, whatever that goal might be,
you're more likely going to aim at the largest target
(14:48):
in order to have the biggest impact. Like, that's going
to make more of a difference than affecting a relatively
small population of Apple users. Go for the bigger population
of Windows users. That's security through obscurity, right, Like, yes,
the security might have been better to some degree, but
that's not why Apple was so safe for the longest time.
(15:10):
It was also safe or what was not the only reason?
I guess I should say it was also safe because
the company's market share was small enough that a lot
of hackers just didn't see the return on investment to
develop malware for Apple when most people were using Windows
machines anyway, Whether the thought was that no one who
(15:31):
was unauthorized would even find their way to this URL,
or it was just an oversight and the web developer
failed to take steps that they should have taken the
vulnerability was in place, and this type of vulnerability is
called an insecure direct object reference. So this is just
a category for vulnerabilities, and essentially it just means that
(15:52):
if a user has the ability to submit a specific
input into a system and they can gain access to
that system without having to pass through any control measures,
that is an insecure direct object reference. So in this case,
the input was just a web address, so the only
tool that you needed was a browser. You did not
(16:14):
have to be a hacker. You needed a web browser
and you needed to put a URL into the address
bar and boom, you would be taken to one of
these documents. Now, adding to this problem was the fact
that First American Financial Corporation was using a sequential numbering
system for their documents, which meant if you had discovered
a URL that brought you to one of these documents,
(16:37):
you could then adjust the numeral that was at the
end of the file name, and if you went down one,
then you'd see the previous record, and if you went
up one, you'd see the next record. So what kind
of records are we talking about. Well, it included stuff
like bank statements, receipts, actual bank account numbers, drivers licenses,
(16:58):
and other stuff. Now, on the bright side, while security
researcher Brian Krebs reported on the discovery of the issue,
it appeared that no unauthorized third parties with malicious intent
had actually accessed this information. You could argue, really just
a matter of luck. Also, there was no way to
really know. But it just didn't seem like this stuff
was showing up anywhere where you would say, oh, the
(17:21):
bad guys got hold of this, right. It wasn't like
it was popping up on the dark web. Perhaps because
it seemed that no criminals had found out about this
problem before First American could actually, you know, address it,
the SEC went fairly light on the financial institution, at
least in my opinion. First American was ordered to pay
a five hundred thousand dollars fine. Now, five hundred thousand
(17:43):
dollars is a lot of money. If you hit me
with a five hundred thousand dollars fine, I would be
up the creek. I would be so deep in trouble.
But when you think of like a financial institution and
the fact that this this data leak scope was nearly
a billion records of incredibly sensitive financial information. I think
(18:04):
it's still a fairly light fine to have to pay.
The State of New York would actually secure a million
dollar payout from First American in a lawsuit settlement, so
that was twice as much. Now it may be, and
I haven't looked at this. It maybe that the SEC
just had limitations on how much it could find an institution,
in which case, you know, no fault on them. It's
(18:24):
not like it's not like they could do more. If
you throw the book at someone, you don't typically assume
the person has a second book to throw. More recently,
First American was in the news again in late twenty
twenty three when hackers claiming to be part of the
infamous Alpha and black Cat groups infiltrated company systems and
encrypted several directories as a ransomware attack. Now, this disrupted
(18:47):
First Americans operations for a short while, but the company
assured the public that the attackers had failed to lock
off anything that was absolutely critical for operations, and at
first they believe that customer records weren't act. However, very
recently First American revealed that quote personal information pertaining to
approximately forty four thousand individuals may have been accessed without
(19:09):
authorization as a result of the incident. End quote. This
is according to the title report dot com. So the
company is going to be contacting those who are potentially
affected and offer identity protection services and credit monitoring for
free for you know, some amount of time. I don't
know for how long. Number three on our list is
a real estate education company. It is called the Real
(19:31):
Estate Wealth Network. Now, before I did any research on
this episode, I had not heard about this particular data breach.
This one I just missed. When it happened, it was
big news, and somehow I didn't see it, And it
really was a data leak. So similar to what we
just talked about with First American. As opposed to you know,
hackers compromising a system, this is more of a company
(19:52):
failing to put in the proper measures to protect information.
Before I read about this particular situation, my imagination went wild, right,
because it's the Real Estate Wealth Network. I in my
imagination thought, aha, this is going to be a story
about some sort of crypto anarchist, right, because here's a
(20:15):
company that's dedicated to teaching folks how to build wealth
by buying up real estate in many parts of the
United States. Right now, we're in sort of a housing crisis.
There are a lot of middle class Americans who cannot
afford to buy a house, which is a change from
previous generations. Right like, you have people who are in
the same relative space in middle class, who, unlike earlier generations,
(20:40):
cannot buy an average home or a suitable home. So
the housing prices have skyrocketed in various regions throughout the
United States in recent years, and a lot of properties
seem to get scooped up by people or companies determined
to turn the houses into lucrative vacation rental properties a
la Airbnb and such. So I am imagine this data
(21:01):
breach was the work of some crypto anarchist akin to
the main character in v for Vendetta. You know, a
person who was determined to take down the system by
targeting a wealth generation platform that by its very existence
seemed to put the common person at a disadvantage. But no,
it's nothing quite so dramatic as that. This is another
case of a company failing to institute basic security measures
(21:23):
in place in order to protect sensitive information. So let's
talk about that information first, and then I will talk
about what actually happened. So the leaked info included all
the top hits, you know, your basic stuff like customer names,
their phone numbers, addresses, that kind of thing. But it
also included other stuff like tax IDs, or whether or
(21:45):
not the entity that owned the property had ever gone
through bankruptcy, or if there were any court judgments against
the property owner. Obviously, it also included property history records
like when it was bought and sold and who bought
it or sold it. And there were a lot of
these data records, or like a one and a half
billion data records in total. Some of them included information
(22:08):
about very notable people, you know, like politicians and celebrities
and that kind of thing. And you could imagine this
sort of crime meant that the people who had access
to this information could do all sorts of other crimes,
everything from spearfishing, which would be a breeze because you
would have so much information about your target, you could
craft a very convincing attack that would potentially compromise them further.
(22:34):
You would have all the information you needed to commit
some pretty nasty fraud crimes in the name of some
of these victims. Not to mention now that you have
these notable people like politicians and celebrities. You have information
that you know, stalkers would really like, or people who
have a particular desire to hurt somebody specific they might
really want the information. So yeah, there's a whole host
(22:55):
of crimes that can happen as a result of this.
So what actually happened? How did this come about? Well,
the simple explanation is that the Real Estate Wealth Network
failed to put any security around accessing this database, which
held one point one six terabytes of information in it.
There was this security researcher named Jeremiah Fowler who discovered
(23:16):
the problem. He found an unencrypted, massive database containing extremely
sensitive information, and he said he found it after searching
for his own details, and then he followed a trail
that led to this database. So I don't know if
he was just like doing this search just on his
own and that had nothing to do with, you know,
any kind of investigation and just stumbled upon this, or
(23:38):
if he had already heard something about this or suspected
something about it and then started to do some searching
and came across it. Either way, he reported the problem
to the Real Estate Wealth Network, and to their credit,
they promptly locked down access to the database, They closed
off that avenue toward the data, and they also confirmed
that they owned the data base, which again all credit
(24:02):
to Real Estate Wealth Network for doing this. They acknowledged
the data leak, and honestly, that had a real breath
of fresh air to it, because, yes, the leak never
should have happened in the first place, but at least
we're not talking about an incident in which the company
delayed installed for days, weeks, months, or even years before
finally owning up to it. Because spoiler alert number one
(24:23):
on this list did that. It's a company that held
back on disclosing information about a massive data breach for
multiple years. But no, Real Estate Wealth Networks was pretty
quick to disclose this issue, which is really the responsible
thing to do, right, to warn those who have been
affected so that they could be on the lookout for
any signs that malicious actors have accessed that information. However,
(24:47):
despite this responsible approach, you know, you still have to
admit there were some pretty massive problems here. So for
one thing, it was not clear how long that database
had been unsecured, right it could have been unsecured for ages.
It was also unknown whether anyone besides you know, the
security research or Fowler had noticed this issue, because you know,
(25:08):
if criminals had found it, they would have a treasure
trove of data at their fingertips, and they wouldn't likely
just blurred out that they had found it if they
wanted to keep accessing it, although they could have made copies.
And apparently, from what I understand, no one found anything
about this on the dark web, So that's a fairly
good indicator that it was unnoticed by the criminal element.
(25:31):
But I mean, it would have only been a matter
of time. So the fact that Fowler found it and
that Real Estate Wealth Networks responded so quickly, that's really
a good thing. But yeah, this data included you know,
information about actual like celebrities, everyone from Britney Spears to
Elon Musk to Nancy Pelosi. So okay, we're coming down
to our top two entries on this list. Although I
(25:52):
should remind everybody that while I'm presenting this as a
top ten countdown, in episode one was like ten through
five and a half and this is five through one,
I should mention Kyle Chen did not claim that his
list was ordered in any kind of ranked way. He
listed twenty six different data breaches, and I don't wish
to imply that this is Kyle Chin's ranking. I just
(26:15):
chose to interpret it that way. So I'm just an
Internet hack. Really. Maybe at some point I'll do an
episode covering the other sixteen data breaches. But we're gonna
take a quick break right now for some more messages,
and when we come back, we're gonna keep on hacking. Okay,
(26:41):
we're back, and I mentioned before the break, we're gonna
keep on hacking. And hacking actually does play a part
in numbers two and one, right, because the last two
those weren't really data breaches. Those were data leaks. A breach,
I would argue, is when an outsider, a hacker, has
managed to infiltrate a system in some way. They have
(27:02):
breached the security whatever there might be of a system.
Data leaks are when you don't have any security in
place and no one actively has to be like searching
for it. It's just out there and it's available if
you happen to nowhere to look. Well, this is definitely
a breach, not a leak, and it's one that puts
Microsoft in the spotlight. The Culprit was an allegedly China
(27:24):
backed hacker group called Hafnium. The target were Microsoft Exchange servers.
So to be clear, the targets weren't just Microsoft. It
wasn't like the they were going after the company Microsoft.
They were going after companies that were using Microsoft Exchange servers,
So customers of Microsoft. That's who these hackers were going after.
(27:47):
And the entry point was allegedly four separate zero day vulnerabilities.
Now I mentioned in the previous episode. A zero day
vulnerability is one that the person or entity that's responsible
for the softwareware, or system doesn't know about. That's what
makes it a zero day vulnerability. They have zero days
to address any sort of exploit that pops up in
(28:09):
the wild, and zero day vulnerabilities are like gold to hackers.
They represent an opportunity to infiltrate systems without fear of
being stopped or sometimes even detected, and that gives hackers
way more time and opportunities to achieve whatever goals they have,
whether that's stealing information or breaking entire directories as part
(28:30):
of a ransomware attack, or infiltrating systems with malware, whatever
it might be. One zero day vulnerability is bad for
zero day vulnerabilities is really really bad. And on top
of that, some of these vulnerabilities had sort of been
grandfathered in from software that had been out for almost
a decade at that point. One key element that made
(28:51):
this particular attack so devastating was that many of the
customers using Microsoft Exchange kept their own email servers on
company premises or on prem as those in the biz
call it, so in case you're not familiar with that term,
it just means that a company hasn't offloaded everything to
(29:11):
the cloud. At least some of their servers that they're
using are on company property, whether that's in the company
HQ or a data center or whatever. The point is,
they own and operate the server. They're just running the
Microsoft Exchange product on those servers. So these are computers
that are not under the direct supervision of Microsoft. And
(29:33):
that's the important part, and the reason it's important is
that once Microsoft became aware of these vulnerabilities, they could
and they did release security patches to plug up those holes,
which would stop attackers from being able to infiltrate those
Microsoft Exchange servers. But while Microsoft could install these patches
(29:55):
directly onto any systems that were under their direct control.
They couldn't do that with exchange servers that were on
premises on customer property, right because Microsoft doesn't have that access.
You wouldn't want Microsoft to have that access. You know,
the whole reason to have on premises systems is that
those are under your direction and control. So you don't
want to give another party access to that's that's a
(30:18):
security vulnerability. So that meant Microsoft had to send out
messages to their customers that essentially said, hey, you need
to install these security patches asap, like yesterday, and the
customers were in charge of actually following through on that
because they were maintaining their own on premises email servers.
(30:38):
And you know, some companies have it departments that will
respond immediately to these kinds of messages and install those
kind of security patches, but there are cases where that
doesn't happen. Now, sometimes the decision not to implement a
security patch right away is actually done out of a
sense of caution, because occasionally you'll get a patch that
(30:59):
once you install, but it has unintended consequences on your operations,
right it might break something else, And so sometimes companies
won't install a security patch on the initial day of
release just in case that patch causes other issues. They
take a wait and see approach to make sure that
they're not going to interrupt their regular business operations by
(31:21):
installing this patch. But that means that they remain vulnerable
for as long as the patch remains uninstalled. Now, other times,
you might have IT departments that just are not on
top of the ball, and that means some companies would
just go unprotected longer than others. Sometimes you don't really
have an IT department at all, Right, You've outsourced a
lot of stuff, and so you don't necessarily have the
(31:44):
assets in place to be able to install security patches.
You're depending too heavily upon third parties and as a result,
you may not have the staff who has the knowledge
of how to install those security patches. It's possible there
are still some servers out there that aren't protected, though
I hope that's not the case because it has been
(32:04):
like three years since this attack happened, and surely someone
has installed security updates within those three years. But you
never know anyway, what did the attackers actually achieve, what
was their goal and what did they do well by
exploiting these vulnerabilities in Microsoft's software. The hackers gained access
to these infected email servers, and that meant they could
(32:27):
access all the email on that server as if they
were the administrator of the server. They could read everything,
so they could go into any account on that email
server and read stuff. They could send email as someone
else if they wanted to, and they could harvest data
in contacts. They could pull all the information off of
calendars like they could gather a lot of valuable information. Now,
(32:52):
in this case, the targets were companies, not necessarily individuals. However,
if they were able to compromise a company system that
had an individual of interest on it, then they could
pull tons of information about that person as part of
their attack. The attackers were able to compromise the email
servers of around thirty thousand companies in the United States.
(33:14):
Thirty thousand companies, not people like keep in mind, like
these businesses might employ hundreds or thousands of people. They
were also able to compromise another thirty thousand businesses around
the world, so sixty thousand total. Brian Krebs, once again
was the researcher who wrote about these attacks and alerted
the world in general as to what was going on.
The revelation came just a few days after Microsoft had
(33:36):
released emergency security updates. By the way, there are actually
a lot of security researchers out there, the white hat
hacker types, who tend to have a general code of
honor right. If they discover a vulnerability in a system,
typically what they do is they reach out to the
company or person responsible for that system and they alert them.
They say, hey, I found this, it's possible to exploit.
(34:00):
You're gonna want to patch it. And typically they'll give
a little bit of time for the company to respond
to this, and then they'll wait for that response before
they reveal what they know to the public. That's the
responsible way to do it, so that the least amount
of damage is done. However, if a company fails to respond,
like if it doesn't acknowledge the fact that you have
(34:20):
alerted them to this vulnerability at all, well, sometimes researchers
will reveal what they know in an effort to pressure
the company into responding. If they go public and say
this vulnerability exists, then there's suddenly this enormous amount of
pressure on the company to fix it, and then also
warns the customers of that company that the product they're
(34:42):
using isn't secure. However, in this case, Microsoft acted very
quickly and then Brian Krebs reported on it, so back
to Microsoft. US cybersecurity experts determine that the hacker group
Halfnium was responsible for these attacks, and that in turn
Halfnium enjoyed the backing and protection of the Chinese government. Further,
the attacks were assumed to be part of a large
(35:03):
espionage mission to spy upon and steal information from US companies.
In particular, The Guardian reported that the US government, in
the form of the FBI, the Federal Bureau of Investigation,
took a rather extreme step to protect companies by hacking
into infected systems that belonged to various companies that had
(35:23):
failed to mitigate the malware themselves. In order to actually
neutralize the threat, so the FBI hacked into company systems
in order to shut down the malware. The FBI did
not go the extra step to install the security updates
on those systems. But apparently the FBI was fighting hacking
by hacking, I guess, and not directly against the hackers,
(35:44):
but against the same companies that had already been hacked.
When it comes to zero day vulnerabilities. I don't think
there's really anything I can say that's terribly helpful. I mean,
how do you fix a problem if you don't know
there is a problem. So, you know, it might be
tempting to blame Microsoft for leasing software platforms that had
these vulnerabilities in them, but again, if the company has
(36:04):
no awareness that there's an issue, how are they supposed
to fix it? So I think just saying do better
isn't really useful. You see that a lot in the
gamer community. It's very dismissive and snobby, and I hate
it and it's not useful at all. It's not helpful.
So I don't really think that's a viable response. As
(36:25):
for customers, well, there's even less that you can do
as a customer to prevent an attack that leverages a
zero day vulnerability in some tool that your company is using.
The best you can do is beyond the ball when
security patches come out to minimize the risk of becoming
another victim, or to at least temporarily migrate away from
a tool that's been known to have been compromised. Okay,
(36:48):
we're finally up to number one on the list, and maybe,
like I said, I'll do a future episodes to cover
some of the other instances that Kyle Chen mentions. So again,
if you didn't hear me before, these are all coming
from a blog post that Kyle Chen wrote for upguard
dot com, So you can always look up like the
largest data breaches in US history. That'll probably pull that
(37:08):
article up as a result. That's where I'm getting this
particular list. But our number one entry is Yahoo, and yeah,
this one was huge. Also, I can't really say this
one because the word one is deceptive. Honestly, this was
a series of cyber attacks that ultimately resulted in more
than three billion records being exposed to cyber criminals. Three billion.
(37:34):
That's nearly forty percent of the world's population. Though honestly,
that's three billion accounts. I'm sure that some people had
multiple accounts, so it's not the same thing as three
billion people, I guess, But that seems like a fine
point that we don't really need to worry about. If
we do assume that's three billion people, that means if
you were to get ten people together, four of those folks,
(37:56):
or really three point seven eight of them would be
affected by this. But those chances would actually depend upon
where in the world you are, right, Like, if you're
in a more developed part of the world, then the
odds are going to be higher that there'll be more
people there who were affected by this. My analogy only
works if the ten people are randomly selected from all
over the world. But anyway, I'm on a tangent. So
(38:16):
what happened, Well, what happened was a combination of various
hacking techniques, some international intrigue, a company staying quiet about
the whole thing for way too long after finding out
about this intrusion, possibly in an effort to avoid affecting
a massive acquisition deal that was going on with another
big company. Because this story is juicy, y'all. But we
(38:40):
begin in twenty thirteen, and this is when the first
and the largest hack happened, though the public would not
find out about it for another three years. Now. Arguably,
Yahoo itself remained ignorant of this attack for quite some time,
but it would take three years for the US public
to hear that this had happened. Even in that revelation,
(39:04):
Yahoo would downplay how many accounts were affected by a
third in fact, because, as we would later hear in
twenty seventeen, the attack compromised some three billion accounts, but
when Yahoo disclosed this attack to the public back in
twenty sixteen, Yahoo said it was just one billion, which
is weird. I was saying, just is crazy. I mean,
(39:24):
one billion is a number so huge that I cannot
possibly imagine it. So you might as well cop to
all three billion at that point, right, But to be
fair to Yahoo, I do think it's very possible the
company honestly did not have a grasp on how large
this attack actually was at that time. And by large
I do mean every single Yahoo account active or otherwise
(39:46):
was affected by this because the company had lousy security.
There's no getting around it. I don't think that's opinion,
by the way, because in twenty twelve, Yahoo had already
been the target of a different hacker attack that ultimately
compromised nearly half a million accounts. Now half a million
is a drop in the bucket compared to three billion.
It's nothing. But you would think that half a million
(40:09):
compromised accounts would be a serious wake up call to Yahoo,
and it would at least kick things into gears so
that the company would institute better security practices. But sadly,
that didn't really happen, or at least it didn't happen
on a scale and timeline that would prevent the massive
intrusion in twenty thirteen. Now, it is easy to conflate
the twenty thirteen attack with another one that happened in
(40:30):
twenty fourteen. So if you're keeping count, that's three different
hacker intrusions in three years. Twenty twelve was half a million,
twenty thirteen three billion, twenty fourteen was like five hundred million.
I think it is important to draw some distinctions between
these because authorities would ultimately identify four individuals believed to
(40:51):
be responsible for the twenty fourteen attack. These folks would
also end up having alleged ties to the Russian government. Thus,
there are locations that the Yahoo hack in twenty fourteen
was the result of a state backed hacking operation, that
it was essentially funded by the Russians. Now, whether the
twenty thirteen attack was state backed or not, we don't
(41:15):
really know. To this day. As far as I can tell,
no one has the definitive information on who was behind
the twenty thirteen attack. Marissa Meyer, who was CEO of
Yahoo during those data breaches, would testify to Congress in
twenty seventeen that the company had been unable to determine
who was responsible for that particular attack in twenty thirteen.
She also revealed that she did learn of the twenty
(41:37):
fourteen intrusion in twenty fourteen, this is the one that
would affect half a billion accounts, but she didn't learn
of the actual scale of the attacks until twenty sixteen.
So if that's true, it meant the attackers had some
really good ability to hide their tracks and had years
of opportunity there as well. So presumably no one knew
(41:57):
about the twenty thirteen attack until much later. They knew
about the twenty fourteen attack, but they didn't know how
bad it was. This also means I can't really talk
about what happened in twenty thirteen, because the truth of
the matter is there were several potential exploits that the
hackers could have used, and the twenty thirteen attack may
have used multiple avenues to get access to all the information.
(42:18):
We can, however, talk about what happened in twenty fourteen.
We know more about that one. It's a tail that
involves spearfishing and cookies. Now I should also mention this
version of the story comes to us courtesy of the FBI.
The agency said that the hackers first sent spearfishing emails
to Yahoo employees, So again, these are emails meant to
(42:39):
trick someone into taking some sort of action that benefits
the hacker, and in this case, it was clicking on
a link that ultimately would give the hackers administrator level
access to some of Yahoo's systems, but not all of
their systems. But it did give them a chance to
look at some code that Yahoo used that would be
really valuable, and this included code on how Yahoo generated
(43:02):
Internet cookies, So a quick refresher course on what cookies
are and what they do. With the Web, You've got
clients and you've got servers. So if you're browsing the
web on your computer or your smartphone, you're using a client.
Servers are sending or serving you the information that you're requesting.
So if you type in an address in your web
(43:23):
browser like www dot Google dot com, your client sends
a request to go to that website. This request gets
routed to the appropriate web server, which then sends the
data to your client, so that you are visiting Google.
So each interaction is kind of like this. Now, to
save some time and effort, we have cookies. So cookies
(43:43):
are little bits of info that get saved to your
computer the client, and cookies can do really handy stuff.
For example, let's say that you've logged into an account
on a service like Amazon and you're doing some shopping,
and then you navigate a way because you have to
go do something else. But then gush, darn it, you remember, oh, well,
you know what, I should have ordered something else on
top of everything else. So you go back to Amazon. Well,
(44:04):
if you didn't have cookies, you would need to go
all the way back through the login process because Amazon
wouldn't know it was you again. But with a cookie
stored on your computer, Amazon can say, oh, yeah, that's
Billy Bob who logged in earlier, never logged out their
back Let's just let them continue their session. So cookies
are how web pages quote unquote know where you were
(44:26):
the last time you visited, so that you can kind
of pick up where you left off. Of course, cookies
can do more than that, and there's a whole discussion
to be had about tracking and whatnot with cookies, but
we're going to leave that for now. So how did
the attack happen. Well, the hypothesis goes that the hackers
were able to figure out how to forge Yahoo cookies
because Yahoo was not good at practicing decent security, because
(44:50):
ideally each cookie would contain data that's unique to a
single individual and that would be very hard to crack.
But Yahoo apparently wasn't really doing this in that regard.
You could say Yahoo was kind of behaving sort of
like how certain German officers in World War Two were
reusing code phrases while encrypting messages using an Enigma machine. Now,
the practice of reusing those code phrases, that's what gave
(45:14):
British code breakers the advantage that they needed to actually
break the code. If the Germans had used more discipline
security measures, the code likely would have stood up to
the BRIT's best efforts and it wouldn't have ever been broken. Possibly.
I mean, it's impossible to say, because we know what
did happen, it's impossible to say that what could have
happened was a definite possibility. Anyway, all this meant that
(45:35):
the hackers could actually forge a cookie, and they could
fool Yahoo into thinking that the hackers were actually somebody else,
like a legitimate Yahoo user, So it meant that they
could access user accounts and then spy on that user's correspondence,
plus scrape any data relating to that user and their
other online accounts. So potentially they could even compromise even
(45:58):
more data in the process. A right, like if you
figure out a user's username and password, and you also
see that they use other services, you can try and
use that and see if it works. Because so many
people reuse their passwords. I said it in the last episode,
I'll say it again. Don't do that, And you start
to see how a data breach can be much bigger
than just this enormous scope of three billion accounts. So
(46:19):
coy to Marissa Meyer, Yahoo learned about the twenty fourteen attack,
even though they might not have known what the scope was,
but they kept things quiet, possibly in part because there
was this big acquisition deal Verizon wanted to acquire Yahoo.
Some of this news, however, would break before that deal
would be finalized, and Verizon would drop the offer by
(46:39):
a whopping three hundred and fifty million dollars, So that
was a big deduction on the final cost for that acquisition,
and even that might have been too modest. Because, of course,
later we would find out the real scope of those attacks,
lawsuits would follow, but Yahoo would pay out a little
more than one hundred million dollars as a result of
the lawsuits, a few tens of millions here, tens of
(47:02):
millions there in different fines, But honestly, I think it
was a pretty small amount considering the nature and scope
of the attack. Then again, the whole thing did cost
y'all who hundreds of millions of dollars because the acquisition
was reduced in price too. Only one of the four
men identified as hackers in that twenty fourteen attack was
ever arrested and sentenced for this crime was in a
(47:25):
Canadian citizen named Karim Borotov. He was sentenced to five
years in prison. He even wrote a book about his experiences.
The other three accused, which included two members of the
Russian FSB, that's kind of like the successor of the
KGB in the old Soviet days. They were accused, but
they were never arrested, and of course Russia denied having
(47:45):
any involvement in the attacks whatsoever. And that brings us
down to the last of my top ten. Again, I
don't wish to suggest that Kyle Chin had ranked these
in any specific way. This was kind of how I
ranked them, and there were sixteen other ones on that list.
So again, go to upguard dot com and search for
that article about the largest data breaches in US history
(48:06):
if you want to read more about them. Maybe I'll
do an episode about those later. I might do an
episode just about the ticketmaster data breach because that happened.
That are particularly bad time for ticketmasters since it's already
in the crosshairs of the US government due to an
antitrust lawsuit. So maybe I'll do a full episode about
that in the future too. In the meantime, I hope
(48:26):
you're all safe. I hope all your personal information is safe,
and I'll talk to you again really soon. Tech Stuff
is an iHeartRadio production. For more podcasts from iHeartRadio, visit
the iHeartRadio app, Apple Podcasts, or wherever you listen to
(48:47):
your favorite shows.
Welcome to tech Stuff, a production from iHeartRadio. Hey there,
and welcome to tech Stuff. I'm your host Jonathan Strickland.
I'm an executive producer with iHeart Podcasts and how the
tech are you? So? In our last episode, I started
covering some of the largest data breaches in US history,
(00:25):
and as a refresher, I'm using a list that was
compiled by Kyle Chen of upguard dot com, and you know,
biggest data breaches. That's an interesting adjective biggest, because the
scope of the attack isn't always a case where the
data breach affected more people than, say, the previous one
on the list. There are cases in which fewer people
(00:46):
were affected, but the types of information made the breach
more severe. For example, in our last episode, I talked
about al hackers stole information from millions of FriendFinder Networks customers.
So friend Fighter Networks op rates lots of different businesses,
including some that fall into the adult entertainment and adult
lifestyle categories. So for some customers, the revelation that they
(01:10):
were patronizing such a business could be embarrassing or damaging
due to the taboo nature of the services, and so
they're less likely to put up a big fuss about
a data breach, because if they did, it would be
admitting that they were using the service. And if you're
a hacker, that kind of target is really tempting because
your victims are incentivized to not come forward. Now, we
(01:35):
left off in the last episode talking about the Cambridge
Analytica scandal with Facebook. That scandal was a doozy and
was hitting right around the time when Facebook, now known
as Meta, was in the US government's crosshairs for multiple reasons.
In fact, I'd argue that those events are in part
what led to Facebook changing its name to Meta in
the first place. It was an attempt to kind of
(01:55):
distance itself from a brand that was being associated with
lacks security and other shady maybe not shady shade is
the wrong word, but ethically questionable actions. But as I
mentioned in the last episode, the Cambridge Analytica scandal was
just a little side quest in the real Number five
(02:15):
on our top ten list of largest data breaches in
US history. Chen's main target for number five was just
Facebook in general, because the site has been a massive
target for hackers looking to harvest a mountain of data,
and that makes sense. Most estimates put the number of
Facebook users in the neighborhood of three billion people billion
with a B. So, if you're a hacker and if
(02:38):
your goal is to steal as much personal information as
you can, you're likely balancing a few different things when
you're figuring out who you're going to attack. How valuable
is the information you're going to get hold of. How
much of that information do you think you can potentially
get away with? How secure is the system? You know
you might be able to infiltrate a relatively small target
(02:59):
without much trouble. On the flip side, you're not likely
going to end up with a ton of useful stuff
in the process. But Facebook, well, Facebook has just about
everyone's data on it, and heck, if you wanted to
see if you could compromise specific accounts and use those
to boost a misinformation campaign, that's a possibility too. It
may be that you're not looking to sell information. You
(03:19):
may want to sell a narrative, and in doing so,
what you're doing is borrowing accounts that aren't yours to
elevate a message. The main data breach that Chen mentions
with Facebook actually happened with Facebook in twenty twenty one.
You know, that's years after the Cambridge Analyticus scandal, and
that's when someone posted to a black market site on
(03:41):
the dark Web that they had data records including personal
information of more than half a billion Facebook users, so
more than five hundred million, like five hundred and thirty
million user accounts essentially, so this information would include things
like user names, the actual names, the data, birth location data,
and more, all from people who were on the platform
(04:03):
between twenty eighteen to twenty nineteen. How much data was
available per person depended upon the individual and the settings
that they used on Facebook, because this was another case
of hackers using data scraping tools to pull publicly available
information off a platform. So no different than if you
were to visit each person's account and then just note
(04:25):
down all the information that was visible to you. And
you might remember from our last episode that a hacker
with a handle Tomliner was offering similar information that someone
presumably Tomliner themselves whoever they are, had scraped off of LinkedIn.
So this Facebook instance is a similar case, except it
(04:46):
appears that the hacker exploited a vulnerability in the Facebook
platform to harvest information from profiles. Until Facebook fixed the
vulnerability in late twenty nineteen, and this is based off
Facebook's own statements about the data reach. The company claimed
initially that the April twenty twenty one data was the
same as a similar breach that happened in January, also
(05:08):
of twenty twenty one. Now Motherboard reported in January twenty
twenty one that quote a user of a low level
cyber criminal forum is selling access to a database of
phone numbers belonging to Facebook users and conveniently letting customers
look up those numbers by using an automated Telegram bot
end quote. So this person had created a database in
(05:29):
which you could search for specific names and see if
you've got a hit with a relevant phone number. But
the April revelation showed more than just phone numbers, which
you know already. Just the phone numbers is bad enough,
But the hack that happened later in twenty twenty one
included lots more stuff like that geolocation data if it
was in fact part of the account. Now companies like
(05:50):
Meta Slash Facebook typically have policies prohibiting the mass scraping
of data. As I said in the last episode, data
is effectively the currency of the Internet, and when you
really get down to it. User data is the commodity
that Meta relies upon for its revenue. Meta's whole business
model is primarily centered on advertising, and user data allows
(06:12):
Meta to work with ad companies to target specific customer bases.
So you'd better believe Meta would prefer to maintain dominion
over that information rather than having someone else get a
hold of it. Plus, by not keeping user information under
tight control, Meta opens itself up to lawsuits and regulatory
finds that sort of thing, and that certainly happened in
(06:32):
twenty twenty one. So, for example, the Data Protection Commission
or DPC, which is a regulatory agency in Ireland and
thus part of the European Union, found Facebook at fault
for failing to comply with the quote GDPR obligation for
data protection by design and default in the quote. So
as a quick reminder for those of y'all who live
(06:54):
outside the EU like me, GDPR stands for General Data
Protection Regulation and it's part of a much larger piece
of legislation regarding fundamental rights. So here in the United
States we have relatively little protection with regard to our
private information. That may be changing, but it's long overdue.
(07:14):
The same is not true in the EU, where citizens
are supposed to have authority over their own personal information.
In the wake of hackers releasing personal information about more
than five hundred million Facebook users, the DPC conducted an
investigation into Facebook. The DPC determined that Facebook failed to
embed proper data privacy and protection measures in place, and
(07:35):
that gave the hackers the opportunity to scrape all that data.
So just having a policy saying hey, don't do that,
that wasn't enough. They had to have things that actually
would prohibit the practice, and that was where the failure was.
The DPC then ruled that Facebook would owe a fine
of two hundred and sixty five million euros, which at
the time equalled to around two hundred and seventy five
(07:56):
million dollars, And that was actually the third fine DPC
levey to get Meta just that year. The first fine
was for eighteen point six million dollars that related to
Meta keeping really poor records that contributed to a data
leak that exposed the information of around thirty million Facebook users,
so a much smaller leak in that case. The second
(08:17):
of the fines was actually the largest because this two
hundred and sixty five million euros. That wasn't the most.
The most was four hundred two million, and that had
to do with how Facebook, well really Meta was handling
data that belonged to teenage users of the app Instagram.
So yeah, it was a very expensive year for Meta
in terms of fines paid to the EU. I mean
(08:37):
keep in mind that Facebook had also had to face
a five billion dollar fine in the United States earlier
due to other issues. So yeah, Facebook was no stranger
to having to pay out hundreds of millions and even
billions of dollars in fines for how the company handles information.
In Chen's blog post, he also points out a few
other incidents involving Meta and data security or lack of
(09:02):
data security. So, for example, in twenty nineteen, Upguard researchers
found a database of five hundred and forty million Facebook
user data records on quote public Amazon S three cloud
servers end quote. Now, arguably you could say this really
wasn't Facebook's fault, This was the fault of a third
party company that was working with Facebook. That third party
(09:24):
company was Cultura Collectiva, which was a media and app
developer company. So you could say that, you know, Cultura
Collectiva was a customer for Facebook, and they had this
massive database of Facebook user data, presumably so that they
could develop the apps or whatever that they were working on,
(09:45):
and they were storing this database on an Amazon S
three cloud server, but they failed to actually secure that
information on the cloud. They didn't put protections in place
to prevent unauthorized people from being able to access, which
is a big old whoopsie. But I think it's fair
to say that it was not Meta's direct fault for
(10:06):
this one. It sounded to me like this was the
third party that arranged to have the database on that server.
But I don't know if Facebook had done that, Like
if Meta had made it available on that server and
then gave access to Cultura Collectiva but failed to secure
that access appropriately, then yes, it would have been Meta's fault.
(10:27):
I honestly don't know the details where I can make
a determination in that regard. Anyway, That's really just the
tip of the iceberg when it comes to data breaches
with Meta slash Facebook. And given the reach of platforms
like Facebook and Watsapp and Instagram, you know, all these
different meta properties, it really should come as no surprise
(10:47):
that any data breach that targets Meta is going to
end up being one of the largest in US history
simply because they have such a huge user base, right like,
just by definition, if it's an effective attack, it's going
to be one of the largest ever. So again, it's
one of those things that you know, it makes Meta
such an attractive target for attackers, the fact that it's
(11:10):
this huge. Okay, we've got lots more to go through,
and rather than start the next entry and then just
have to take a break in the middle, let's take
a break. Now, we'll be back with numbers four and three.
I think, okay, we're back. So number four on our
(11:34):
list of largest data breaches in US history is another
financial institution. So in the last episode, I mentioned how
a twenty fourteen hack on JP Morgan Chase demonstrated that
it wasn't just web based companies that were at risk.
In May twenty nineteen, that lesson was reinforced when poor
data security practices meant the first American financial corporation inadvertently
(11:57):
made it possible for anyone with a particular weblink and
able to access some really sensitive financial information. There was
no hacking required. Literally, all you needed was the URL
and boom you could view a whole bunch of files,
and by whole bunch, I mean nine hundred million files almost,
so you know, more than eight hundred billion. I think
(12:18):
it was like eight hundred and eighty million something along
those lines. So what the heck happened? Well, whomever first
American financial corporation hired to do web design made a
major boo boo, And I'd like to think it was
an honest but dumb mistake and not you know, some
sort of malicious or premeditated attempt to gain access to
sensitive information. So essentially, the web developer failed to include
(12:40):
any sort of authorization or verification process to access this
list of files. So maybe the thought was just that,
you know, the URL for the web directory wouldn't be
published anywhere, so the only people who would even have
access to it were the ones who knew what the
UURL was. And if that was the thought, like if
it was like, oh, we don't need to institute anything
(13:02):
else because this is a private web address, who's going
to see it? That would be a practice that's called
security through obscurity, which by the way, is not very
secure at all. And as the name implies, the hope
is that by flying below the radar of attackers, no
one takes notice of you, so you remain safe, not
because you're practicing really good security, but because no one
(13:24):
has spotted you, and so no one has decided to
target you. Sometimes this isn't something that you're actively practicing,
it's just kind of in effect. I have argued in
the past that Apple enjoyed security through obscurity. For many years,
you didn't see much malware targeting Apple systems. Apple fans
(13:44):
would argue this was because Apple was just better at
security than companies like Microsoft or IBM. In fact, some
of Apple's own ads seemed to me at least to
imply that one advantage Apple computers had over Windows based
PCs is that they were more secure. Now, I would
counter that I don't think Apple was necessarily so much
(14:06):
better at security. I mean, granted, they were using proprietary systems,
including proprietary software and hardware, which does make it harder
to develop malware for those platforms. It doesn't make it impossible,
but it makes it harder. But I think that the
vast majority of people, I don't think this this is true.
The vast majority of people were not using Apple computers.
(14:26):
They were on Windows based machines. So, yeah, there were
people using Apple computers, but if you looked at the percentages,
I mean, Apple was just dwarfed by Windows machines. So
if you are a hacker and you're going to dedicate
the time and effort into developing malware, and you have
a specific goal in mind, whatever that goal might be,
you're more likely going to aim at the largest target
(14:48):
in order to have the biggest impact. Like, that's going
to make more of a difference than affecting a relatively
small population of Apple users. Go for the bigger population
of Windows users. That's security through obscurity, right, Like, yes,
the security might have been better to some degree, but
that's not why Apple was so safe for the longest time.
(15:10):
It was also safe or what was not the only reason?
I guess I should say it was also safe because
the company's market share was small enough that a lot
of hackers just didn't see the return on investment to
develop malware for Apple when most people were using Windows
machines anyway, Whether the thought was that no one who
(15:31):
was unauthorized would even find their way to this URL,
or it was just an oversight and the web developer
failed to take steps that they should have taken the
vulnerability was in place, and this type of vulnerability is
called an insecure direct object reference. So this is just
a category for vulnerabilities, and essentially it just means that
(15:52):
if a user has the ability to submit a specific
input into a system and they can gain access to
that system without having to pass through any control measures,
that is an insecure direct object reference. So in this case,
the input was just a web address, so the only
tool that you needed was a browser. You did not
(16:14):
have to be a hacker. You needed a web browser
and you needed to put a URL into the address
bar and boom, you would be taken to one of
these documents. Now, adding to this problem was the fact
that First American Financial Corporation was using a sequential numbering
system for their documents, which meant if you had discovered
a URL that brought you to one of these documents,
(16:37):
you could then adjust the numeral that was at the
end of the file name, and if you went down one,
then you'd see the previous record, and if you went
up one, you'd see the next record. So what kind
of records are we talking about. Well, it included stuff
like bank statements, receipts, actual bank account numbers, drivers licenses,
(16:58):
and other stuff. Now, on the bright side, while security
researcher Brian Krebs reported on the discovery of the issue,
it appeared that no unauthorized third parties with malicious intent
had actually accessed this information. You could argue, really just
a matter of luck. Also, there was no way to
really know. But it just didn't seem like this stuff
was showing up anywhere where you would say, oh, the
(17:21):
bad guys got hold of this, right. It wasn't like
it was popping up on the dark web. Perhaps because
it seemed that no criminals had found out about this
problem before First American could actually, you know, address it,
the SEC went fairly light on the financial institution, at
least in my opinion. First American was ordered to pay
a five hundred thousand dollars fine. Now, five hundred thousand
(17:43):
dollars is a lot of money. If you hit me
with a five hundred thousand dollars fine, I would be
up the creek. I would be so deep in trouble.
But when you think of like a financial institution and
the fact that this this data leak scope was nearly
a billion records of incredibly sensitive financial information. I think
(18:04):
it's still a fairly light fine to have to pay.
The State of New York would actually secure a million
dollar payout from First American in a lawsuit settlement, so
that was twice as much. Now it may be, and
I haven't looked at this. It maybe that the SEC
just had limitations on how much it could find an institution,
in which case, you know, no fault on them. It's
(18:24):
not like it's not like they could do more. If
you throw the book at someone, you don't typically assume
the person has a second book to throw. More recently,
First American was in the news again in late twenty
twenty three when hackers claiming to be part of the
infamous Alpha and black Cat groups infiltrated company systems and
encrypted several directories as a ransomware attack. Now, this disrupted
(18:47):
First Americans operations for a short while, but the company
assured the public that the attackers had failed to lock
off anything that was absolutely critical for operations, and at
first they believe that customer records weren't act. However, very
recently First American revealed that quote personal information pertaining to
approximately forty four thousand individuals may have been accessed without
(19:09):
authorization as a result of the incident. End quote. This
is according to the title report dot com. So the
company is going to be contacting those who are potentially
affected and offer identity protection services and credit monitoring for
free for you know, some amount of time. I don't
know for how long. Number three on our list is
a real estate education company. It is called the Real
(19:31):
Estate Wealth Network. Now, before I did any research on
this episode, I had not heard about this particular data breach.
This one I just missed. When it happened, it was
big news, and somehow I didn't see it, And it
really was a data leak. So similar to what we
just talked about with First American. As opposed to you know,
hackers compromising a system, this is more of a company
(19:52):
failing to put in the proper measures to protect information.
Before I read about this particular situation, my imagination went wild, right,
because it's the Real Estate Wealth Network. I in my
imagination thought, aha, this is going to be a story
about some sort of crypto anarchist, right, because here's a
(20:15):
company that's dedicated to teaching folks how to build wealth
by buying up real estate in many parts of the
United States. Right now, we're in sort of a housing crisis.
There are a lot of middle class Americans who cannot
afford to buy a house, which is a change from
previous generations. Right like, you have people who are in
the same relative space in middle class, who, unlike earlier generations,
(20:40):
cannot buy an average home or a suitable home. So
the housing prices have skyrocketed in various regions throughout the
United States in recent years, and a lot of properties
seem to get scooped up by people or companies determined
to turn the houses into lucrative vacation rental properties a
la Airbnb and such. So I am imagine this data
(21:01):
breach was the work of some crypto anarchist akin to
the main character in v for Vendetta. You know, a
person who was determined to take down the system by
targeting a wealth generation platform that by its very existence
seemed to put the common person at a disadvantage. But no,
it's nothing quite so dramatic as that. This is another
case of a company failing to institute basic security measures
(21:23):
in place in order to protect sensitive information. So let's
talk about that information first, and then I will talk
about what actually happened. So the leaked info included all
the top hits, you know, your basic stuff like customer names,
their phone numbers, addresses, that kind of thing. But it
also included other stuff like tax IDs, or whether or
(21:45):
not the entity that owned the property had ever gone
through bankruptcy, or if there were any court judgments against
the property owner. Obviously, it also included property history records
like when it was bought and sold and who bought
it or sold it. And there were a lot of
these data records, or like a one and a half
billion data records in total. Some of them included information
(22:08):
about very notable people, you know, like politicians and celebrities
and that kind of thing. And you could imagine this
sort of crime meant that the people who had access
to this information could do all sorts of other crimes,
everything from spearfishing, which would be a breeze because you
would have so much information about your target, you could
craft a very convincing attack that would potentially compromise them further.
(22:34):
You would have all the information you needed to commit
some pretty nasty fraud crimes in the name of some
of these victims. Not to mention now that you have
these notable people like politicians and celebrities. You have information
that you know, stalkers would really like, or people who
have a particular desire to hurt somebody specific they might
really want the information. So yeah, there's a whole host
(22:55):
of crimes that can happen as a result of this.
So what actually happened? How did this come about? Well,
the simple explanation is that the Real Estate Wealth Network
failed to put any security around accessing this database, which
held one point one six terabytes of information in it.
There was this security researcher named Jeremiah Fowler who discovered
(23:16):
the problem. He found an unencrypted, massive database containing extremely
sensitive information, and he said he found it after searching
for his own details, and then he followed a trail
that led to this database. So I don't know if
he was just like doing this search just on his
own and that had nothing to do with, you know,
any kind of investigation and just stumbled upon this, or
(23:38):
if he had already heard something about this or suspected
something about it and then started to do some searching
and came across it. Either way, he reported the problem
to the Real Estate Wealth Network, and to their credit,
they promptly locked down access to the database, They closed
off that avenue toward the data, and they also confirmed
that they owned the data base, which again all credit
(24:02):
to Real Estate Wealth Network for doing this. They acknowledged
the data leak, and honestly, that had a real breath
of fresh air to it, because, yes, the leak never
should have happened in the first place, but at least
we're not talking about an incident in which the company
delayed installed for days, weeks, months, or even years before
finally owning up to it. Because spoiler alert number one
(24:23):
on this list did that. It's a company that held
back on disclosing information about a massive data breach for
multiple years. But no, Real Estate Wealth Networks was pretty
quick to disclose this issue, which is really the responsible
thing to do, right, to warn those who have been
affected so that they could be on the lookout for
any signs that malicious actors have accessed that information. However,
(24:47):
despite this responsible approach, you know, you still have to
admit there were some pretty massive problems here. So for
one thing, it was not clear how long that database
had been unsecured, right it could have been unsecured for ages.
It was also unknown whether anyone besides you know, the
security research or Fowler had noticed this issue, because you know,
(25:08):
if criminals had found it, they would have a treasure
trove of data at their fingertips, and they wouldn't likely
just blurred out that they had found it if they
wanted to keep accessing it, although they could have made copies.
And apparently, from what I understand, no one found anything
about this on the dark web, So that's a fairly
good indicator that it was unnoticed by the criminal element.
(25:31):
But I mean, it would have only been a matter
of time. So the fact that Fowler found it and
that Real Estate Wealth Networks responded so quickly, that's really
a good thing. But yeah, this data included you know,
information about actual like celebrities, everyone from Britney Spears to
Elon Musk to Nancy Pelosi. So okay, we're coming down
to our top two entries on this list. Although I
(25:52):
should remind everybody that while I'm presenting this as a
top ten countdown, in episode one was like ten through
five and a half and this is five through one,
I should mention Kyle Chen did not claim that his
list was ordered in any kind of ranked way. He
listed twenty six different data breaches, and I don't wish
to imply that this is Kyle Chin's ranking. I just
(26:15):
chose to interpret it that way. So I'm just an
Internet hack. Really. Maybe at some point I'll do an
episode covering the other sixteen data breaches. But we're gonna
take a quick break right now for some more messages,
and when we come back, we're gonna keep on hacking. Okay,
(26:41):
we're back, and I mentioned before the break, we're gonna
keep on hacking. And hacking actually does play a part
in numbers two and one, right, because the last two
those weren't really data breaches. Those were data leaks. A breach,
I would argue, is when an outsider, a hacker, has
managed to infiltrate a system in some way. They have
(27:02):
breached the security whatever there might be of a system.
Data leaks are when you don't have any security in
place and no one actively has to be like searching
for it. It's just out there and it's available if
you happen to nowhere to look. Well, this is definitely
a breach, not a leak, and it's one that puts
Microsoft in the spotlight. The Culprit was an allegedly China
(27:24):
backed hacker group called Hafnium. The target were Microsoft Exchange servers.
So to be clear, the targets weren't just Microsoft. It
wasn't like the they were going after the company Microsoft.
They were going after companies that were using Microsoft Exchange servers,
So customers of Microsoft. That's who these hackers were going after.
(27:47):
And the entry point was allegedly four separate zero day vulnerabilities.
Now I mentioned in the previous episode. A zero day
vulnerability is one that the person or entity that's responsible
for the softwareware, or system doesn't know about. That's what
makes it a zero day vulnerability. They have zero days
to address any sort of exploit that pops up in
(28:09):
the wild, and zero day vulnerabilities are like gold to hackers.
They represent an opportunity to infiltrate systems without fear of
being stopped or sometimes even detected, and that gives hackers
way more time and opportunities to achieve whatever goals they have,
whether that's stealing information or breaking entire directories as part
(28:30):
of a ransomware attack, or infiltrating systems with malware, whatever
it might be. One zero day vulnerability is bad for
zero day vulnerabilities is really really bad. And on top
of that, some of these vulnerabilities had sort of been
grandfathered in from software that had been out for almost
a decade at that point. One key element that made
(28:51):
this particular attack so devastating was that many of the
customers using Microsoft Exchange kept their own email servers on
company premises or on prem as those in the biz
call it, so in case you're not familiar with that term,
it just means that a company hasn't offloaded everything to
(29:11):
the cloud. At least some of their servers that they're
using are on company property, whether that's in the company
HQ or a data center or whatever. The point is,
they own and operate the server. They're just running the
Microsoft Exchange product on those servers. So these are computers
that are not under the direct supervision of Microsoft. And
(29:33):
that's the important part, and the reason it's important is
that once Microsoft became aware of these vulnerabilities, they could
and they did release security patches to plug up those holes,
which would stop attackers from being able to infiltrate those
Microsoft Exchange servers. But while Microsoft could install these patches
(29:55):
directly onto any systems that were under their direct control.
They couldn't do that with exchange servers that were on
premises on customer property, right because Microsoft doesn't have that access.
You wouldn't want Microsoft to have that access. You know,
the whole reason to have on premises systems is that
those are under your direction and control. So you don't
want to give another party access to that's that's a
(30:18):
security vulnerability. So that meant Microsoft had to send out
messages to their customers that essentially said, hey, you need
to install these security patches asap, like yesterday, and the
customers were in charge of actually following through on that
because they were maintaining their own on premises email servers.
(30:38):
And you know, some companies have it departments that will
respond immediately to these kinds of messages and install those
kind of security patches, but there are cases where that
doesn't happen. Now, sometimes the decision not to implement a
security patch right away is actually done out of a
sense of caution, because occasionally you'll get a patch that
(30:59):
once you install, but it has unintended consequences on your operations,
right it might break something else, And so sometimes companies
won't install a security patch on the initial day of
release just in case that patch causes other issues. They
take a wait and see approach to make sure that
they're not going to interrupt their regular business operations by
(31:21):
installing this patch. But that means that they remain vulnerable
for as long as the patch remains uninstalled. Now, other times,
you might have IT departments that just are not on
top of the ball, and that means some companies would
just go unprotected longer than others. Sometimes you don't really
have an IT department at all, Right, You've outsourced a
lot of stuff, and so you don't necessarily have the
(31:44):
assets in place to be able to install security patches.
You're depending too heavily upon third parties and as a result,
you may not have the staff who has the knowledge
of how to install those security patches. It's possible there
are still some servers out there that aren't protected, though
I hope that's not the case because it has been
(32:04):
like three years since this attack happened, and surely someone
has installed security updates within those three years. But you
never know anyway, what did the attackers actually achieve, what
was their goal and what did they do well by
exploiting these vulnerabilities in Microsoft's software. The hackers gained access
to these infected email servers, and that meant they could
(32:27):
access all the email on that server as if they
were the administrator of the server. They could read everything,
so they could go into any account on that email
server and read stuff. They could send email as someone
else if they wanted to, and they could harvest data
in contacts. They could pull all the information off of
calendars like they could gather a lot of valuable information. Now,
(32:52):
in this case, the targets were companies, not necessarily individuals. However,
if they were able to compromise a company system that
had an individual of interest on it, then they could
pull tons of information about that person as part of
their attack. The attackers were able to compromise the email
servers of around thirty thousand companies in the United States.
(33:14):
Thirty thousand companies, not people like keep in mind, like
these businesses might employ hundreds or thousands of people. They
were also able to compromise another thirty thousand businesses around
the world, so sixty thousand total. Brian Krebs, once again
was the researcher who wrote about these attacks and alerted
the world in general as to what was going on.
The revelation came just a few days after Microsoft had
(33:36):
released emergency security updates. By the way, there are actually
a lot of security researchers out there, the white hat
hacker types, who tend to have a general code of
honor right. If they discover a vulnerability in a system,
typically what they do is they reach out to the
company or person responsible for that system and they alert them.
They say, hey, I found this, it's possible to exploit.
(34:00):
You're gonna want to patch it. And typically they'll give
a little bit of time for the company to respond
to this, and then they'll wait for that response before
they reveal what they know to the public. That's the
responsible way to do it, so that the least amount
of damage is done. However, if a company fails to respond,
like if it doesn't acknowledge the fact that you have
(34:20):
alerted them to this vulnerability at all, well, sometimes researchers
will reveal what they know in an effort to pressure
the company into responding. If they go public and say
this vulnerability exists, then there's suddenly this enormous amount of
pressure on the company to fix it, and then also
warns the customers of that company that the product they're
(34:42):
using isn't secure. However, in this case, Microsoft acted very
quickly and then Brian Krebs reported on it, so back
to Microsoft. US cybersecurity experts determine that the hacker group
Halfnium was responsible for these attacks, and that in turn
Halfnium enjoyed the backing and protection of the Chinese government. Further,
the attacks were assumed to be part of a large
(35:03):
espionage mission to spy upon and steal information from US companies.
In particular, The Guardian reported that the US government, in
the form of the FBI, the Federal Bureau of Investigation,
took a rather extreme step to protect companies by hacking
into infected systems that belonged to various companies that had
(35:23):
failed to mitigate the malware themselves. In order to actually
neutralize the threat, so the FBI hacked into company systems
in order to shut down the malware. The FBI did
not go the extra step to install the security updates
on those systems. But apparently the FBI was fighting hacking
by hacking, I guess, and not directly against the hackers,
(35:44):
but against the same companies that had already been hacked.
When it comes to zero day vulnerabilities. I don't think
there's really anything I can say that's terribly helpful. I mean,
how do you fix a problem if you don't know
there is a problem. So, you know, it might be
tempting to blame Microsoft for leasing software platforms that had
these vulnerabilities in them, but again, if the company has
(36:04):
no awareness that there's an issue, how are they supposed
to fix it? So I think just saying do better
isn't really useful. You see that a lot in the
gamer community. It's very dismissive and snobby, and I hate
it and it's not useful at all. It's not helpful.
So I don't really think that's a viable response. As
(36:25):
for customers, well, there's even less that you can do
as a customer to prevent an attack that leverages a
zero day vulnerability in some tool that your company is using.
The best you can do is beyond the ball when
security patches come out to minimize the risk of becoming
another victim, or to at least temporarily migrate away from
a tool that's been known to have been compromised. Okay,
(36:48):
we're finally up to number one on the list, and maybe,
like I said, I'll do a future episodes to cover
some of the other instances that Kyle Chen mentions. So again,
if you didn't hear me before, these are all coming
from a blog post that Kyle Chen wrote for upguard
dot com, So you can always look up like the
largest data breaches in US history. That'll probably pull that
(37:08):
article up as a result. That's where I'm getting this
particular list. But our number one entry is Yahoo, and yeah,
this one was huge. Also, I can't really say this
one because the word one is deceptive. Honestly, this was
a series of cyber attacks that ultimately resulted in more
than three billion records being exposed to cyber criminals. Three billion.
(37:34):
That's nearly forty percent of the world's population. Though honestly,
that's three billion accounts. I'm sure that some people had
multiple accounts, so it's not the same thing as three
billion people, I guess, But that seems like a fine
point that we don't really need to worry about. If
we do assume that's three billion people, that means if
you were to get ten people together, four of those folks,
(37:56):
or really three point seven eight of them would be
affected by this. But those chances would actually depend upon
where in the world you are, right, Like, if you're
in a more developed part of the world, then the
odds are going to be higher that there'll be more
people there who were affected by this. My analogy only
works if the ten people are randomly selected from all
over the world. But anyway, I'm on a tangent. So
(38:16):
what happened, Well, what happened was a combination of various
hacking techniques, some international intrigue, a company staying quiet about
the whole thing for way too long after finding out
about this intrusion, possibly in an effort to avoid affecting
a massive acquisition deal that was going on with another
big company. Because this story is juicy, y'all. But we
(38:40):
begin in twenty thirteen, and this is when the first
and the largest hack happened, though the public would not
find out about it for another three years. Now. Arguably,
Yahoo itself remained ignorant of this attack for quite some time,
but it would take three years for the US public
to hear that this had happened. Even in that revelation,
(39:04):
Yahoo would downplay how many accounts were affected by a
third in fact, because, as we would later hear in
twenty seventeen, the attack compromised some three billion accounts, but
when Yahoo disclosed this attack to the public back in
twenty sixteen, Yahoo said it was just one billion, which
is weird. I was saying, just is crazy. I mean,
(39:24):
one billion is a number so huge that I cannot
possibly imagine it. So you might as well cop to
all three billion at that point, right, But to be
fair to Yahoo, I do think it's very possible the
company honestly did not have a grasp on how large
this attack actually was at that time. And by large
I do mean every single Yahoo account active or otherwise
(39:46):
was affected by this because the company had lousy security.
There's no getting around it. I don't think that's opinion,
by the way, because in twenty twelve, Yahoo had already
been the target of a different hacker attack that ultimately
compromised nearly half a million accounts. Now half a million
is a drop in the bucket compared to three billion.
It's nothing. But you would think that half a million
(40:09):
compromised accounts would be a serious wake up call to Yahoo,
and it would at least kick things into gears so
that the company would institute better security practices. But sadly,
that didn't really happen, or at least it didn't happen
on a scale and timeline that would prevent the massive
intrusion in twenty thirteen. Now, it is easy to conflate
the twenty thirteen attack with another one that happened in
(40:30):
twenty fourteen. So if you're keeping count, that's three different
hacker intrusions in three years. Twenty twelve was half a million,
twenty thirteen three billion, twenty fourteen was like five hundred million.
I think it is important to draw some distinctions between
these because authorities would ultimately identify four individuals believed to
(40:51):
be responsible for the twenty fourteen attack. These folks would
also end up having alleged ties to the Russian government. Thus,
there are locations that the Yahoo hack in twenty fourteen
was the result of a state backed hacking operation, that
it was essentially funded by the Russians. Now, whether the
twenty thirteen attack was state backed or not, we don't
(41:15):
really know. To this day. As far as I can tell,
no one has the definitive information on who was behind
the twenty thirteen attack. Marissa Meyer, who was CEO of
Yahoo during those data breaches, would testify to Congress in
twenty seventeen that the company had been unable to determine
who was responsible for that particular attack in twenty thirteen.
She also revealed that she did learn of the twenty
(41:37):
fourteen intrusion in twenty fourteen, this is the one that
would affect half a billion accounts, but she didn't learn
of the actual scale of the attacks until twenty sixteen.
So if that's true, it meant the attackers had some
really good ability to hide their tracks and had years
of opportunity there as well. So presumably no one knew
(41:57):
about the twenty thirteen attack until much later. They knew
about the twenty fourteen attack, but they didn't know how
bad it was. This also means I can't really talk
about what happened in twenty thirteen, because the truth of
the matter is there were several potential exploits that the
hackers could have used, and the twenty thirteen attack may
have used multiple avenues to get access to all the information.
(42:18):
We can, however, talk about what happened in twenty fourteen.
We know more about that one. It's a tail that
involves spearfishing and cookies. Now I should also mention this
version of the story comes to us courtesy of the FBI.
The agency said that the hackers first sent spearfishing emails
to Yahoo employees, So again, these are emails meant to
(42:39):
trick someone into taking some sort of action that benefits
the hacker, and in this case, it was clicking on
a link that ultimately would give the hackers administrator level
access to some of Yahoo's systems, but not all of
their systems. But it did give them a chance to
look at some code that Yahoo used that would be
really valuable, and this included code on how Yahoo generated
(43:02):
Internet cookies, So a quick refresher course on what cookies
are and what they do. With the Web, You've got
clients and you've got servers. So if you're browsing the
web on your computer or your smartphone, you're using a client.
Servers are sending or serving you the information that you're requesting.
So if you type in an address in your web
(43:23):
browser like www dot Google dot com, your client sends
a request to go to that website. This request gets
routed to the appropriate web server, which then sends the
data to your client, so that you are visiting Google.
So each interaction is kind of like this. Now, to
save some time and effort, we have cookies. So cookies
(43:43):
are little bits of info that get saved to your
computer the client, and cookies can do really handy stuff.
For example, let's say that you've logged into an account
on a service like Amazon and you're doing some shopping,
and then you navigate a way because you have to
go do something else. But then gush, darn it, you remember, oh, well,
you know what, I should have ordered something else on
top of everything else. So you go back to Amazon. Well,
(44:04):
if you didn't have cookies, you would need to go
all the way back through the login process because Amazon
wouldn't know it was you again. But with a cookie
stored on your computer, Amazon can say, oh, yeah, that's
Billy Bob who logged in earlier, never logged out their
back Let's just let them continue their session. So cookies
are how web pages quote unquote know where you were
(44:26):
the last time you visited, so that you can kind
of pick up where you left off. Of course, cookies
can do more than that, and there's a whole discussion
to be had about tracking and whatnot with cookies, but
we're going to leave that for now. So how did
the attack happen. Well, the hypothesis goes that the hackers
were able to figure out how to forge Yahoo cookies
because Yahoo was not good at practicing decent security, because
(44:50):
ideally each cookie would contain data that's unique to a
single individual and that would be very hard to crack.
But Yahoo apparently wasn't really doing this in that regard.
You could say Yahoo was kind of behaving sort of
like how certain German officers in World War Two were
reusing code phrases while encrypting messages using an Enigma machine. Now,
the practice of reusing those code phrases, that's what gave
(45:14):
British code breakers the advantage that they needed to actually
break the code. If the Germans had used more discipline
security measures, the code likely would have stood up to
the BRIT's best efforts and it wouldn't have ever been broken. Possibly.
I mean, it's impossible to say, because we know what
did happen, it's impossible to say that what could have
happened was a definite possibility. Anyway, all this meant that
(45:35):
the hackers could actually forge a cookie, and they could
fool Yahoo into thinking that the hackers were actually somebody else,
like a legitimate Yahoo user, So it meant that they
could access user accounts and then spy on that user's correspondence,
plus scrape any data relating to that user and their
other online accounts. So potentially they could even compromise even
(45:58):
more data in the process. A right, like if you
figure out a user's username and password, and you also
see that they use other services, you can try and
use that and see if it works. Because so many
people reuse their passwords. I said it in the last episode,
I'll say it again. Don't do that, And you start
to see how a data breach can be much bigger
than just this enormous scope of three billion accounts. So
(46:19):
coy to Marissa Meyer, Yahoo learned about the twenty fourteen attack,
even though they might not have known what the scope was,
but they kept things quiet, possibly in part because there
was this big acquisition deal Verizon wanted to acquire Yahoo.
Some of this news, however, would break before that deal
would be finalized, and Verizon would drop the offer by
(46:39):
a whopping three hundred and fifty million dollars, So that
was a big deduction on the final cost for that acquisition,
and even that might have been too modest. Because, of course,
later we would find out the real scope of those attacks,
lawsuits would follow, but Yahoo would pay out a little
more than one hundred million dollars as a result of
the lawsuits, a few tens of millions here, tens of
(47:02):
millions there in different fines, But honestly, I think it
was a pretty small amount considering the nature and scope
of the attack. Then again, the whole thing did cost
y'all who hundreds of millions of dollars because the acquisition
was reduced in price too. Only one of the four
men identified as hackers in that twenty fourteen attack was
ever arrested and sentenced for this crime was in a
(47:25):
Canadian citizen named Karim Borotov. He was sentenced to five
years in prison. He even wrote a book about his experiences.
The other three accused, which included two members of the
Russian FSB, that's kind of like the successor of the
KGB in the old Soviet days. They were accused, but
they were never arrested, and of course Russia denied having
(47:45):
any involvement in the attacks whatsoever. And that brings us
down to the last of my top ten. Again, I
don't wish to suggest that Kyle Chin had ranked these
in any specific way. This was kind of how I
ranked them, and there were sixteen other ones on that list.
So again, go to upguard dot com and search for
that article about the largest data breaches in US history
(48:06):
if you want to read more about them. Maybe I'll
do an episode about those later. I might do an
episode just about the ticketmaster data breach because that happened.
That are particularly bad time for ticketmasters since it's already
in the crosshairs of the US government due to an
antitrust lawsuit. So maybe I'll do a full episode about
that in the future too. In the meantime, I hope
(48:26):
you're all safe. I hope all your personal information is safe,
and I'll talk to you again really soon. Tech Stuff
is an iHeartRadio production. For more podcasts from iHeartRadio, visit
the iHeartRadio app, Apple Podcasts, or wherever you listen to
(48:47):
your favorite shows.
TechStuff News
Hosts And Creators
Oz Woloshyn
Karah Preiss
Popular Podcasts
United States of Kennedy
United States of Kennedy is a podcast about our cultural fascination with the Kennedy dynasty. Every week, hosts Lyra Smith and George Civeris go into one aspect of the Kennedy story.
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com