1
00:00:04,760 --> 00:00:08,119
Welcome to Crying Out Cloud, the
podcast that will make you 

2
00:00:08,119 --> 00:00:12,920
laugh, cry, and reconsider all 
of your cloud security fears. 

3
00:00:13,360 --> 00:00:17,800
I'm Eden and I'm here with my 
amazing Co host Amitai. 

4
00:00:18,240 --> 00:00:21,320
Hello. 
Amitai, what are we going to 

5
00:00:21,320 --> 00:00:24,680
talk about today? 
So today we're going to talk 

6
00:00:24,680 --> 00:00:28,840
about React to Shell, the 
vulnerability that lit the 

7
00:00:28,840 --> 00:00:36,080
Internet on fire, Shai Hulud, 2 
Point O and a zero day in gogs. 

8
00:00:37,160 --> 00:00:39,680
And finally, we'll be talking 
about is a vulnerability 

9
00:00:39,680 --> 00:00:44,520
affecting Apache Tikka. 
OK, for the first one, RAC to 

10
00:00:44,600 --> 00:00:51,160
shell it is a vulnerability in 
React server components. 

11
00:00:51,440 --> 00:00:54,960
It's a software library for 
front end apps, but it 

12
00:00:54,960 --> 00:00:57,280
essentially runs React on the 
back end. 

13
00:00:58,240 --> 00:01:02,480
What was interesting about this 
is it went down as an embargo. 

14
00:01:02,560 --> 00:01:07,000
What happened exactly? 
So what happens with sort of big

15
00:01:07,000 --> 00:01:12,520
bugs like this where the people 
who discover it or the vendor 

16
00:01:13,640 --> 00:01:16,480
whose products are affected, if 
they know that this is going to 

17
00:01:16,480 --> 00:01:18,840
cause a splash and if they know 
that this is something that's 

18
00:01:18,840 --> 00:01:20,800
going to be heavily exploited, 
or if they have a feeling it's 

19
00:01:20,800 --> 00:01:24,160
going to be, then they'll 
basically place an embargo on 

20
00:01:24,160 --> 00:01:27,080
the information and share it 
with a few select other 

21
00:01:27,080 --> 00:01:30,600
companies or researchers. 
Part of the goal there is to 

22
00:01:31,440 --> 00:01:35,920
make sure that vendors that use 
the software heavily have chance

23
00:01:35,920 --> 00:01:38,600
to patch before the 
vulnerability becomes public. 

24
00:01:38,840 --> 00:01:41,840
Most big companies have have a 
pretty good way of doing going 

25
00:01:41,840 --> 00:01:44,000
about this and making sure that 
things stay under wraps. 

26
00:01:44,400 --> 00:01:48,160
Sometimes this stuff leaks ahead
of time that has happened before

27
00:01:48,440 --> 00:01:52,200
and then the embargo is 
essentially broken and they need

28
00:01:52,200 --> 00:01:54,760
to to publish the vulnerability 
ahead of time, which isn't 

29
00:01:54,760 --> 00:01:57,040
great. 
The reason they do this in the 

30
00:01:57,040 --> 00:02:00,280
1st place is just because once 
you publish A vulnerability once

31
00:02:00,280 --> 00:02:02,520
everybody knows about it, It's a
race against time until it gets 

32
00:02:02,520 --> 00:02:05,320
exploited. 
So you want to give defenders 

33
00:02:05,320 --> 00:02:06,880
advantage? 
Yeah. 

34
00:02:06,880 --> 00:02:09,479
And this one specifically is 
big, right? 

35
00:02:09,479 --> 00:02:12,240
Like in this case, the embargo 
was important because it had 

36
00:02:12,240 --> 00:02:16,960
like a lot of impact, a lot of 
potentially or actually impacted

37
00:02:16,960 --> 00:02:20,080
environments. 
So React itself is incredibly 

38
00:02:20,080 --> 00:02:21,760
popular. 
Many people use it. 

39
00:02:22,480 --> 00:02:27,160
React Server components is a bit
rarer, but specifically it is 

40
00:02:27,160 --> 00:02:31,600
being used in something called 
Next JS, which is a very, very 

