start	end	text
38340	44160	Welcome to When TLS Hacks You. Josh, thanks so much for joining us today for Q&A.
44160	47020	And I was wondering if you would mind introducing yourself to everyone.
47600	55360	Hi, I'm Josh. I work at a lot of Quora. And yeah, this is my second Black Hat Talk.
55820	59100	Which you'll see in a second. Thanks everyone for watching.
59740	61200	Thanks for being here.
61200	66840	Yeah, we were talking a little bit earlier about what inspired you to kind of get into this and, you know, write about it.
66840	69200	I was wondering if you might be willing to share with everyone.
69820	74500	Oh, yeah. So it was last year with Apple Pay.
75220	82560	We just covered a lot of SRF vulnerabilities and, you know, different ways of exploiting them.
82940	88700	They weren't super obvious internal endpoints to hit. So that's what we'll be diving into here.
89180	95380	You kind of mentioned Let's Encrypt when we were talking about that. Is that too much to go into?
96240	105500	Yeah. So just during exploring this, I ended up needing to create a fair amount of SSL certificates.
106940	113200	And that's where I was really glad that Let's Encrypt was around just in time for me to start doing this research.
116100	125060	Just because, you know, anytime I wanted to create a cert, I could do it for free. It's really handy.
127060	130140	I see the questions coming in already.
130740	138760	The first one was, I'm a bit confused about how you go from caching the TLS session ID in memcache to SSRF.
139920	140940	Okay.
142240	145600	So I guess maybe where the confusion might be is
147340	149760	caching the TLS session ID.
150480	153160	The TLS session ID gets cached
154000	161640	on the victim server that I'm attacking with SSRF. So when the victim server makes a first request, it
162780	177020	picks up this TLS session ID. And then when I send the same URL on the next request, it's going to send that session ID to itself. And of course, because it's sending a TLS packet to itself on memcache, it's going to be a bunch of
179920	186940	binary data in with it, as well as a memcache insert. And because memcache is so permissive,
186940	187520	it will actually
192180	198740	parse that memcache insert as long as it's delimited with new lines, even though it's sandwiched between a bunch of binary data.
200140	204880	Can you go just a little bit further on this? Because it seems to be an area that people are curious about.
204880	212700	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?
213400	214200	Right.
215240	219560	So maybe it helps to step back and
223340	233080	kind of revisit the just kind of the SRF trigger for this. Is that, you know, say for a practical example,
234060	238940	let's see, say you're, you know, wanting GitHub to notify you.
239600	246100	You know, usually it'd be on a Slack channel, but GitHub would notify you of commits to your repo.
246220	248300	But GitHub provides a URL field
249940	255080	that you can say, like, anytime someone commits to my repo, post to this URL.
255860	257300	So with SRF, people have
259280	265060	discovered that, you know, if you can enter a URL and a website hits it, that can be dangerous.
266480	273020	So, and where this gets to, you know, actually persisting stuff on GitHub,
273020	282120	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
284220	292920	it's where I send one request, GitHub follows a redirect on that request several times, and then
294120	298140	after the redirects, the DNS entry is expired and
299580	305880	you know, GitHub posts the section ID, which the DNS entry now resolves to itself
307620	310900	and onto some local port.
311780	313860	So it was clear.
315780	318100	Let me look back at the question.
318860	323160	No problem, I can ask it again if you want, but I know we kind of put you on the question there.
323360	332120	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.
332160	332840	Yeah.
334460	339320	Actually, something I just realized about this that might be helpful way to frame it is that this is
339900	346680	this is a second order attack, and that, you know, if you're familiar with or want to dig deeper,
346680	348120	anyone watching can look up
349360	350480	second order
351300	353120	SQL injection attacks,
353680	359020	which are kind of the same sort of thing where you like send, you know, one attack
360420	372780	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,
373840	375760	just the second thing that you launch.
377860	378940	Cool.
381100	382480	I'm sorry.
382760	384380	You're doing great.
385180	401320	So we can also ask Nate Brady's question from the Discord. He wants to know, he said, you mentioned in your talk that MySQL and Postgres might be susceptible services. What's behind that? And when looking at other services, what are the main things to look for?
402220	404120	Oh, right. That's a good question.
405320	410100	So this is actually where I'm really curious to see other people take this further.
411000	422180	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?
424000	426740	Now, the difficulty with
428880	439980	attacking stuff like MySQL and Postgres is that they're binary protocols. And, you know, a lot of times, at least as far as I've seen, a valid TLS packet is not going to be
441800	443800	it's not going to function as a valid MySQL
445480	465800	you know, insert, you know, something that's going to trigger an insert. 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.
466540	467420	Cool.
467980	469800	Let's see. Go ahead.
469800	475560	On that point, is there a list of, you know, prerequisite conditions for this attack to be successful?
480900	483780	So I guess the big point there is
486360	490800	probably the most helpful thing is the, there's a triple Venn diagram I have maybe
491840	494020	it's two thirds of the way through the talk.
494980	497120	And I believe the slides are posted.
498780	507760	But it's the three of those together are effectively the prerequisite. So you need to have a something that looks like SSRF.
508640	515880	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,
516420	524040	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.
524820	538140	You actually with these, it's flexible enough that you don't care about like, you know, content type restrictions. You don't care server only except PNGs, stuff like that. You just need some, you need that precondition.
538140	543640	You also need whatever the server is using to send the URL to be something that caches TLS sessions.
544300	549820	So like, I don't believe like Python currently caches TLS sessions.
551520	563020	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.
564640	577920	But, and then the third one is that whatever you're attacking has to have some locally authenticated service. And so the reason I pick on memcached particularly a lot is just that
578960	584060	It's so common to be to have memcached sitting on a server locally unauthenticated.
586760	588010	So, but there's
589980	590860	See there's
592360	605000	There's also, there's like a table in the talk. And I actually, I'd also be curious to see what locally unauthenticated services, you know, people are using to do srf attacks.
605460	616620	Awesome. 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. I think the
617480	624820	memcached one you had like RCE next to it all the way down to some others. And there's often only just like so much room that you can put on there.
624880	634640	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?
635960	637840	I do think so.
638360	646380	And actually, one thing that I thought I thought about exploring. I really wanted to get like a demo like this in time for the presentation would be
649600	657460	Finding some webcam that has like a telnet port open, right, which that has happened in the past.
658000	663640	And then, you know, having the phishing demo then get like a shell on that webcam or something like that.
664480	676040	The catch with that is that I couldn't find any webcams right now that have like that bad of a vulnerability. Probably just, I mean, there probably are, but I haven't had the time to
676840	679880	To order them all and explore them.
682760	693140	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. What was Chrome's reason for not addressing this?
693960	695180	Um,
696380	697760	So I think
700400	701440	See,
708310	709160	I think really
709160	713060	It seems to boil down to severity.
713440	716620	I don't want to gossip too much about Chrome.
717640	718960	I think
719480	731440	And to some extent, Chrome also has other DNS rebinding approaches. So, for example, you know, if you're phishing someone and you get them to click a link right
733720	742280	That in that case, if you get something to load up someone to load a fully malicious page. I think there are still existing DNS rebinding approaches.
742280	750060	I think, you know, whereas here for for Chrome specifically I'm just adding the ability to
751480	754900	If someone's doing an email and doesn't click a link.
756400	760860	Then, you know, I can still attack them by using TLS and image tags.
762240	763340	And actually
763340	773700	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.
775420	786840	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.
786840	795940	Like it's not consistent with the implementation, but it actually makes Mozilla safer or Firefox safer by default against this stuff.
798860	809740	So how was your experience with reporting the vulnerabilities that you found? What kind of feedback did you get? Was it a good experience? Bad experience? Mixed all across the board? How was that?
810220	813140	I'd say it was kind of mixed, especially at first.
814260	815020	But I think
816080	826580	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
827160	838900	that software that's making the vulnerability happen, right, it is ultimately like this is just kind of a consequence of the way TLS, you know, is standardized, right.
839780	845000	And so, you know, even though there definitely are potential fixes, you know,
845020	858940	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.
862330	866730	Is there a way on the DNS side to be able to protect yourself from this?
868170	868970	Yes.
870310	872730	So there's an interesting...
875390	880950	Like in the past there have been, you know, of course, like DNS rebinding attacks as a whole are not new.
881810	886150	The only thing that's new here is DNS rebinding with TLS, right.
888350	905910	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.
907450	911370	Or I think it might be built into like DNS mask and stuff.
911370	923450	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.
924710	932410	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.
932410	935730	So I do think those would also protect from the TLS variant of this.
935730	943530	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...
943530	949890	I think there are some like instances where it would be a breaking change on a network.
950190	953210	So it's a little bit complicated to roll out in that respect.
954050	955010	Excellent.
956050	969030	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?
969030	985370	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.
985370	996510	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.
996790	1002790	It does get more difficult if you don't have that level of transparency onto something you're attacking.
1003130	1010670	Um, I think the way that I've, you know, kind of, I've had a few attempts at this.
1010670	1023830	Um, it's the first, you know, port scan, right? 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?
1024950	1033870	Um, aside from, you know, launching on other things. So some people, what they do is, you know, what you could do is you could port scan by SSRF.
1033870	1040110	Discover that port 11201 or like 205, that something like that is like open.
1040850	1051310	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? And say like,
1051310	1060770	Hi, this is Josh in the memcached, right? 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.
1060770	1073210	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.
1073210	1082590	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.
1082590	1094470	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.
1095530	1108170	Where memcached does have a flush all command. 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
1109530	1114690	you know, that's one way you could have evidence that this is actually happening against memcached.
1115990	1126370	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? For example, you know, cross-site forgery requests.
1126450	1130170	Sorry, I said that one wrong. Cross-site request forgery.
1130170	1154350	Right. 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. Right.
1154350	1184130	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. Right. Um, there's not a whole lot of depth to go, go here with just CSRF attacks. 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
1184350	1211470	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. Um, and that's kind of a CSRF angle, even though it's on a server, it's like Chrome. 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.
1211990	1220470	Like an instance or like a mail instance or something like that. Um, that's, that's kind of a CSRF attack that you could explore.
1221170	1236230	Cool. Um, I think you mentioned before that last year at DEF CON, you presented on SSRF and then this year you have this presentation. Where do you think that you're going to go from here? What's next for you?
1236230	1244670	I'm guessing you probably already have some ideas of things that you want to look into. Is there some kind of next thing in this area or are you going in a completely different direction next?
1245310	1254190	Um, oh man, let's see. I have different directions. Um, let's see.
1255350	1271070	Or also, are there other things based on what you found that you want other people to look into that you figured? I didn't quite get a chance to go as far as I wanted to with this yet. And if somebody else is interested, they could kind of jump onto your work as well.
1271490	1275210	Right, right. Just trying to figure out how, how much I want to delve into detail.
1275410	1277590	Sure. Don't want to reveal too much.
1280070	1305250	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, to some extent, I look forward to like seeing people find and write up further vulnerabilities in this space.
1305250	1315410	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.
1315410	1340590	Because in the past, like, I think an orange size talk in like 2017, a new era of SRF, right? He had some really interesting vulnerability chains with SRF there. 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.
1341410	1344170	And then also, like,
1345010	1357270	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.
1358510	1371570	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. Because sometimes people will fix something by just, you know, checking out the URLs HTTPS
1372450	1378970	and leaving the fix there, whereas here you can actually go back and unfix those vulnerabilities.
1383010	1396030	Question earlier about what was your motivation with getting into this? And I was looking over your GitHub. And I think I see a lot of, you know, interesting things that go a little bit deeper into this with more information. Would you be willing to talk to us a little bit about what you have on there?
1397190	1397950	Um,
1398610	1399750	let's see.
1400490	1402210	Trying to think what's on my GitHub.
1402830	1404270	Putting you on the spot there.
1404550	1405310	What?
1405690	1408110	I said, we're really putting you on the spot today.
1408110	1409010	Oh, yeah.
1410190	1413510	Specifically about your TLS Poison repo?
1414030	1416810	Oh, right. Yes, the TLS Poison repo.
1423410	1426950	I posted the link if people want to take a look.
1427150	1439470	Oh, yeah. Yeah, of course, the link's right there. 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
1440930	1446710	these instructions, because it's definitely like it's just a fair warning on setting this up. It's
1448670	1457450	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.
1459170	1467430	So like if you're really committed with like infrastructure setup, then it might be a bit of a breeze. But I mean, otherwise, it can be a learning experience.
1468170	1473650	But I definitely wrote these instructions up pretty hastily. So there's some rough edges.
1474350	1484450	Cool. 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.
1484450	1503210	How do you get started? 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. So like, how do I find that next thing? And how do I actually, you know, jump in and find something to research and where do I start?
1504030	1513670	Yeah, um, I think one thing, especially with vulnerabilities, like, you know, there's just like vulnerabilities like that.
1514950	1530850	You know, just opening up Wireshark, right? 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.
1531490	1540390	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.
1540390	1542690	I think actually even the first
1544190	1546390	The first discovery of this was
1546390	1557070	I'm just remembering, it was when I was doing srf, and I accidentally had an HTTP endpoint
1557070	1568210	that I fed an HTTPS URL. And I got an error, like Flask was saying, a bunch of random characters,
1568210	1572650	but that's not a valid request method. And I'm like, that's an interesting error.
1573130	1578890	Then, opening up Wireshark and seeing, what are some fields here I can use?
1578890	1589570	And, of course, previously people used S9 field, but there may even be more stuff here.
1590630	1596570	As well as, I mean, just TLS is really complicated. So,
1597290	1600270	there's definitely a lot of angles to explore with.
1600990	1605110	Totally sounds like there's a lot of research to still be done. And if people kind of wanted
1605110	1608290	to contribute to what you're already working on and start working together,
1608290	1612050	is that something you're looking towards, or a way for them to best do it?
1612510	1620710	Oh, yeah. So, I mean, if anyone has, I mean, has just the time and ability to
1623090	1627870	make this repo a little bit easier to set up, whether that's infrastructure as code,
1627870	1634830	or just better documentation, or introductory read-me's, that's definitely welcome.
1638120	1642600	To the end of the time we have together, besides the GitHub, what is the best way for people to
1642600	1646740	be able to reach out with any other questions, or if they hit issues when they're trying to
1646740	1650860	get this set up on their own? Oh, yeah. So, my Twitter,
1652420	1660600	joshmdx, same as my username on this DEF CON server. And I believe my direct messages are
1660600	1666760	open at least on Twitter. You can also send me a friend request, or try to reach out on
1666760	1673360	the Discord, too. Thanks for taking the time to answer these questions. And, yeah, hopefully we'll
1673360	1677760	see you again next year. It seems like you're on a roll with the subject. All right. Thank you.
1677760	1679620	Thank you, everyone, for watching. Thanks, Josh.