WEBVTT
Kind: captions
Language: en-GB

1
00:00:00.099 --> 00:00:04.410
Moonpig is a British company that makes personalised
crap.

2
00:00:04.410 --> 00:00:07.879
If you want some cheap tat with a photo of
someone's ugly baby on it, or if you thought

3
00:00:07.879 --> 00:00:12.550
that sending someone a tacky and overly expensive
card with their name printed on it is a good

4
00:00:12.550 --> 00:00:15.500
gift, Moonpig was your place.

5
00:00:15.500 --> 00:00:20.090
Except: yesterday, a developer called Paul
Price disclosed a security hole which, according

6
00:00:20.090 --> 00:00:25.000
to him, exposed all Moonpig users' personal
details, to the level where you can reasonably

7
00:00:25.000 --> 00:00:27.080
start to pull off identity theft.

8
00:00:27.080 --> 00:00:29.039
So: how did it happen?

9
00:00:29.039 --> 00:00:31.950
Well, first, here's how well-designed apps
work.

10
00:00:31.950 --> 00:00:35.629
You download the app, you log in with your
username and password, they're checked on

11
00:00:35.629 --> 00:00:40.239
the server over a secure connection, and if
they're right the app gets given a token,

12
00:00:40.239 --> 00:00:44.620
a random string of characters, like a browser
cookie, that it can use in place of those

13
00:00:44.620 --> 00:00:46.219
details in future.

14
00:00:46.219 --> 00:00:49.179
That way, you're not storing the user's password
anywhere on the device.

15
00:00:49.179 --> 00:00:53.799
And if the app is built by a different company
entirely, like you have a "Log in with Facebook"

16
00:00:53.799 --> 00:00:57.519
button, or something like that, then there
are extra precautions you can take so that

17
00:00:57.519 --> 00:01:01.620
third-party app never even sees the user's
password for a moment.

18
00:01:01.620 --> 00:01:05.269
The most common one's called oAuth 2, you
can look it up if you're interested.

19
00:01:05.269 --> 00:01:06.269
Okay.

20
00:01:06.269 --> 00:01:10.170
So: send username and password, get token,
use token in future to prove you're authorised.

21
00:01:10.170 --> 00:01:12.369
And that's what Moonpig did.

22
00:01:12.369 --> 00:01:13.369
Except.

23
00:01:13.369 --> 00:01:16.799
That token was always your customer ID.

24
00:01:16.799 --> 00:01:20.820
Now on its own, that is bad, it means you
have no way of revoking that app's permission,

25
00:01:20.820 --> 00:01:25.110
ever, even if someone changes their password,
it means that if someone finds out your customer

26
00:01:25.110 --> 00:01:28.880
ID, they can impersonate you and there's nothing
you can do but close your account, but it's

27
00:01:28.880 --> 00:01:31.590
not truly catastrophic.

28
00:01:31.590 --> 00:01:35.810
Because a well-designed customer IDs will
be a long, randomly generated string, it'd

29
00:01:35.810 --> 00:01:39.140
take thousands of years to guess someone else's...

30
00:01:39.140 --> 00:01:41.119
...yeah, no.

31
00:01:41.119 --> 00:01:43.770
Moonpig's customer IDs were consecutive.

32
00:01:43.770 --> 00:01:50.190
If you were user 51624, them the person who
signed up before you would be 51623.

33
00:01:50.190 --> 00:01:52.780
And the person after you is 51625.

34
00:01:52.780 --> 00:01:57.609
And remember, that's the only token that's
being sent by that app -- or by any malicious

35
00:01:57.609 --> 00:02:01.020
attacker pretending to be that app -- that
customer ID number.

36
00:02:01.020 --> 00:02:03.710
So you didn't need to guess anyone's username
and password.

37
00:02:03.710 --> 00:02:05.679
You didn't need to do any sort of cracking.

38
00:02:05.679 --> 00:02:09.890
You could just send a request to Moonpig's
server, attach someone else's easily-guessed

39
00:02:09.890 --> 00:02:14.540
customer ID, and responses helpfully come
back for them instead of you.

40
00:02:14.540 --> 00:02:18.140
With that, you could get the name on someone
else's credit card, you could get the last

41
00:02:18.140 --> 00:02:21.530
four digits, you could get the expiry date,
and their address.

42
00:02:21.530 --> 00:02:26.050
That's been more than enough data, in the
past, to call up Apple and get into an iCloud

43
00:02:26.050 --> 00:02:28.160
account, at which point it's game over.

44
00:02:28.160 --> 00:02:31.420
Nick their email address, nick their Amazon
Web Services account if they've got one, run

45
00:02:31.420 --> 00:02:35.540
up a ten-thousand-dollar bill mining Bitcoins
on someone else's credit card.

46
00:02:35.540 --> 00:02:40.280
And here's the crucial thing: because those
ID numbers were sequential, a malicious attacker

47
00:02:40.280 --> 00:02:44.220
could run through and grab the details of
every single one of their customers.

48
00:02:44.220 --> 00:02:48.240
There was no rate-limiting, no check to say
"hey, that person's making a lot of requests