41
00:02:31,600 --> 00:02:34,720
popular library used by tons of 
websites. 

42
00:02:35,440 --> 00:02:38,800
Our data shows that a very large
percentage of cloud environments

43
00:02:39,000 --> 00:02:42,320
use Nix JS and for this 
vulnerability specifically, 

44
00:02:43,320 --> 00:02:48,560
around 50% of environments had 
this vulnerability somewhere in 

45
00:02:48,560 --> 00:02:51,520
their environment, even on 
whether it was internal or or 

46
00:02:51,520 --> 00:02:55,200
external resources. 
And around 10% actually had it 

47
00:02:55,200 --> 00:02:58,960
exposed from the outside, like 
actually validated as 

48
00:02:58,960 --> 00:03:01,280
exploitable, which is a very 
large number. 

49
00:03:01,680 --> 00:03:04,200
Yeah, huge. 
And who took advantage of this? 

50
00:03:04,640 --> 00:03:10,680
So basically everyone, a bunch 
of a bunch of vendors, including

51
00:03:10,680 --> 00:03:13,240
ourselves, started putting out 
information about this 

52
00:03:13,240 --> 00:03:16,080
vulnerability saying, OK, we're 
starting to see exploitation, 

53
00:03:16,080 --> 00:03:18,120
We're starting to see PO CS 
popping up. 

54
00:03:18,520 --> 00:03:23,120
And then within a few days, I 
think Google and a few other 

55
00:03:23,120 --> 00:03:26,760
companies were already claiming 
that Chinese productors were 

56
00:03:26,760 --> 00:03:30,760
taking advantage of this and, 
and exploiting this immediately.

57
00:03:30,760 --> 00:03:33,160
We saw usage of this for crypto 
mining. 

58
00:03:33,160 --> 00:03:37,320
We saw usage of this for all 
sorts of purposes, both cyber 

59
00:03:37,320 --> 00:03:41,960
criminal and and nation state. 
That's what happens when you 

60
00:03:41,960 --> 00:03:44,680
have a really good and really, 
really widespread vulnerability.

61
00:03:44,840 --> 00:03:47,160
You're you're going to use it. 
It was funny because while the 

62
00:03:47,160 --> 00:03:49,840
real exploits were dropping, 
there were also like a lot of 

63
00:03:49,840 --> 00:03:53,440
fake proof of concept exploits 
going around, which creates a 

64
00:03:53,440 --> 00:03:56,280
bit like a fog of foggy 
situation. 

65
00:03:57,240 --> 00:04:01,200
But some of the AI ones, we're 
doing something. 

66
00:04:01,280 --> 00:04:03,080
I don't think it's funny. 
I think it's funny they were 

67
00:04:03,080 --> 00:04:07,480
leaving like helpful comments in
the code which no actual 

68
00:04:07,480 --> 00:04:12,120
attacker would do. 
So it was clearly an AI POC. 

69
00:04:12,760 --> 00:04:14,920
Yeah, that was fun to see. 
Like in the beginning they were 

70
00:04:15,560 --> 00:04:19,240
they were completely fake, like 
they were just someone made a 

71
00:04:19,240 --> 00:04:23,040
best effort using CHA GPT, 
decided to publish it, decided 

72
00:04:23,040 --> 00:04:25,040
to scan the Internet with it. 
It didn't really work. 

73
00:04:25,560 --> 00:04:30,120
And within a few days, things 
started to look a bit more a bit

74
00:04:30,120 --> 00:04:32,240
more interesting and a bit more 
more impactful. 

75
00:04:32,960 --> 00:04:34,960
But the ones that were impactful
was interesting. 

76
00:04:34,960 --> 00:04:36,560
Is that a bunch of more file 
list? 

77
00:04:36,560 --> 00:04:38,720
Like they didn't leave a trace 
on the disk, which made them 

78
00:04:38,720 --> 00:04:41,280
hard to detect if you didn't 
have an agent. 

79
00:04:41,880 --> 00:04:43,000
Yeah, that was really 
interesting. 

80
00:04:43,600 --> 00:04:47,880
Generally, because of the way 
that node, that next JS is 

