1
00:00:20,070 --> 00:00:29,030
Okay, well, good morning, or good evening, or good afternoon, wherever you are right now.

2
00:00:29,470 --> 00:00:33,950
Welcome to Q&A with Gals Aurore.

3
00:00:33,950 --> 00:00:37,230
We have a little bit of business to take care of first.

4
00:00:37,230 --> 00:00:41,670
This is Gals' first time speaking and presenting at DEF CON.

5
00:00:41,870 --> 00:00:47,290
And not only that, it's also, his wedding anniversary.

6
00:00:47,850 --> 00:00:53,350
And his wedding occurred actually in Las Vegas.

7
00:00:53,350 --> 00:00:56,890
So, unfortunately, as you guys know, we are all stuck at home.

8
00:00:57,590 --> 00:01:05,530
So, we're not ones to let the Rona get in the way of staying fairly well lubricated.

9
00:01:05,530 --> 00:01:10,110
So, to everybody playing the home version of DEF CON.

10
00:01:11,170 --> 00:01:15,670
We have shots here.

11
00:01:16,070 --> 00:01:18,230
There we go.

12
00:01:18,230 --> 00:01:18,810
All right.

13
00:01:18,810 --> 00:01:19,770
So, Gal, here's to you.

14
00:01:19,770 --> 00:01:22,090
Congratulations on making a stage.

15
00:01:22,170 --> 00:01:28,050
Congratulations to your bride on surviving here with a hacker who made it through DEF CON.

16
00:01:28,050 --> 00:01:29,370
So, here's to you.

17
00:01:29,710 --> 00:01:30,910
Cheers.

18
00:01:31,170 --> 00:01:32,530
I'll drink to that.

19
00:01:36,410 --> 00:01:37,750
All right.

20
00:01:38,490 --> 00:01:40,150
Not a bad way to start.

21
00:01:40,150 --> 00:01:40,730
Okay.

22
00:01:40,730 --> 00:01:42,070
I'm glad we did that.

23
00:01:42,630 --> 00:01:43,010
Okay.

24
00:01:43,010 --> 00:01:47,090
So, welcome to Q&A with Gals Aurore.

25
00:01:47,090 --> 00:01:59,010
Gal gave a fantastic presentation on Ruckus wireless gear and some of the problems that seem to be resonant in that over and over and over again.

26
00:01:59,010 --> 00:01:59,610
All right.

27
00:02:00,430 --> 00:02:04,670
So, Gal, why don't you introduce yourself a little bit.

28
00:02:04,670 --> 00:02:09,290
Tell us about yourself in case some folks may be glazed over that part of your presentation.

29
00:02:09,410 --> 00:02:13,050
And we'll start queuing up some of these questions from the audience.

30
00:02:13,870 --> 00:02:14,910
Sure.

31
00:02:14,950 --> 00:02:24,130
So, I work for Adaf Research, which is a part of HCL AppScan.

32
00:02:24,130 --> 00:02:32,470
And I've been doing reverse engineering for something like 10, 11 years.

33
00:02:33,290 --> 00:02:36,590
Especially embedded devices.

34
00:02:36,590 --> 00:02:44,270
This is a subject that I was exploring for a while.

35
00:02:44,270 --> 00:03:05,030
And actually, something that I did not say in my talk, I talked about it in the previous talk, was that the inspiration for this research was because last year I visited DefCon and BlackHat, and I noticed that BlackHat are using this gear.

36
00:03:05,030 --> 00:03:07,270
So, this is what started everything.

37
00:03:07,910 --> 00:03:08,950
Yeah.

38
00:03:10,210 --> 00:03:13,750
You saw them in the wild, like, oh, nope, I gotta do that.

39
00:03:13,750 --> 00:03:14,510
Right, right.

40
00:03:14,510 --> 00:03:21,650
I've heard about them, but I never really had the opportunity to really do a full research.

41
00:03:21,990 --> 00:03:26,430
And yeah, so it turns out to be two research.

42
00:03:26,430 --> 00:03:33,070
One was presented half a year ago in Leipzig, in CCC.

43
00:03:33,250 --> 00:03:48,150
And this one, is the follow-up research that I managed to find additional vulnerabilities and some fixes that did not fix the vulnerabilities I already found.

44
00:03:50,690 --> 00:03:51,870
Well, very good.

45
00:03:51,870 --> 00:03:56,770
So, you found a number of different problems and kind of triggered them to take some action on their part.

