WEBVTT 00:38.340 --> 00:41.400 Welcome to When TLS Hacks You. 00:41.400 --> 00:44.160 Josh, thanks so much for joining us today for Q&A. 00:44.160 --> 00:47.020 And I was wondering if you would mind introducing yourself to everyone. 00:47.600 --> 00:49.220 Hi, I'm Josh. 00:49.220 --> 00:51.380 I work at a lot of Quora. 00:52.500 --> 00:55.360 And yeah, this is my second Black Hat Talk. 00:55.820 --> 00:57.460 Which you'll see in a second. 00:57.500 --> 00:59.100 Thanks everyone for watching. 00:59.740 --> 01:01.200 Thanks for being here. 01:01.200 --> 01:06.840 Yeah, we were talking a little bit earlier about what inspired you to kind of get into this and, you know, write about it. 01:06.840 --> 01:09.200 I was wondering if you might be willing to share with everyone. 01:09.820 --> 01:10.220 Oh, yeah. 01:10.220 --> 01:14.500 So it was last year with Apple Pay. 01:15.220 --> 01:22.560 We just covered a lot of SRF vulnerabilities and, you know, different ways of exploiting them. 01:22.940 --> 01:26.200 They weren't super obvious internal endpoints to hit. 01:26.440 --> 01:28.700 So that's what we'll be diving into here. 01:29.180 --> 01:33.340 You kind of mentioned Let's Encrypt when we were talking about that. 01:33.560 --> 01:35.380 Is that too much to go into? 01:36.240 --> 01:36.720 Yeah. 01:36.720 --> 01:45.500 So just during exploring this, I ended up needing to create a fair amount of SSL certificates. 01:46.940 --> 01:53.200 And that's where I was really glad that Let's Encrypt was around just in time for me to start doing this research. 01:56.100 --> 02:02.720 Just because, you know, anytime I wanted to create a cert, I could do it for free. 02:03.180 --> 02:05.060 It's really handy. 02:07.060 --> 02:10.140 I see the questions coming in already. 02:10.740 --> 02:18.760 The first one was, I'm a bit confused about how you go from caching the TLS session ID in memcache to SSRF. 02:19.920 --> 02:20.940 Okay. 02:22.240 --> 02:29.760 So I guess maybe where the confusion might be is caching the TLS session ID. 02:30.480 --> 02:37.120 The TLS session ID gets cached on the victim server that I'm attacking with SSRF. 02:37.120 --> 02:45.220 So when the victim server makes a first request, it picks up this TLS session ID. 02:45.440 --> 02:51.660 And then when I send the same URL on the next request, it's going to send that session ID to itself. 02:51.660 --> 03:04.120 And of course, because it's sending a TLS packet to itself on memcache, it's going to be a bunch of binary data in with it, as well as a memcache insert. 03:04.120 --> 03:07.520 And because memcache is so permissive, it will actually 03:12.180 --> 03:18.740 parse that memcache insert as long as it's delimited with new lines, even though it's sandwiched between a bunch of binary data. 03:20.140 --> 03:21.820 Can you go just a little bit further on this? 03:21.820 --> 03:24.880 Because it seems to be an area that people are curious about. 03:24.880 --> 03:32.700 Because the next question is, how did you get the vulnerable server to use TLS session ID ticket as a body of the SMTP request? 03:33.400 --> 03:34.200 Right. 03:35.240 --> 03:39.560 So maybe it helps to step back and 03:43.340 --> 03:48.600 kind of revisit the just kind of the SRF trigger for this. 03:48.740 --> 03:58.940 Is that, you know, say for a practical example, let's see, say you're, you know, wanting GitHub to notify you. 03:59.600 --> 04:06.100 You know, usually it'd be on a Slack channel, but GitHub would notify you of commits to your repo. 04:06.220 --> 04:15.080 But GitHub provides a URL field that you can say, like, anytime someone commits to my repo, post to this URL. 04:15.860 --> 04:25.060 So with SRF, people have discovered that, you know, if you can enter a URL and a website hits it, that can be dangerous. 04:26.480 --> 04:47.500 So, and where this gets to, you know, actually persisting stuff on GitHub, even though I haven't attacked GitHub, but where it gets to actually persisting stuff on GitHub and getting GitHub to send what it persists into itself is it's where I send one request, 04:47.500 --> 05:10.900 GitHub follows a redirect on that request several times, and then after the redirects, the DNS entry is expired and you know, GitHub posts the section ID, which the DNS entry now resolves to itself and onto some local port. 05:11.780 --> 05:13.860 So it was clear. 05:15.780 --> 05:18.100 Let me look back at the question. 05:18.860 --> 05:23.160 No problem, I can ask it again if you want, but I know we kind of put you on the question there. 05:23.360 --> 05:32.120 Most of them just asked me about how you're getting whatever, you know, whether it be SMTP or memcache to actually interact or to bring in DSL. 05:32.160 --> 05:32.840 Yeah. 05:34.460 --> 05:53.120 Actually, something I just realized about this that might be helpful way to frame it is that this is this is a second order attack, and that, you know, if you're familiar with or want to dig deeper, anyone watching can look up second order SQL injection attacks, 05:53.680 --> 06:12.780 which are kind of the same sort of thing where you like send, you know, one attack to, you know, get the server into some state to where you can send the same URL or a different URL again and then actually get the attack to happen based upon that second, 06:13.840 --> 06:15.760 just the second thing that you launch. 06:17.860 --> 06:18.940 Cool. 06:21.100 --> 06:22.480 I'm sorry. 06:22.760 --> 06:24.380 You're doing great. 06:25.180 --> 06:30.240 So we can also ask Nate Brady's question from the Discord. 06:30.240 --> 06:36.100 He wants to know, he said, you mentioned in your talk that MySQL and Postgres might be susceptible services. 06:36.120 --> 06:37.300 What's behind that? 06:37.300 --> 06:41.320 And when looking at other services, what are the main things to look for? 06:42.220 --> 06:42.820 Oh, right. 06:42.820 --> 06:44.120 That's a good question. 06:45.320 --> 06:50.100 So this is actually where I'm really curious to see other people take this further. 06:51.000 --> 07:02.180 Is that, you know, what I have here is the ability to get a server to send, you know, with a really flexible manner, binary data to itself that I control, right? 07:04.000 --> 07:12.820 Now, the difficulty with attacking stuff like MySQL and Postgres is that they're binary protocols. 07:12.960 --> 07:29.100 And, you know, a lot of times, at least as far as I've seen, a valid TLS packet is not going to be it's not going to function as a valid MySQL you know, insert, you know, something that's going to trigger an insert. 07:29.380 --> 07:45.800 But the area where I'm really curious to see if anyone could go with, could do some like memory corruption or, you know, other areas that I'm, I'm definitely not great at like memory corruption vulnerabilities, but I'm really, really curious to see if people can actually take this more in that direction. 07:46.540 --> 07:47.420 Cool. 07:47.980 --> 07:49.020 Let's see. 07:49.020 --> 07:49.800 Go ahead. 07:49.800 --> 07:55.560 On that point, is there a list of, you know, prerequisite conditions for this attack to be successful? 08:00.900 --> 08:14.020 So I guess the big point there is probably the most helpful thing is the, there's a triple Venn diagram I have maybe it's two thirds of the way through the talk. 08:14.980 --> 08:17.120 And I believe the slides are posted. 08:18.780 --> 08:22.800 But it's the three of those together are effectively the prerequisite. 08:22.800 --> 08:27.760 So you need to have a something that looks like SSRF. 08:28.640 --> 08:44.040 Sometimes in the case of like Flum Demo where I'm phishing people, it's actually CSRF, but in that case, it's, you know, it's a little bit weird, but just restricting to SRF, you know, you need to be able to send a server a URL and it needs to hit that URL. 08:44.820 --> 08:51.300 You actually with these, it's flexible enough that you don't care about like, you know, content type restrictions. 08:51.300 --> 08:55.360 You don't care server only except PNGs, stuff like that. 08:55.360 --> 08:58.140 You just need some, you need that precondition. 08:58.140 --> 09:03.640 You also need whatever the server is using to send the URL to be something that caches TLS sessions. 09:04.300 --> 09:09.820 So like, I don't believe like Python currently caches TLS sessions. 09:11.520 --> 09:23.020 And there are other, I think Go, most Go stuff doesn't cache TLS sessions either, or at least, yeah, I think there's an open ticket in Go to actually do this, at which point you will be able to attack Go stuff. 09:24.640 --> 09:33.520 But , and then the third one is that whatever you're attacking has to have some locally authenticated service. 09:33.520 --> 09:44.060 And so the reason I pick on memcached particularly a lot is just that It's so common to be to have memcached sitting on a server locally unauthenticated. 09:46.760 --> 09:56.000 So, but there's See there's There's also, there's like a table in the talk. 09:56.000 --> 10:05.000 And I actually, I'd also be curious to see what locally unauthenticated services, you know, people are using to do srf attacks. 10:05.460 --> 10:06.260 Awesome. 10:06.260 --> 10:15.680 Yeah, I remember in your talk, I think you had a slide on a whole bunch of the different srf examples and you might have even had them ranked. 10:15.680 --> 10:21.260 I think the memcached one you had like RCE next to it all the way down to some others. 10:21.260 --> 10:24.820 And there's often only just like so much room that you can put on there. 10:24.880 --> 10:34.640 Are there like, do you think there's a lot more vectors or areas that would be vulnerable to this type of attack that other people might potentially be able to find? 10:35.960 --> 10:37.840 I do think so. 10:38.360 --> 10:41.760 And actually, one thing that I thought I thought about exploring. 10:41.760 --> 10:46.380 I really wanted to get like a demo like this in time for the presentation would be 10:49.600 --> 10:57.460 Finding some webcam that has like a telnet port open, right, which that has happened in the past. 10:58.000 --> 11:03.640 And then, you know, having the phishing demo then get like a shell on that webcam or something like that. 11:04.480 --> 11:11.080 The catch with that is that I couldn't find any webcams right now that have like that bad of a vulnerability. 11:11.480 --> 11:19.880 Probably just, I mean, there probably are, but I haven't had the time to To order them all and explore them. 11:22.760 --> 11:30.900 We have the next question, which is, you mentioned that using Mozilla within the right parameters instead of Chrome would be preferable to protect you. 11:30.900 --> 11:33.140 What was Chrome's reason for not addressing this? 11:33.960 --> 11:41.440 Um, So I think See, 11:48.310 --> 11:53.060 I think really It seems to boil down to severity. 11:53.440 --> 11:56.620 I don't want to gossip too much about Chrome. 11:57.640 --> 12:05.780 I think And to some extent, Chrome also has other DNS rebinding approaches. 12:06.600 --> 12:18.640 So, for example, you know, if you're phishing someone and you get them to click a link right That in that case, if you get something to load up someone to load a fully malicious page. 12:19.060 --> 12:22.280 I think there are still existing DNS rebinding approaches. 12:22.280 --> 12:34.900 I think, you know, whereas here for for Chrome specifically I'm just adding the ability to If someone's doing an email and doesn't click a link. 12:36.400 --> 12:40.860 Then, you know, I can still attack them by using TLS and image tags. 12:42.240 --> 12:53.700 And actually I don't know if I got into it in this talk, but the reason Mozilla is actually so Mozilla allows you to disable TLS session IDs. 12:55.420 --> 13:06.840 Mozilla has kind of a quirk where it caches by IP address instead of domain, which is, it's kind of, in a way, it's a bug, but I don't think it's really a serious one. 13:06.840 --> 13:15.940 Like it's not consistent with the implementation, but it actually makes Mozilla safer or Firefox safer by default against this stuff. 13:18.860 --> 13:23.320 So how was your experience with reporting the vulnerabilities that you found? 13:23.320 --> 13:25.400 What kind of feedback did you get? 13:25.400 --> 13:26.480 Was it a good experience? 13:26.480 --> 13:27.260 Bad experience? 13:27.260 --> 13:28.680 Mixed all across the board? 13:28.680 --> 13:29.740 How was that? 13:30.220 --> 13:33.140 I'd say it was kind of mixed, especially at first. 13:34.260 --> 13:50.460 But I think what kind of helped with that is kind of reframing this as, you know, this really like when you report this stuff like Chrome or like Girl or someone that's like, you know, even though it's like that software that's making the vulnerability happen, 13:50.460 --> 13:58.900 right, it is ultimately like this is just kind of a consequence of the way TLS, you know, is standardized, right. 13:59.780 --> 14:18.940 And so, you know, even though there definitely are potential fixes, you know, like, I think I can definitely understand why people are not rushing to try to like diverge from the spec in order to like address this particular attack. 14:22.330 --> 14:26.730 Is there a way on the DNS side to be able to protect yourself from this? 14:28.170 --> 14:28.970 Yes. 14:30.310 --> 14:32.730 So there's an interesting... 14:35.390 --> 14:40.950 Like in the past there have been, you know, of course, like DNS rebinding attacks as a whole are not new. 14:41.810 --> 14:46.150 The only thing that's new here is DNS rebinding with TLS, right. 14:48.350 --> 15:05.910 So in the past, just in order to address DNS rebinding over like HTTP, I believe like PFSense and like I think there's like a plugin for like if you have a Raspberry Pi like Pi hole. 15:07.450 --> 15:11.370 Or I think it might be built into like DNS mask and stuff. 15:11.370 --> 15:23.450 To where if they, I think if they like sense a domain name getting resolved to something publicly and then later it's getting resolved to like localhost. 15:24.710 --> 15:32.410 These plugins will detect that and, you know, I think either like block it or just, you know, do something to protect you from it. 15:32.410 --> 15:35.730 So I do think those would also protect from the TLS variant of this. 15:35.730 --> 15:43.530 Although the caveat with that is that even though that's something you could theoretically roll out on like every network, I don't think it's... 15:43.530 --> 15:49.890 I think there are some like instances where it would be a breaking change on a network. 15:50.190 --> 15:53.210 So it's a little bit complicated to roll out in that respect. 15:54.050 --> 15:55.010 Excellent. 15:56.050 --> 16:09.030 Nate Brady wants to know, when you have a second order blind SSRF attack like this, how do you know if you've successfully poisoned something like memcached and when would you report it? 16:09.030 --> 16:25.370 Um, so yeah, this is actually, this is one area where it gets difficult is, you know, a lot of the stuff I've, I've really mainly focused on open source stuff. 16:25.370 --> 16:36.510 Um, you know, so in that case, like I can prove out locally the, whether I've inserted something in the memcached and then, you know, just report it and it's like, it's a substrate. 16:36.790 --> 16:42.790 It does get more difficult if you don't have that level of transparency onto something you're attacking. 16:43.130 --> 16:50.670 Um, I think the way that I've, you know, kind of, I've had a few attempts at this. 16:50.670 --> 16:55.430 Um, it's the first, you know, port scan, right? 16:55.430 --> 17:03.830 Or like first, you know, you can do like internal port scanning by SSRF and lots of people do that and it's not a super serious vulnerability, right? 17:04.950 --> 17:08.410 Um, aside from, you know, launching on other things. 17:08.490 --> 17:13.870 So some people, what they do is, you know, what you could do is you could port scan by SSRF. 17:13.870 --> 17:20.110 Discover that port 11201 or like 205, that something like that is like open. 17:20.850 --> 17:29.370 Um, and then what I've thought about doing is just like, you know, if I, if I see that, right, you know, I can trigger an insert, right? 17:29.370 --> 17:33.550 And say like, Hi, this is Josh in the memcached, right? 17:33.550 --> 17:40.770 And then submit it and it'll be like, you know, if you see this entry in your memcached, then, you know, this is really bad. 17:40.770 --> 17:53.210 Um, you could also try to just spray like Python to your serialization payloads, like, um, because, you know, just because of how big TLS sessions can be. 17:53.210 --> 18:02.590 You could put like, you know, hundreds or thousands of payloads in there and just hope that one of them, one of them will like get deserialized and execute. 18:02.590 --> 18:14.470 Um, and then, you know, another way is, I don't know if I'd recommend this necessarily, but is just trying the DDoS or not DDoS, but just like denial of service angle. 18:15.530 --> 18:17.930 Where memcached does have a flush all command. 18:18.070 --> 18:34.690 So if you were to try this attack and get memcached to flush all and suddenly you see the site like, you know, starting to take one time to load pages, then you know, that's one way you could have evidence that this is actually happening against memcached. 18:35.990 --> 18:43.530 It seems like you're still delving into this and, you know, learning more, but we're being asked is, are you working on this type of attack with anything else? 18:43.530 --> 18:46.370 For example, you know, cross-site forgery requests. 18:46.450 --> 18:48.150 Sorry, I said that one wrong. 18:48.190 --> 18:50.170 Cross-site request forgery. 18:50.170 --> 18:51.290 Right. 18:51.630 --> 19:13.650 Um, so I think the thing with CSRF, um, well specifically with TLS for mining, right, is, uh, the, um, you know, really it kind of, it's something that practically you, you want to send from like, you know, you want to send from like a phishing URL. 19:13.650 --> 19:14.350 Right. 19:14.350 --> 19:23.990 Um, and because kind of the, really in most cases, the, where this happens is just Chrome and where it can be printed as Chrome. 19:23.990 --> 19:24.630 Right. 19:24.970 --> 19:30.370 Um, there's not a whole lot of depth to go, go here with just CSRF attacks. 19:30.710 --> 19:56.970 Um, although, um, in a way, like another avenue of exploiting this on Chrome is to do, uh, is to, if you have an excess in like a PDF generator, um, like there was a talk last year at, uh, I think DEF CON, um, uh, about, uh, about PDF generators getting like SSRC in those. 19:57.210 --> 20:02.330 Um, and that's kind of a CSRF angle, even though it's on a server, it's like Chrome. 20:02.450 --> 20:11.470 Um, so that's, that is one angle is like, if you have a PDF renderer that's running, you know, and it can access. 20:11.990 --> 20:15.830 Like an instance or like a mail instance or something like that. 20:15.830 --> 20:20.470 Um, that's, that's kind of a CSRF attack that you could explore. 20:21.170 --> 20:22.070 Cool. 20:22.190 --> 20:31.830 Um, I think you mentioned before that last year at DEF CON, you presented on SSRF and then this year you have this presentation. 20:31.950 --> 20:34.690 Where do you think that you're going to go from here? 20:34.690 --> 20:36.230 What's next for you? 20:36.230 --> 20:39.930 I'm guessing you probably already have some ideas of things that you want to look into. 20:39.930 --> 20:44.670 Is there some kind of next thing in this area or are you going in a completely different direction next? 20:45.310 --> 20:48.650 Um, oh man, let's see. 20:48.650 --> 20:50.390 I have different directions. 20:50.530 --> 20:54.190 Um, let's see. 20:55.350 --> 21:02.730 Or also, are there other things based on what you found that you want other people to look into that you figured? 21:02.730 --> 21:06.350 I didn't quite get a chance to go as far as I wanted to with this yet. 21:06.350 --> 21:11.070 And if somebody else is interested, they could kind of jump onto your work as well. 21:11.490 --> 21:12.490 Right, right. 21:12.490 --> 21:15.210 Just trying to figure out how, how much I want to delve into detail. 21:15.410 --> 21:16.090 Sure. 21:16.090 --> 21:17.590 Don't want to reveal too much. 21:20.070 --> 21:38.970 The second part of that question I like because there's definitely here for stuff here where I've kind of like been like, okay, this is, I've been spent so much time trying to like DNS rebind or TLS rebind stuff that I don't want to delve too deeply and I just kind of, 21:38.970 --> 21:45.250 to some extent, I look forward to like seeing people find and write up further vulnerabilities in this space. 21:45.250 --> 21:55.410 So definitely like, you know, stuff where you're targeting something with memory corruption payloads, that would be really interesting to see this like change with that. 21:55.410 --> 22:02.790 Because in the past, like, I think an orange size talk in like 2017, a new era of SRF, right? 22:03.270 --> 22:07.330 He had some really interesting vulnerability chains with SRF there. 22:07.530 --> 22:20.590 So doing something, you know, now that we can effectively have, you know, HTTPS URLs that act as go for payloads, right, you know, we can kind of like revive that line of research a bit. 22:21.410 --> 22:37.270 And then also, like, so there are a lot of SRF vulnerabilities out there that, you know, have been reported and written up, right, and been, you know, like, at least assumed to be fixed. 22:38.510 --> 22:47.190 But I think also like some of this research, I found that in some cases that actually invalidates that assumption that something's been fixed. 22:47.190 --> 22:58.970 Because sometimes people will fix something by just, you know, checking out the URLs HTTPS and leaving the fix there, whereas here you can actually go back and unfix those vulnerabilities. 23:03.010 --> 23:06.410 Question earlier about what was your motivation with getting into this? 23:06.410 --> 23:08.190 And I was looking over your GitHub. 23:08.190 --> 23:12.810 And I think I see a lot of, you know, interesting things that go a little bit deeper into this with more information. 23:12.810 --> 23:16.030 Would you be willing to talk to us a little bit about what you have on there? 23:17.190 --> 23:19.750 Um, let's see. 23:20.490 --> 23:22.210 Trying to think what's on my GitHub. 23:22.830 --> 23:24.270 Putting you on the spot there. 23:24.550 --> 23:25.310 What? 23:25.690 --> 23:28.110 I said, we're really putting you on the spot today. 23:28.110 --> 23:29.010 Oh, yeah. 23:30.190 --> 23:33.510 Specifically about your TLS Poison repo? 23:34.030 --> 23:34.490 Oh, right. 23:34.490 --> 23:36.810 Yes, the TLS Poison repo. 23:43.410 --> 23:46.950 I posted the link if people want to take a look. 23:47.150 --> 23:47.890 Oh, yeah. 23:47.890 --> 23:49.610 Yeah, of course, the link's right there. 23:49.610 --> 24:06.550 And definitely like as people are going through these instructions, I've already had a couple of people reach out with some really good feedback on these instructions, because it's definitely like it's just a fair warning on setting this up. 24:06.550 --> 24:17.450 It's the instruction can be a little bit tough to work through just because you have to set up a couple of instances and DNS entries and a TLS certificate. 24:19.170 --> 24:24.270 So like if you're really committed with like infrastructure setup, then it might be a bit of a breeze. 24:24.610 --> 24:27.430 But I mean, otherwise, it can be a learning experience. 24:28.170 --> 24:31.830 But I definitely wrote these instructions up pretty hastily. 24:31.830 --> 24:33.650 So there's some rough edges. 24:34.350 --> 24:35.190 Cool. 24:35.190 --> 24:44.450 Also, along the lines of a learning experience, one question that I've been asking a few of the other speakers that have been doing research. 24:44.450 --> 24:46.070 How do you get started? 24:46.070 --> 24:54.650 Like if you're somebody that's new and really is interested in getting some kind of research angle, or maybe they want to speak at DEF CON one day. 24:54.650 --> 24:57.370 So like, how do I find that next thing? 24:57.370 --> 25:03.210 And how do I actually, you know, jump in and find something to research and where do I start? 25:04.030 --> 25:13.670 Yeah, um, I think one thing, especially with vulnerabilities, like, you know, there's just like vulnerabilities like that. 25:14.950 --> 25:19.010 You know, just opening up Wireshark, right? 25:19.030 --> 25:30.850 And, you know, say there's like some IoT device on your network, trying to get Wireshark to see what the IoT device is doing, or just see what some piece of software is doing. 25:31.490 --> 25:40.390 Or, I mean, honestly, just anytime you can intercept traffic and pick it apart and look at what stuff is doing, that's really helpful. 25:40.390 --> 26:01.830 I think actually even the first The first discovery of this was I'm just remembering, it was when I was doing srf, and I accidentally had an HTTP endpoint that I fed an HTTPS URL. 26:01.830 --> 26:09.970 And I got an error, like Flask was saying, a bunch of random characters, but that's not a valid request method. 26:09.970 --> 26:12.650 And I'm like, that's an interesting error. 26:13.130 --> 26:18.890 Then, opening up Wireshark and seeing, what are some fields here I can use? 26:18.890 --> 26:29.570 And , of course, previously people used S9 field, but there may even be more stuff here. 26:30.630 --> 26:35.630 As well as, I mean, just TLS is really complicated. 26:35.630 --> 26:40.270 So, there's definitely a lot of angles to explore with. 26:40.990 --> 26:44.110 Totally sounds like there's a lot of research to still be done. 26:44.110 --> 26:52.050 And if people kind of wanted to contribute to what you're already working on and start working together, is that something you're looking towards, or a way for them to best do it? 26:52.510 --> 26:53.530 Oh, yeah. 26:53.990 --> 27:14.830 So, I mean, if anyone has, I mean, has just the time and ability to make this repo a little bit easier to set up, whether that's infrastructure as code, or just better documentation, or introductory read-me's, that's definitely welcome. 27:18.120 --> 27:28.060 To the end of the time we have together, besides the GitHub, what is the best way for people to be able to reach out with any other questions, or if they hit issues when they're trying to get this set up on their own? 27:28.800 --> 27:29.560 Oh, yeah. 27:29.760 --> 27:36.660 So, my Twitter, joshmdx, same as my username on this DEF CON server. 27:38.200 --> 27:41.960 And I believe my direct messages are open at least on Twitter. 27:43.040 --> 27:48.120 You can also send me a friend request, or try to reach out on the Discord, too. 27:49.000 --> 27:51.780 Thanks for taking the time to answer these questions. 27:51.900 --> 27:54.320 And, yeah, hopefully we'll see you again next year. 27:54.320 --> 27:56.160 It seems like you're on a roll with the subject. 27:56.520 --> 27:56.940 All right. 27:56.940 --> 27:57.760 Thank you. 27:57.760 --> 27:58.800 Thank you, everyone, for watching. 27:59.000 --> 27:59.620 Thanks, Josh.