81
00:04:47,880 --> 00:04:51,840
working, this basically caused 
the situation where a lot of the

82
00:04:52,520 --> 00:04:55,640
activity didn't really leave any
trace on the disk, so you needed

83
00:04:55,640 --> 00:05:00,040
to have some sort of runtime 
protection, some sort of EDR in 

84
00:05:00,040 --> 00:05:03,000
order to to be aware of what was
going on. 

85
00:05:03,960 --> 00:05:06,400
There wasn't much logging, at 
least not by default. 

86
00:05:06,840 --> 00:05:11,840
We actually looked into what 
logs our customers should enable

87
00:05:11,920 --> 00:05:14,440
to make it a bit easier to to 
track this stuff, but none of 

88
00:05:14,440 --> 00:05:18,080
the stuff is enabled by default.
So what should people do in a 

89
00:05:18,080 --> 00:05:20,440
situation like this? 
Well, at this point it's very 

90
00:05:20,440 --> 00:05:27,080
easy to test if you are. 
If you are exposed to this, our 

91
00:05:27,080 --> 00:05:31,520
recommendation, as always, is to
patch and focus on a publicly 

92
00:05:31,520 --> 00:05:36,480
exposed applications. 
Do it Our second story, 

93
00:05:36,760 --> 00:05:41,600
Shyhalood 2 Point O. 
We're already seeing a sequel 

94
00:05:41,600 --> 00:05:44,240
very fast. 
What is the first Shyhalood? 

95
00:05:45,000 --> 00:05:50,800
So Shyhalood was a worm their 
their creator named them after 

96
00:05:51,960 --> 00:05:53,600
named them after the worm from 
Dune. 

97
00:05:55,360 --> 00:05:57,880
Which is unfortunate because 
Dune is great and there are a 

98
00:05:57,880 --> 00:05:59,480
bunch of other things named 
after Dune. 

99
00:05:59,880 --> 00:06:03,000
So this causes confusion. 
We didn't choose the name. 

100
00:06:04,640 --> 00:06:11,360
Anyway, it was a worm that sort 
of burst its way through the NPM

101
00:06:11,720 --> 00:06:16,480
get ecosystem, where basically 
you had a few initial NPM 

102
00:06:16,480 --> 00:06:21,720
packages that were compromised 
by a malicious actor, and then 

103
00:06:23,320 --> 00:06:26,440
they used that access in order 
to publish basically fake 

104
00:06:26,440 --> 00:06:29,400
malicious versions of those 
legitimate packages. 

105
00:06:29,680 --> 00:06:33,040
People downloaded them, and then
that spread to their machines, 

106
00:06:33,040 --> 00:06:34,800
that spread to their CICD 
systems. 

107
00:06:35,240 --> 00:06:39,400
And from there the malware 
automatically searched the 

108
00:06:39,400 --> 00:06:42,600
machine for any credentials they
could find for GitHub or NPM. 

109
00:06:42,880 --> 00:06:45,240
And then they used those 
credentials to basically recurse

110
00:06:45,240 --> 00:06:49,720
through the ecosystem and take 
advantage of whatever access 

111
00:06:50,240 --> 00:06:53,720
those victims had to NPM in 
order to publish more versions 

112
00:06:53,720 --> 00:06:56,720
of the malicious library and so 
on and so forth. 

113
00:06:57,880 --> 00:07:01,440
And the first one was was 
horrible, and a lot of companies

114
00:07:01,440 --> 00:07:03,880
were impacted by this and a lot 
of credentials were stolen this 

115
00:07:03,880 --> 00:07:07,560
way. 
And the second one was it was 

116
00:07:07,560 --> 00:07:10,880
also not great. 
Not great for sure. 

117
00:07:11,600 --> 00:07:15,120
I do think what's interesting 
about this, it's like a low 

118
00:07:15,120 --> 00:07:18,120
level of sophistication, but 
it's incredibly persistent. 

119
00:07:18,400 --> 00:07:22,160
So it was inevitable the second 
one would happen. 

120
00:07:24,240 --> 00:07:26,720
But it is interesting because 
from the first time around, the 