46
00:03:56,770 --> 00:04:09,670
Do you know, does Ruckus actually patch any of their gear automatically, such that, you know, what you found and what they did fix or try to fix, did that get pushed out to all the gear worldwide?

47
00:04:10,010 --> 00:04:10,690
Right.

48
00:04:10,690 --> 00:04:16,830
So, as far as I know, Ruckus avoids automatic update.

49
00:04:16,830 --> 00:04:37,270
I understand where it comes from because, you know, pushing an automatic update through the air on network gear might sometimes mess configuration and do some things that you don't necessarily want to happen.

50
00:04:37,290 --> 00:04:41,650
So, I get why they don't push their updates.

51
00:04:41,650 --> 00:05:03,250
But yeah, so the thing I think is the most important from my talks is Ruckus users should stay up to date, you know, even now, even after this, even before my previous research and on this research as well, they need to keep everything up to date.

52
00:05:03,510 --> 00:05:12,890
So, there's a general question out then from Hawkeye Dank about how did Ruckus respond to your research and what sort of a communication did you get back and forth with them?

53
00:05:13,690 --> 00:05:13,950
Yeah.

54
00:05:13,950 --> 00:05:28,070
So, in my research group, I think like most of the research group, we try to do a full disclosure, which is a 90-day disclosure.

55
00:05:28,070 --> 00:05:35,330
And with Ruckus, both the first research and this follow-up research, we gave them enough time.

56
00:05:35,330 --> 00:05:38,270
Eventually, it was a bit more than 90 days.

57
00:05:38,270 --> 00:05:41,350
It was around 100 and so days.

58
00:05:41,430 --> 00:05:46,150
And we just sent them a report with all the things we found.

59
00:05:46,150 --> 00:05:52,650
We just talked about it a bit and they fixed... well, they tried to fix everything.

60
00:05:54,150 --> 00:05:58,470
So, all in all, the disclosure was pretty standard.

61
00:06:02,420 --> 00:06:08,180
It's one of the interesting things to have the conversation with folks about how did your disclosure go?

62
00:06:08,180 --> 00:06:12,780
How did that conversation go with the developers and with the people on that team?

63
00:06:12,780 --> 00:06:19,660
Because there's a lot that you can learn about a company by how that relationship evolves.

64
00:06:19,660 --> 00:06:23,360
So, it's nice to get that data point.

65
00:06:23,380 --> 00:06:24,000
Right.

66
00:06:24,000 --> 00:06:29,780
If I may add something, if we are talking about a disclosure, I think one thing...

67
00:06:29,780 --> 00:06:53,480
this is from my first research and not from this one... I think one thing that took Ruckus by, let's say, a surprise was the fact that I managed to recover a lot of function names from their binaries because they left a lot of debug information both in the debug logs and some assertion in the code itself.

68
00:06:54,400 --> 00:07:01,520
So, yes, when I sent them the report, it was with the right function names and the right architecture.

69
00:07:01,520 --> 00:07:04,380
So, I think it was a bit of a shock for them.

70
00:07:04,380 --> 00:07:15,860
Well, it's a lesson that I bet they learned to try to not give free stuff for hackers.

71
00:07:16,220 --> 00:07:17,380
Yeah, no, that's good.

72
00:07:17,380 --> 00:07:24,220
Well, that goes pretty well with this question about how does owning the device help you with the research that you did?

73
00:07:24,620 --> 00:07:25,400
Oh, yeah.

74
00:07:25,400 --> 00:07:32,840
So, well, yes, my first research was done on emulation, 100% based on emulation.

75
00:07:32,840 --> 00:07:47,020
I just extracted the firmware from Ruckus, and then I managed to emulate most of the device itself, which, well, all the vulnerabilities were found on the web interface.

76
00:07:47,020 --> 00:07:54,200
So, I managed to get the web interface up and running, which included different binaries.

77
00:07:54,200 --> 00:08:04,600
But I think when I got the actual device, when I bought it, so I bought it for live demos and stuff.

78
00:08:04,720 --> 00:08:27,840
And so, when I got the device itself, I could debug and see different things that were more related to the configuration of the device itself, because sometimes the device you get from the firmware, the device you emulate, not necessarily has all the configuration or the binaries,

79
00:08:27,840 --> 00:08:33,140
depends on how the vendor is deploying the firmware.

80
00:08:33,280 --> 00:08:40,720
And, yeah, and when I got the device itself, it really helped me to override the admin credentials.