49
00:02:48.240 --> 00:02:50.420
there, maybe we should shut them down for
a bit".

50
00:02:50.420 --> 00:02:54.290
It was a near-perfect storm of incompetent
coding.

51
00:02:54.290 --> 00:02:58.310
This isn't one line of code with a bug in
it: these are decisions made by the site's

52
00:02:58.310 --> 00:02:59.310
developers.

53
00:02:59.310 --> 00:03:02.162
Don't get me wrong, I've written code this
bad before, but it was years ago while I was

54
00:03:02.162 --> 00:03:04.620
learning and I wasn't getting paid for it.

55
00:03:04.620 --> 00:03:10.120
Now, credit to Paul Price for not only discovering
this, but for responsibly disclosing it.

56
00:03:10.120 --> 00:03:14.050
After finding the error, he kept quiet, he
alerted Moonpig privately, gave them fair

57
00:03:14.050 --> 00:03:17.010
warning, and only after they didn't solve
it did he publish.

58
00:03:17.010 --> 00:03:20.910
Now, he left it for a year, which is about
eleven months more leeway than he reasonably

59
00:03:20.910 --> 00:03:22.120
needed to give.

60
00:03:22.120 --> 00:03:25.650
In that time, has someone malicious swiped
the details of every customer and kept quiet

61
00:03:25.650 --> 00:03:26.650
about it?

62
00:03:26.650 --> 00:03:28.120
We have no idea.

63
00:03:28.120 --> 00:03:31.890
Paul's report says he was also careful not
to pull down details of any customer otherthan

64
00:03:31.890 --> 00:03:34.591
himself, and the test users he set up to check
the bug.

65
00:03:34.591 --> 00:03:38.010
Remember, if you're playing about with things
like this, there is a non-zero chance that

66
00:03:38.010 --> 00:03:42.320
a company will try and sue you, or report
you to the police, rather than solving the

67
00:03:42.320 --> 00:03:45.200
security hole: there's a lot of risk and not
all that much glory.

68
00:03:45.200 --> 00:03:48.480
Now, I've found a couple of things like this
in the past -- fortunately both times, the

69
00:03:48.480 --> 00:03:53.710
companies in question solved them within 48
hours and said thank you.

70
00:03:53.710 --> 00:03:57.200
There are two lessons here: one for developers,
I'll get to that in a minute, and one for

71
00:03:57.200 --> 00:03:59.650
the people non-technical who hire them.

72
00:03:59.650 --> 00:04:04.090
If you're not technical, but you're listening
to this and thinking "oh no, is our site vulnerable?"

73
00:04:04.090 --> 00:04:05.570
Get someone to test it.

74
00:04:05.570 --> 00:04:09.930
Even better, if you have the budget, hire
someone outside your company to test it.

75
00:04:09.930 --> 00:04:11.410
The search term you need is "pentest".

76
00:04:11.410 --> 00:04:17.590
And when someone reports a security bug, get
it fixed, say thank you, don't go into PR-spin

77
00:04:17.590 --> 00:04:18.690
mode and ignore it.

78
00:04:18.690 --> 00:04:23.190
On that note, I did ask Moonpig for comments
this morning, and gave them the whole day

79
00:04:23.190 --> 00:04:27.760
to reply: their PR company very quickly sent
their press statement, which says: "We can

80
00:04:27.760 --> 00:04:33.290
assure our customers that all password and
payment information is and has always been

81
00:04:33.290 --> 00:04:34.290
safe".

82
00:04:34.290 --> 00:04:37.000
Now that is a suspiciously specific denial.

83
00:04:37.000 --> 00:04:40.820
They didn't mention addresses, or impersonation,
or anything else, or really any of the claims

84
00:04:40.820 --> 00:04:41.820
at all.

85
00:04:41.820 --> 00:04:45.930
I did ask about that, and if "payment information"
included the last four digits of card numbers:

86
00:04:45.930 --> 00:04:48.880
as I record this, seven hours later, they
haven't replied.

87
00:04:48.880 --> 00:04:53.000
They have, however, shut down the bit of their
site that the app worked with.

88
00:04:53.000 --> 00:04:56.040
If they do get back to me, I'll add it to
the video description.

89
00:04:56.040 --> 00:05:01.240
And developers: if you're making anything
that stores private information, code like

90
00:05:01.240 --> 00:05:02.500
you're being attacked.

91
00:05:02.500 --> 00:05:03.930
Because you will be.

92
00:05:03.930 --> 00:05:05.090
Never trust user input.

93
00:05:05.090 --> 00:05:10.410
Assume that anyone sending anything to your
site is malicious until proven otherwise and

94
00:05:10.410 --> 00:05:11.970
prepare for the worst.

95
00:05:11.970 --> 00:05:14.590
Don't think "ah, nobody'll ever notice this"
-- they will.

96
00:05:14.590 --> 00:05:16.560
Instead, think "how could I break this?".

97
00:05:16.560 --> 00:05:20.160
Because I guarantee you, there will be someone
out there who's thinking that too.