121
00:07:26,720 --> 00:07:32,280
attackers learned they got 
smarter, they made, they didn't 

122
00:07:32,280 --> 00:07:35,960
make the same mistakes twice, 
particularly around when they 

123
00:07:35,960 --> 00:07:38,200
couldn't find credentials on a 
machine. 

124
00:07:38,960 --> 00:07:43,680
The new version works in waves 
where it searches get up for any

125
00:07:43,680 --> 00:07:45,520
credentials that it can pivot 
to. 

126
00:07:45,840 --> 00:07:49,160
Meaning like if they couldn't 
find on my machine credentials, 

127
00:07:49,160 --> 00:07:51,720
but they could find on AMI ties,
they would just use AMI ties. 

128
00:07:52,280 --> 00:07:56,880
Doubled my thing. 
So this had a big scale, but 

129
00:07:56,880 --> 00:07:59,400
it's interesting how it got to a
big scale. 

130
00:07:59,400 --> 00:08:03,160
Can you kind of talk about like 
how they were able to use the 

131
00:08:03,160 --> 00:08:09,680
right packages to get far? 
It seems like the recipe for a 

132
00:08:09,680 --> 00:08:14,320
successful Shankillude style 
campaign, and we don't actually 

133
00:08:14,320 --> 00:08:15,880
know if this was even the same 
attacker. 

134
00:08:16,160 --> 00:08:18,360
It might have been a completely 
different one, there might be 

135
00:08:18,360 --> 00:08:21,400
many, many, many attackers 
working, but it seems like the 

136
00:08:21,440 --> 00:08:25,120
the sort of the recipe here, 
like the the key to success is 

137
00:08:25,120 --> 00:08:29,080
you need to choose your patient 
zeros very well. 

138
00:08:29,960 --> 00:08:33,720
In this case, their patient 
zeros were super popular 

139
00:08:33,720 --> 00:08:36,960
packages that exists across tons
and tons and tons of 

140
00:08:36,960 --> 00:08:39,400
environments that are downloaded
like millions of times a week. 

141
00:08:40,960 --> 00:08:44,360
And the way they gained initial 
access to those to the 

142
00:08:44,360 --> 00:08:48,360
irrelevant maintainers was they 
took advantage of what we called

143
00:08:48,360 --> 00:08:51,840
a phone request, which is a 
vulnerability that affects 

144
00:08:52,160 --> 00:08:54,280
GitHub actions that are 
basically misconfigured. 

145
00:08:54,680 --> 00:08:59,240
And it's relatively prevalent. 
And, and the the main thing is 

146
00:08:59,240 --> 00:09:02,320
that it's very easy to find. 
There's a lot of open source 

147
00:09:02,320 --> 00:09:05,040
tooling out there, like 
offensive security tooling that 

148
00:09:05,040 --> 00:09:08,680
basically anyone can run across 
any repository in the world. 

149
00:09:09,840 --> 00:09:13,240
And, you know, they just scam 
GitHub all the time. 

150
00:09:13,280 --> 00:09:16,080
The second they find that a type
of on the bill like that, they 

151
00:09:16,080 --> 00:09:19,320
exploit it, they steal the keys.
And then, you know, they they 

152
00:09:19,560 --> 00:09:22,080
take advantage of the of the 
fact that they now have the 

153
00:09:22,080 --> 00:09:26,920
ability to publish a version of 
a super popular package to just 

154
00:09:27,280 --> 00:09:29,120
trojanize that package and 
insert malware. 

155
00:09:30,080 --> 00:09:34,600
And in this case, there were 
around 10 packages owned by, I 

156
00:09:34,600 --> 00:09:37,520
think like two or three vendors 
that got popped in this case. 

157
00:09:38,000 --> 00:09:44,640
And that was enough to 'cause 
this to be to propagate through 

158
00:09:44,640 --> 00:09:47,400
the entire ecosystem really, 
really, really, really quickly. 

159
00:09:47,560 --> 00:09:52,520
The key here is the attacker 
needs some way to hijack super 

160
00:09:52,520 --> 00:09:55,520
prevalent packages and from 
there they can just go to town. 