81
00:08:40,720 --> 00:08:46,920
So, one of the vulnerabilities I demonstrated is admin override.

82
00:08:46,960 --> 00:09:00,170
And I just, by debugging just the binary itself on the device, I could see all the files it tried to, which actually, it was with a simple asterisk, all the files he was opening and writing to.

83
00:09:00,210 --> 00:09:04,990
And this is how I realized those are the configuration files that are important.

84
00:09:04,990 --> 00:09:12,430
And if I manage to override one of them, well, specifically the sys.xml, I would win.

85
00:09:12,430 --> 00:09:14,170
And thankfully, it happened.

86
00:09:14,390 --> 00:09:18,910
Well, so you're definitely not afraid of diving into the technical stuff here.

87
00:09:18,910 --> 00:09:30,290
So, would you talk just a little bit more then about how that was different doing it, how you were able to find those things easier on the physical device than you were with the emulated device?

88
00:09:30,290 --> 00:09:31,770
I'd like to hear more about that.

89
00:09:31,770 --> 00:09:32,370
Right.

90
00:09:32,590 --> 00:09:43,630
So, it's really common in embedded devices that they usually separate the web server and the logic to different binaries.

91
00:09:43,630 --> 00:09:47,870
And usually they find this way to communicate with each other.

92
00:09:47,870 --> 00:09:52,190
It's very popular to use Unix domain socket.

93
00:09:52,190 --> 00:09:54,870
And this is exactly the case in Ruckus.

94
00:09:55,290 --> 00:10:04,270
So, eventually, the web server just talks with other services, with other binaries, with domain sockets.

95
00:10:04,290 --> 00:10:11,970
And at first, when I was emulating the device itself, I was emulating only a single socket to the logic itself.

96
00:10:11,970 --> 00:10:13,150
And that's about it.

97
00:10:13,150 --> 00:10:36,190
But when I had the physical device, just by running a simple PS on the device, I could see all the other binaries that I had to trigger and all the domain sockets they had to use to get everything work together.

98
00:10:36,190 --> 00:10:41,490
So, yeah, that really, really helped a lot with the other research.

99
00:10:41,490 --> 00:10:57,350
That's probably a good thing for a lot of folks who are getting into this field to have some understanding of is you can do a lot from emulation, but there does come a point where having the physical device is going to be a benefit to you.

100
00:10:57,830 --> 00:10:58,510
Right.

101
00:10:58,510 --> 00:10:59,530
I agree.

102
00:10:59,530 --> 00:11:09,470
I think that... well, if you put enough effort, I tend to think that you can get most of the things done by emulation.

103
00:11:09,470 --> 00:11:18,770
Depends, user space, of course, but you can even emulate like the kernel and Ruckus actually gives you the config file for the kernel itself.

104
00:11:18,770 --> 00:11:25,590
So, theoretically, you can just compile yourself the Ruckus kernel, exact kernel, and run drivers and everything.

105
00:11:26,090 --> 00:11:33,630
But, yeah, there's this... when having a physical device really, really speeds things up.

106
00:11:34,230 --> 00:11:42,250
Things that you need to spend some time and understand how to emulate, you just don't need to do it.

107
00:11:42,250 --> 00:11:44,810
So, it really helps.

108
00:11:45,070 --> 00:11:46,510
Very cool.

109
00:11:46,690 --> 00:11:57,970
Once you found out that Ruckus had tried to fix one of the vulnerabilities, how did you then figure out that they didn't fix it properly?

110
00:11:58,910 --> 00:12:00,290
Okay.

111
00:12:00,530 --> 00:12:11,710
So, well, that was kind of a hunch, because... so, my first research, I found several bugs.

112
00:12:12,650 --> 00:12:18,490
And I... so, when I got the fix, I was going through them.

113
00:12:19,010 --> 00:12:34,230
But I realized that the function they're using to validate the... actually, everything that they are validating, all the inputs from the user are... well, let's say it's not like airtight.

114
00:12:34,230 --> 00:12:38,990
It's not... they got some bad practices there.

115
00:12:39,410 --> 00:12:48,890
And hopefully, I was managed to find these three primitives, which were the new line, the shabang, and slash.

116
00:12:48,890 --> 00:13:00,030
And thankfully, with those primitives, I was able to understand that this validation function is not doing a good enough job.

117
00:13:00,030 --> 00:13:06,210
And that's how I got the injection again, to get the command injection back to work.