161
00:09:56,680 --> 00:09:59,400
How can you protect yourself? 
So that's a good question. 

162
00:09:59,440 --> 00:10:02,280
If there's a sort of a shared 
responsibility model here that 

163
00:10:02,280 --> 00:10:06,960
we need to consider, there are 
things that NPM, GitHub, GitLab,

164
00:10:07,480 --> 00:10:11,400
pipee, etcetera can do here to 
make this a lot more difficult 

165
00:10:11,400 --> 00:10:15,920
to happen in the 1st place. 
Like making sure that you can't 

166
00:10:15,920 --> 00:10:21,240
publish a version of your 
package to NPM without MFA, for 

167
00:10:21,240 --> 00:10:22,840
example. 
And that is something that that 

168
00:10:22,840 --> 00:10:28,600
NPM is starting to work on. 
And you could also, in terms of 

169
00:10:28,600 --> 00:10:32,240
the GitHub action, you could 
make the Pone request a thing of

170
00:10:32,240 --> 00:10:34,600
the past by just making a lot 
more difficult to exploit. 

171
00:10:34,880 --> 00:10:37,120
That's also something that 
GitHub is is improving, 

172
00:10:37,680 --> 00:10:41,280
improving out a lot in terms of 
what you can do as an 

173
00:10:41,280 --> 00:10:44,600
organization to prevent yourself
from being exposed to this sort 

174
00:10:44,600 --> 00:10:46,480
of thing. 
First of all, if you don't want 

175
00:10:46,480 --> 00:10:50,520
to become patient zero, you need
to make sure that you are have a

176
00:10:50,520 --> 00:10:55,800
super hardened release system 
where you never publish anything

177
00:10:55,800 --> 00:11:01,560
unless you intend to, where you 
have review and control over 

178
00:11:02,160 --> 00:11:05,880
every, every time you you 
publish a a version to a version

179
00:11:05,880 --> 00:11:09,920
10 PM, you want to make sure 
that you don't have any 

180
00:11:11,000 --> 00:11:13,440
credentials for your maintainers
lying around anywhere. 

181
00:11:14,480 --> 00:11:17,080
There's a lot of really basic 
things you can do to make sure 

182
00:11:17,080 --> 00:11:19,760
that you are not the next 
patient zero to this in terms of

183
00:11:19,760 --> 00:11:23,000
preventing yourself from being a
victim here, from being like a 

184
00:11:23,000 --> 00:11:25,640
carrier of the worm. 
The easiest thing you can do is 

185
00:11:25,640 --> 00:11:29,160
just not download the latest 
version of any package like 

186
00:11:29,160 --> 00:11:31,680
always wait a few days or a 
week. 

187
00:11:32,560 --> 00:11:35,520
That's turned out to be super 
effective at preventing the 

188
00:11:35,520 --> 00:11:38,120
spread. 
It's basically like doing like 

189
00:11:38,120 --> 00:11:41,440
quarantining people during, 
during COVID, I guess, But just 

190
00:11:41,440 --> 00:11:44,080
instead of quarantining in 
space, you're quarantining in 

191
00:11:44,080 --> 00:11:46,320
time. 
Never meet anyone new unless 

192
00:11:46,320 --> 00:11:48,280
they've been around for more 
than a few days and you know 

193
00:11:48,280 --> 00:11:51,920
that they're not sick, I guess. 
And you know, you could use a 

194
00:11:51,920 --> 00:11:54,720
proxy within your organization 
to enforce this. 

195
00:11:55,040 --> 00:11:58,200
You can enforce it at the level 
of the tooling that you use to 

196
00:11:58,200 --> 00:12:00,160
pull packages from, from MPM and
PIPI. 

197
00:12:00,960 --> 00:12:07,160
Lots of things you can do here. 
OK, story #3 Goggs. 0 day Goggs.

198
00:12:07,160 --> 00:12:11,200
If you don't know, it's an open 
source alternative to GitHub. 

199
00:12:11,280 --> 00:12:16,280
And Amitai's team actually 
found, or maybe more precisely 

200
00:12:16,280 --> 00:12:20,240
stumbled into this zero day 
vulnerability. 

201
00:12:21,480 --> 00:12:25,240
What did they find? 
So we weren't looking for 

202
00:12:25,640 --> 00:12:27,600
vulnerabilities in the 
traditional senses, weren't like

203
00:12:27,600 --> 00:12:29,560
we were. 
It wasn't like we were reviewing

204
00:12:29,560 --> 00:12:31,640
the source code and trying to 
find vulnerabilities or anything

205
00:12:31,640 --> 00:12:36,840
like that. 
The first thing that Gili and 

206
00:12:37,160 --> 00:12:39,840
Yala from my team saw when they 
were looking into this was 

207
00:12:40,200 --> 00:12:43,160
basically post exploitation 
activity on a machine that had 

208
00:12:43,160 --> 00:12:48,840
Gogs installed. 
And the machine seemed to be not

209
00:12:48,840 --> 00:12:51,880
at risk, like there were no 
vulnerabilities being detected 

210
00:12:51,880 --> 00:12:55,240
on it or anything like that, 
just the malware running there. 

211
00:12:55,880 --> 00:12:58,600
And they started looking into 
this and tried to figure out 

212
00:12:59,520 --> 00:13:01,200
what the mower was doing. 
And then the next question, 

213
00:13:01,200 --> 00:13:03,240
which is an important question, 
is how did they get there? 

214
00:13:04,800 --> 00:13:07,760
And the answer is almost always 
either a vulnerability or a 

215
00:13:07,760 --> 00:13:10,280
misconfiguration. 
And in this case, they couldn't 

216
00:13:10,280 --> 00:13:12,880
find anything. 
So that's when they started to 

217
00:13:12,880 --> 00:13:15,640
look in a bit more deeper into 
the code itself, trying to 

218
00:13:15,640 --> 00:13:17,240
figure out what might have 
happened here. 

219
00:13:17,400 --> 00:13:19,480
And that is how they actually 
found that there is a 

220
00:13:19,480 --> 00:13:24,640
vulnerability affecting Gogs in 
its latest version, and that the

221
00:13:24,640 --> 00:13:27,960
attacker had probably realized 
this a while ago and began 

222
00:13:27,960 --> 00:13:30,760
exploiting this. 
How widely was this exploited? 

223
00:13:30,760 --> 00:13:34,280
Like how big is the territory of
compromise? 

224
00:13:34,680 --> 00:13:38,080
So once they realize that there 
was a vulnerability here, they 

225
00:13:38,080 --> 00:13:42,120
started looking for other cases 
where this might have happened. 

226
00:13:44,400 --> 00:13:48,960
We we looked at scan data to see
where else in the world GOGS is 

227
00:13:48,960 --> 00:13:51,400
exposed. 
It seems to mostly be used in 

228
00:13:51,400 --> 00:13:54,880
Asia. 
And once we start looking into 

229
00:13:54,880 --> 00:13:58,760
this, we actually found that 
like 70 or 80% of all instances 

230
00:13:58,760 --> 00:14:02,280
of this technology that that are
exposed in the world were 

231
00:14:02,280 --> 00:14:05,200
targeted by this attacker, like 
this attacker really went to 

232
00:14:05,200 --> 00:14:06,840
town. 
Who is the attacker? 

233
00:14:06,840 --> 00:14:08,480
Do we know? 
We don't know. 

234
00:14:08,480 --> 00:14:11,480
I mean, they're just an 
opportunistic cybercriminal 

235
00:14:11,480 --> 00:14:16,040
focusing on using compute to 
mine cryptocurrency. 

236
00:14:18,680 --> 00:14:21,440
That's pretty much all we know. 
And is it fixed? 

237
00:14:21,440 --> 00:14:23,120
Like do the maintainers take 
care of it? 

238
00:14:23,680 --> 00:14:26,080
So unfortunately not. 
We reported this a few months 

239
00:14:26,080 --> 00:14:28,880
ago. 
They're taking their time to fix

240
00:14:28,880 --> 00:14:30,920
this. 
That's sort of why we decided to