118
00:13:06,210 --> 00:13:27,690
So, from the perspective of a bug hunter doing this work, would you, in the future, change the way you wrote your bug report and sent that in to help the team come up with more of these... to fix more of the... to fix more of your avenue in?

119
00:13:27,690 --> 00:13:30,250
Or would you do it the same way in the future?

120
00:13:30,250 --> 00:13:33,370
You give them the... this is the area that I hit.

121
00:13:33,370 --> 00:13:37,370
And how would you structure that in the future, knowing what you know now?

122
00:13:37,410 --> 00:13:37,970
Right.

123
00:13:38,130 --> 00:13:49,330
So, I think that... well, I did not know that they're using this... so, apparently, this validator function was been there the entire time, even before my research.

124
00:13:49,330 --> 00:13:56,090
It was using this bad validation function, like, since the beginning of the first research.

125
00:13:56,170 --> 00:14:16,190
I would... if I would knew that they're going to use this function, and actually, I did not knew this function even exists, but if I knew that they're going to use it, I would definitely tell them to use a different function with a more robust white list or black list,

126
00:14:16,190 --> 00:14:17,850
to be exact.

127
00:14:19,330 --> 00:14:31,430
Do you think any of those vulnerabilities, like that function that you were just talking about, do you think that is present in other similar devices that are out there?

128
00:14:31,430 --> 00:14:37,870
Or do you think that was kind of a custom rolled thing from Ruckus that it's going to be a one and done kind of deal?

129
00:14:39,730 --> 00:15:00,630
Yeah, so, I think by the name of the functions, because a lot of, as I said before, a lot of information I managed to extract from the debug functions and debug logs in Ruckus, and because a lot of them are Ruckus related, I think that's only Ruckus code base.

130
00:15:00,630 --> 00:15:17,830
I don't think that other vendors are using this code, but what I did realize, and I already mentioned it in the research, I did realize that they're using this code base for for more than one product line.

131
00:15:17,830 --> 00:15:28,510
So, for both of the product line, also the Wi-Fi controller, as well at the access point, they all use the same code base, and that's why they were vulnerable to...

132
00:15:29,070 --> 00:15:31,810
both of them were vulnerable to some of the attacks.

133
00:15:33,790 --> 00:15:34,790
I like this.

134
00:15:34,790 --> 00:15:36,450
Hawkeye Dank has the question.

135
00:15:36,450 --> 00:15:39,630
Did you find a way to brick the Ruckus?

136
00:15:40,430 --> 00:15:41,410
Brick?

137
00:15:42,110 --> 00:15:43,290
No, actually.

138
00:15:43,290 --> 00:15:48,830
So, at first, yeah, while doing emulation, it wasn't even in my mind.

139
00:15:48,830 --> 00:15:58,990
But, of course, when I bought an actual device, I bought two, of course, because I already broke some devices back in the time.

140
00:15:59,610 --> 00:16:15,530
So, I don't think, because I was dealing with user space and nothing that was too deep in the internals of the device, I did not manage to brick it.

141
00:16:15,530 --> 00:16:33,870
Although that, well, it was for another research, but I realized that if you write echo, any echo, right, the A character to slash dev slash asterisks, usually the device gets bricked.

142
00:16:34,070 --> 00:16:35,790
That happened to me before.

143
00:16:35,790 --> 00:16:42,450
I don't even know why I did that, but I just, I think it was like a last resort.

144
00:16:42,450 --> 00:16:44,090
I was like, okay, nothing works.

145
00:16:44,090 --> 00:16:49,790
Let's try to echo to the entire dev, and that worked poorly.

146
00:16:51,290 --> 00:16:53,170
That's good to know.

147
00:16:53,770 --> 00:16:54,490
Yeah.

148
00:16:55,070 --> 00:17:02,230
So, yeah, no rm slash, rm minus rf slash, and no slash dev asterisks.

149
00:17:03,450 --> 00:17:07,070
I'll keep that in mind the next time I'm hunting around in these things.

150
00:17:07,070 --> 00:17:14,910
So, in the stack overflow, did you have to use any sort of brute force to overcome the ASLR?

151
00:17:15,630 --> 00:17:16,410
Yes.

152
00:17:16,410 --> 00:17:40,890
So, well, so this stack overflow, I was lucky enough to just base it, so the same payload for my first stack overflow, although they were in different binaries, the library that I was using to create the rope chains were both in libc.

153
00:17:40,890 --> 00:17:46,230
So, I only had to fix the addresses, and basically I used the same gadgets.