241
00:14:30,920 --> 00:14:33,440
go public with this. 
We waited a long time and then 

242
00:14:33,560 --> 00:14:35,120
we eventually decided, OK, 
enough's enough. 

243
00:14:35,400 --> 00:14:39,440
So TLDR, don't expose your bogs 
to the Internet. 

244
00:14:40,080 --> 00:14:42,720
Yeah, probably best practice 
anyway, but at the moment that's

245
00:14:42,720 --> 00:14:45,680
really the only option you have 
because you can't patch this. 

246
00:14:46,240 --> 00:14:52,400
Our last story, Apache Tikka. 
Apache Tikka, because you can't 

247
00:14:52,400 --> 00:14:56,640
really tell from the name what 
it is, is APDF parsing library. 

248
00:14:56,800 --> 00:14:59,320
It is used under the hood by 
many apps. 

249
00:14:59,760 --> 00:15:06,120
People want to parse PDFs. 
So to explain how this works, 

250
00:15:06,320 --> 00:15:12,800
imagine you have a cool startup 
that lets people upload PDFs and

251
00:15:12,800 --> 00:15:15,600
you do some sort of AI analysis 
for them. 

252
00:15:15,600 --> 00:15:19,360
Like you read their tax returns 
or something, but they have to 

253
00:15:19,360 --> 00:15:21,680
upload APDF. 
That's the the core thing. 

254
00:15:21,960 --> 00:15:27,600
If they use tika tika tika, an 
attacker can upload a malicious 

255
00:15:27,600 --> 00:15:32,280
PDF that would trigger an RC on 
the server where it's parsed and

256
00:15:32,280 --> 00:15:35,600
then all hell breaks loose. 
I mean Ty and I were talking 

257
00:15:35,600 --> 00:15:37,680
about this before and I was 
talking about how it's really 

258
00:15:37,680 --> 00:15:40,360
hard to triage. 
Can you talk about why? 

259
00:15:41,560 --> 00:15:45,640
So any vulnerability that's 
really prevalent is 

260
00:15:45,640 --> 00:15:51,160
automatically hard to handle 
because you just have a lot of a

261
00:15:51,160 --> 00:15:53,320
lot of cases that you need to 
prioritize between. 

262
00:15:54,000 --> 00:16:00,600
In this case, it's not like you 
can just say like I'm going to 

263
00:16:00,600 --> 00:16:04,320
prioritize publicly exposed 
machines that are running Tikka 

264
00:16:04,640 --> 00:16:10,480
or publish cases where I can, 
where I can see Tikka running 

265
00:16:10,480 --> 00:16:13,240
from the outside when using an 
authenticated scan or something 

266
00:16:13,240 --> 00:16:15,680
like that. 
Because Tikka is running behind 

267
00:16:15,680 --> 00:16:21,600
the scenes. 
And there's also not much you 

268
00:16:21,600 --> 00:16:23,720
can do here. 
And it's not like it's dependent

269
00:16:23,720 --> 00:16:26,480
on how you're using Tikka. 
It's just like if you're 

270
00:16:26,480 --> 00:16:29,480
uploading the PDF, then then 
you're then you're at risk. 

271
00:16:29,480 --> 00:16:32,440
Like if you accept PDF from 
untrusted sources, you're going 

272
00:16:32,440 --> 00:16:34,920
to be at risk. 
And you know, you might have 

273
00:16:34,920 --> 00:16:37,560
Tikka on some like internal 
machine that's getting things 

274
00:16:37,560 --> 00:16:40,760
from a front end. 
So it makes it a bit a bit 

275
00:16:40,760 --> 00:16:44,600
difficult to to prioritize. 
Some of the stuff that we've 

276
00:16:44,600 --> 00:16:49,760
been recommending customers do 
is a, there are cases where 

277
00:16:49,760 --> 00:16:52,560
Tikka is literally exposing the 
server to the Internet. 

278
00:16:52,560 --> 00:16:55,360
It doesn't do that by default, 
but that might exist in your 

279
00:16:55,360 --> 00:16:57,640
organization. 
So that's definitely what you 

280
00:16:57,640 --> 00:17:00,280
should handle first, because 
that's the most at risk. 