154
00:17:46,930 --> 00:18:05,630
But the thing is, so in my first stack overflow, back in my first research, I was trying to deal with the ASLR in a non-brute force way, yeah, just to not to, you know, to create something a bit more robust.

155
00:18:05,850 --> 00:18:16,910
And I just decided after I found the command injection, I just decided to ditch it, because, you know, there's already an easier exploit for it.

156
00:18:16,910 --> 00:18:21,970
So, let's just see, like, let's do a POC for the stack overflow.

157
00:18:24,910 --> 00:18:41,370
And on, okay, so with this research, I realized that because this is a different binary, this is the web server binary, which is way more bigger than the ZAP binary from my first research.

158
00:18:41,630 --> 00:18:52,550
So, I think I can overcome the ASLR not by doing brute force, maybe just, you know, take something from the binary itself and use it.

159
00:18:52,550 --> 00:19:08,670
But again, because I already, because I found and command injection as well, so I just decided to stick with the most basic POC, because the command injection, in my opinion, is way more, it's not way more critical, but it's just different.

160
00:19:08,670 --> 00:19:10,190
It's easier to exploit.

161
00:19:16,010 --> 00:19:17,650
You're talking about the web server.

162
00:19:17,650 --> 00:19:23,910
Can you talk more about the web server correlation with the binary?

163
00:19:24,890 --> 00:19:25,970
Yeah.

164
00:19:26,890 --> 00:19:40,510
So, as I said, as I mentioned before, so the web server is, and it's super common for embedded devices, it just communicates with different processes, with different binaries.

165
00:19:40,590 --> 00:19:47,690
And one in particular was this, like, the device logic called EMFD.

166
00:19:47,690 --> 00:19:59,950
So, this binary is the one that actually executes the commands and just do, like, network configuration and just about everything.

167
00:19:59,950 --> 00:20:15,070
And the interesting part about this binary is that Ruckus, so they, Ruckus were using this embedded JavaScript developed, I think, by EmbedDisk.

168
00:20:15,070 --> 00:20:18,470
I'm not sure if this is theirs, but I think, so they work together.

169
00:20:18,470 --> 00:20:27,450
EmbedDisk, which is the web server, supports the embedded JavaScript, E-M-E-G-S.

170
00:20:27,910 --> 00:20:43,910
And so this back server, or back-end JavaScript, that was the one that, this is the language they use to trigger different functions that would be sent to different binaries.

171
00:20:43,910 --> 00:21:07,090
So, I get into it in the first, in my first talk, but also in my second, that, so they added a code to trigger these functions that were using the domain socket that I talked about to just pass commands to different binaries.

172
00:21:07,090 --> 00:21:09,650
And some of them were vulnerable.

173
00:21:12,960 --> 00:21:22,640
Hawkeye Dank does ask the question here, he's talking about you found cross-site scripting and some other exploits, which looks like he's specifically wondering about Csurf vulnerabilities.

174
00:21:22,640 --> 00:21:24,160
Did you find any Csurf in there?

175
00:21:25,440 --> 00:21:53,560
No, actually, so the entire Csurf token in, I didn't pay too much attention to it, because, so in one of the pages, or in some of the pages in Ruckus, in the embedded JavaScript language that I mentioned before, some of them were expecting a Csurf token,

176
00:21:53,560 --> 00:22:10,660
but the thing is that some of them looks to be like hard-coded there, so probably I can just overcome this token, but I did not pay too much attention for it, I must honestly say.

177
00:22:11,320 --> 00:22:17,540
Yeah, and the XSS vulnerability as well, it was just out there.

178
00:22:17,540 --> 00:22:23,980
For every request you send, you just get the reflected, you know, reflection for what you sent.

179
00:22:23,980 --> 00:22:28,640
So I'm like, okay, there's an XSS here, I gotta tell them.

180
00:22:29,520 --> 00:22:35,460
You can't not report that one when it, you didn't, sounds like you didn't really try, it just came back to you.

181
00:22:36,380 --> 00:22:37,500
That's true.

182
00:22:37,560 --> 00:22:57,800
So, and that's actually an interesting idea of how you are approaching this, so if there are some vulnerabilities that just show up without you having to really hunt for them, when you are reporting that, do you ever leave commentary around, hey, so I found this one,