281
00:17:01,640 --> 00:17:05,680
Second, you can, if you're able 
to do that, search for cases 

282
00:17:05,680 --> 00:17:08,520
where you can find Tikka 
installed in a machine that also

283
00:17:08,520 --> 00:17:12,680
has a bunch of PDFs like. 
That might indicate that it's 

284
00:17:13,119 --> 00:17:18,200
being used for PDF parsing and 
actually in use. 

285
00:17:19,240 --> 00:17:21,720
And other than that, basically 
focus on cases where you can 

286
00:17:21,720 --> 00:17:24,319
validate in runtime that Tikka 
is actually running. 

287
00:17:25,240 --> 00:17:28,680
Because again, it comes under 
the hood in a lot of cases. 

288
00:17:28,680 --> 00:17:31,440
Like it's bundled along with a 
bunch of other software, but it 

289
00:17:31,440 --> 00:17:34,200
isn't necessarily always in use.
So you should focus on cases 

290
00:17:34,200 --> 00:17:38,280
where you have at least some 
signal that it's actually being 

291
00:17:38,280 --> 00:17:41,040
used. 
Sounds like a solid plan. 

292
00:17:42,840 --> 00:17:48,960
OK what are the pot aways? 
Take a pods from this episode. 

293
00:17:49,360 --> 00:17:54,520
So react to shell patch. 
Not really a lot of options 

294
00:17:54,520 --> 00:17:58,000
here. 
You can use WAFF rules but 

295
00:17:58,000 --> 00:18:02,960
they've been proven as not 
infallible, so best to patch 

296
00:18:04,360 --> 00:18:10,680
Shivalu 2 point O make sure that
if you are an organization that 

297
00:18:10,680 --> 00:18:14,840
is publishing to MPM, make sure 
that you're using MFA to do so. 

298
00:18:15,880 --> 00:18:19,320
And if you are consuming 
packages from MPM, you might 

299
00:18:19,320 --> 00:18:21,120
want to consider. 
Not consuming latest. 

300
00:18:21,440 --> 00:18:25,120
You might want to consider 
having some sort of delay on how

301
00:18:25,120 --> 00:18:28,600
fast you're consuming packages 
because that will give you a 

302
00:18:29,080 --> 00:18:31,920
window in which other people 
might get infected and then 

303
00:18:32,600 --> 00:18:37,720
they'll warn you about it. 
GOG 0 day you can't patch 

304
00:18:37,760 --> 00:18:39,080
because there's no patch 
available. 

305
00:18:39,240 --> 00:18:41,400
So just don't expose gogs to the
Internet. 

306
00:18:42,080 --> 00:18:48,280
Always best practice and Apache 
Tikka patch, but since it's 

307
00:18:48,280 --> 00:18:51,440
incredibly prevalent, you should
probably focus on cases where 

308
00:18:51,440 --> 00:18:54,760
it's literally exposing the 
server to the Internet, or if 

309
00:18:54,760 --> 00:18:58,120
it's being used by an app that 
is being exposed to the 

310
00:18:58,120 --> 00:19:01,560
Internet. 
Or if you can find it on servers

311
00:19:01,560 --> 00:19:04,400
in your environment that have a 
bunch of PDFs, because that 

312
00:19:04,400 --> 00:19:07,680
might indicate that they are 
actually being parsed by 

313
00:19:07,840 --> 00:19:11,160
Bachitika, which means that it 
might be accepting PDFs from 

314
00:19:11,160 --> 00:19:13,840
untrusted sources. 
Maybe not the ABS, but that 

315
00:19:13,840 --> 00:19:15,760
gives you some sort of signal to
work with. 

316
00:19:16,280 --> 00:19:20,080
All right, well, if you enjoyed 
the show, be sure to subscribe 

317
00:19:20,080 --> 00:19:23,440
and share a link to the podcast,
but not your cloud keys. 

318
00:19:23,960 --> 00:19:26,920
And as always, if your cloud 
security strategy is making you 

319
00:19:26,920 --> 00:19:30,760
cry, don't worry. 
Just cry out cloud.