183
00:22:57,800 --> 00:23:17,120
I wasn't really looking for it, I didn't really hunt down in this direction, or is this something that you're leaving open for future research for yourself, or would you tell anybody else in the community, oh hey, there's probably some findings here if you want to aim in this quadrant.

184
00:23:17,400 --> 00:23:20,520
Right, that's a good question.

185
00:23:20,520 --> 00:23:40,240
So no, I don't leave anything, I try not to leave anything open, I just, you know, try to report everything that I, you know, managed to found, even things that are not necessarily a full exploit, I would still let them know.

186
00:23:40,540 --> 00:23:43,080
A good example for it is the information leakage.

187
00:23:43,080 --> 00:23:58,060
I also noticed that there's this page, that you just go to this page, upnp.jsp, and you get just everything about the device, and I'm like, okay, this is a bad practice, it can lead to a jailbreak, and you guys should fix it.

188
00:23:58,100 --> 00:24:07,620
So no, I'm not, I think that the responsible thing to do is just to tell them, you know, to report everything that you find.

189
00:24:07,720 --> 00:24:17,520
But that being said, I must honestly say that the XSS, I only reported on this report, and not on my previous report, because as I said, it was really obvious.

190
00:24:17,720 --> 00:24:27,220
But I just, you know, I just, I don't know if I forget, I forgot about it, but I just, on this round, I just said, okay, I have to report it.

191
00:24:28,660 --> 00:24:29,320
Very good.

192
00:24:29,320 --> 00:24:33,400
Well, we're kind of coming to the end of the Q&A session.

193
00:24:33,400 --> 00:24:40,180
And one thing that Falvo and I like to do is kind of give you an opportunity to talk to the community about what's next, right?

194
00:24:40,480 --> 00:24:42,640
What's next in this kind of vein of research?

195
00:24:42,780 --> 00:24:45,120
Where are you going to be taking this kind of thing next?

196
00:24:45,120 --> 00:24:55,080
And where do you think that other people that are interested in the in the same kind of thing, how can they, how can they take what you've done and then run with it in other directions?

197
00:24:56,140 --> 00:24:57,120
All right.

198
00:24:57,360 --> 00:25:00,700
So, I think so.

199
00:25:00,700 --> 00:25:03,400
In our group, there are a lot of going on.

200
00:25:03,400 --> 00:25:08,440
We do all different sorts of research projects.

201
00:25:08,660 --> 00:25:13,220
And I think I already got another research that I just started.

202
00:25:13,220 --> 00:25:19,760
It's not going to be embedded devices, because I just want to experience with something else.

203
00:25:19,820 --> 00:25:23,820
Probably going to be around a bit fuzzing.

204
00:25:24,320 --> 00:25:28,040
And that's it for now.

205
00:25:28,400 --> 00:25:46,200
But except for that, so, in my group, we are also doing a very impressive research on iOS simulation, which is a really, really cool project that I might also take some part of it.

206
00:25:46,200 --> 00:26:00,360
Or in general, I think, so, as I already said, emulation in general, I think it's a really good thing to have in your arsenal as a researcher.

207
00:26:01,800 --> 00:26:02,540
So, yeah.

208
00:26:02,540 --> 00:26:06,080
So, probably some more emulation for sure.

209
00:26:06,080 --> 00:26:14,960
And then my next research, I think, is going to be, I hope, is going to be on something else with brand new vulnerabilities.

210
00:26:17,540 --> 00:26:20,420
There's a lot of exciting stuff to look forward to, then.

211
00:26:20,480 --> 00:26:21,800
Thank you very much.

212
00:26:21,800 --> 00:26:22,660
That's cool.

213
00:26:22,940 --> 00:26:23,980
Thank you, guys.

214
00:26:24,200 --> 00:26:24,620
Yeah.

215
00:26:24,620 --> 00:26:25,380
Thanks a lot.

216
00:26:25,380 --> 00:26:30,620
And thank you, everybody, for coming out for the Q&A session.

217
00:26:30,900 --> 00:26:33,700
And we will see you guys later on.

218
00:26:33,700 --> 00:26:36,460
Congratulations again on a great talk.

219
00:26:36,460 --> 00:26:38,960
And happy anniversary.

220
00:26:39,360 --> 00:26:40,900
Thank you very much, guys.

221
00:26:41,900 --> 00:26:42,400
All right.

222
00:26:42,400 --> 00:26:43,580
We'll talk to you guys soon.

223
00:26:44,120 --> 00:26:44,720
Okay.

224
00:26:44,720 --> 00:26:45,120
Bye now.