 Welcome to WinTLS Hacks U. Josh, thanks so much for joining us today for Q&A, and I was wondering if you would mind introducing yourself to everyone. Hi, I'm Josh. I work at Laudacora. This is my second Black Hat talk, which we'll see in a second. Thanks everyone for watching. Thanks for being here. Yeah. We were talking a little bit earlier about what inspired you to get into this and write about it. I was wondering if you might be willing to share with everyone. Oh, yeah. So it was last year with Apple Pay. You just have a lot of SREC vulnerabilities and you're just looking into different ways of exploiting them. There weren't super obvious underlying points to it. So that's what we'll be diving into here. You kind of mentioned Let's Encrypt when we were talking about that. Is that too much for you to go into? Yeah. So just during exploring this, I ended up needing to create a fair amount of S-Ball certificates. And that's where I was really well that Let's Encrypt was around just in time for me to start doing this research. Just because, you know, anytime I wanted to create a cert, I would get it free. It's really handy. As I see the questions coming in already. The first one was I'm a bit confused about how you go from caching the TLS session ID and memcache to SSRF. Okay. So I guess maybe where the confusion might be is caching the TLS session ID. The TLS session ID gets cached on the victim server that I'm attacking with SSRF. So when the victim server makes a first request, it 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 sending a TLS package itself on memcache, it's going to be a bunch of, you know, there's going to be a bunch of binary data in with it, as well as a memcache insert. And because memcache is so permissive, it'll actually allow, it'll actually parse that memcache insert as long as it's still limited with new lines, even though it's sandwiched between a bunch of binary data. Can you go just a little bit further on this, because it seems to be an area that people are curious about, 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? Right. So maybe it helps to step back and kind of revisit the SSRF trigger for this, is that, you know, say for a practical example, let's see, say you're, you know, you want GitHub to notify you, you know, usually it'd be on a Slack channel, but GitHub to notify you of commits to your repo. So GitHub provides a URL field that you can say, like, anytime someone commits to my repo, post to this URL. So with SSRF people have discovered that, you know, if you can enter a URL on a website, that that's, that can be dangerous. So, and where this gets to, you know, actually persisting stuff on GitHub, and we can, for example, 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 to do itself is it's where I send one request, GitHub follows a redirect on that request several times, and then after your redirects, the DNS entry is expired, and, you know, GitHub posts the session ID, which the DNS entry now resolves to itself in onto some local port. That was clear. Let me look back at the question. No problem. I can ask it again if you want. But I know we kind of put you on the question there. Most of them just about how you're getting whatever, you know, whether BSM2P or MIMTASH to actually interact or to bring in BSL. Yeah. And 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, and when Washington look up second order, the SQL injection attacks, 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. Just the second thing that you launch. Cool. So we're going to have to do more. Sorry. You're doing great. So we can also ask Nate Brady's question from the, from the discord. He wants to know, 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? All right, that's a good question. So this is actually where I'm really curious to see other people take this further. 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. Now, the difficulty with with 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 It's not going to function as a valid MySQL, you know, insert, you know, something that's going to trigger an insert. But there 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 that great at like memory correction vulnerabilities, but I'm really, really curious to see if people can actually take this and run that direction. Cool. I'll see. Go ahead. On that point, is there a list of, you know, prerequisite conditions for this attack to be successful. The big. So I guess the big point there is probably the most helpful thing is the, there's a triple Vendire and I have maybe it's two thirds of the way through the talk. I believe the slides are posted. But it's the three of those together are effectively the pre-rock was it so you need to have a something that looks like SSRF. Sometimes in the case of like one demo or I'm fishing 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 or server a URL and it needs to hit that URL. You actually with these, it's a lot of that you don't care about like, you know, content type restrictions you don't care server only except in G's stuff like that you just need some, you need that precondition. You also need whatever the server is using to send the URL to be something that caches TLS sessions. So like, I don't believe like Python currently caches TLS sessions. And I mean, there are other I think go most go stuff doesn't catch the all sessions either. Or at least yeah, I think there's an open ticket and go to actually do this, at which point you will be able to attack go stuff. But, and then the third one is that whatever you're attacking has have some locally an authenticated service. 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. So, but there's see there's there's also there's like a table in the talk. And I actually I'd also be curious to see what locally on authenticated services, you know, people are using to us or have attacks. Awesome. Yeah, I remember in your talk I think you had a slide on a whole bunch of the different SSRF examples and you might have even had them ranked I think the the 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. Either 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. I do think so. And actually one thing that I thought about exploring I really wanted to get like a demo like this and time for the presentation would be finding some webcam that has like a telnet port open right which that has happened in the past. And then you know having the 15 demo, then get like a shell on that webcam or something like that. And that is that I couldn't find any webcams right now that have like that bad of a vulnerability. Probably just, they're probably are but I haven't had the time to order them all and explore them. We have the next question which is you mentioned that using within the right parameters instead of Chrome would be preferable to protect you. What was Chrome's reason for not addressing this. So I think, see, I think really it seems to boil down to severity. I don't want to gossip too much about Chrome. They, I think, 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. That in that case, I think it's something a lot of someone a lot of falling malicious page. I think there are still existing DNS rebinding approaches. I think, you know, whereas here for for Chrome specifically, I'm just adding the ability to if someone's viewing an email and doesn't click a link. Then, you know, I can still attack them by using TLS image tags. 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. Mozilla has kind of a quirk where it catches 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. Like it's not consistent with the implementation, but it actually makes Mozilla safer or Firefox safer by default against this stuff. So how is 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? I'd say it's kind of mixed, especially at first. But I think what kind of helpful that is kind of reframing this as, you know, this really like when you report the 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, right? It is ultimately like, this is just kind of a consequence of the way TLS, you know, is standardized, right? 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 do diverge from the spec in order to like address this particular attack. Cool. The way on the DNS side to be able to protect yourself from them? Yes. So there's an interesting, like in the past there have been, you know, of course, like DNS rebinding attacks as a whole are not new. The only thing that's new here is DNS rebinding with TLS, right? So, in the past, just by just in order to address DNS rebinding over like HTTP, I believe like PF sense and like, I think there's like a plug in for, for like, if you have a raspberry pi like pi whole. Or I think it might be built into like DNS mask and stuff to where if they, I think if they like since a domain name getting resolved to something publicly and then later it's getting resolved to like local host, 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. So I do think those would also protect from the TLS variant of this, 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, I think there are some like instances where it would be a breaking change on a network. So it's a little bit complicated to roll out in that respect. Excellent. 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 men cashed. And when would you report it. So yeah, this is actually, this is one, one area where it gets difficult is, you know, a lot of the stuff. I've really mainly focused on open source stuff. You know, so in that case, it's like, I can prove out locally, the, whether I've inserted something in the men cashed, and then you know, just reported it's like, it does get more difficult if you don't have that level of transparency on the something you're attacking. I think the way that I've, you know, kind of, I've had a few attempts at this. It's the first, you know, port scan, right, or like first, you know, you can do like internal port scanning by SRF and lots of people do that. And it's not a super serious vulnerability, right. Aside from, you know, launching on other things. So some people what they do is, you know, what you could do is you can port scan by SRF, discover that for one one two and one or like two and a five that something like that it's like open. 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, Hi, this is Josh in their memcast right and then submit it and be like, you know, if you see the century in your memcast, then, you know, this is really bad. You could also try to just spray like Python dear serialization payloads like because, you know, just because of how big TLS session take this can be, 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 these serialized and execute. 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 we just like denial of service angle, where memcatch does have a flush off command. So if you were to try this attack and get memcatch flush all, and suddenly you see it 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 memcatch. 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 orgery request, or sorry, I said that one across site request forgery. Right. So the thing with CSRF, well, specifically with TLS for mining, right, is the, you know, really it kind of, it's something that practically you want to send from like, you know, you want to send from like a phishing you're all right. And because kind of the, really in most cases, the, where this happens is just Chrome and where it can be front of this Chrome, right. There's not a whole lot of depth to go here with just CSRF attacks. So, in a way, like, another avenue of exploiting this one from is to do is to, if you have an access and like PDF generator, like there was a talk last year, and I think def con about about PDF generators getting like access to RC and those. That's kind of a CSRF angle, even though it's on a server, it's like Chrome. So that's, that is one angle is like if you have a PDF renderer that's running, you know, and it can access, like MM catch instance or like a mail instance or something like that. That's, that's kind of a CSRF attack that you could explore. 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? 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? Oh, man. Let's see. I have different directions. Let's see. 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 on to your work as well. Right, right. It's trying to figure out how much I want to delve into detail on. Sure. Don't reveal too much. The second part of that question I like because there's definitely here for stuff here where I've kind of like, and like, okay, this is, I've been spent so much time trying to like DNS or bind or TLS or bind stuff that I don't want to delve too deeply. And I, it had just kind of to some extent I look forward to like seeing people wind and write up further vulnerabilities in the space. 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. 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, H2S URLs that act as gopher payloads, right? You know, we can kind of like revive that line of research in a bit. And then also like, so there are a lot of SRF vulnerabilities out there that, you know, have been reported and written out, right? And then, you know, like at least assumed to be fixed. 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 at the URLs H2S and leaving the fix there. Whereas here you can actually go back and unfix those vulnerabilities. I had a 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? Um, see, trying to think what's on my GitHub. Putting you on the spot there. What? So we're really putting you on the spot today. Oh yeah. Specifically about your TLS poison repo. Oh right. Yes, the TLS poison repo. See. I posted the link if people want to take a look. 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 these instructions because it's definitely like it's just a fair warning on setting this up. 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. Like if you're really familiar with like infrastructure setup, then it might be a bit of a breeze. But I mean, otherwise it can be a learning experience. But I definitely read both these instructions up pretty easily. So there's some rough edges. 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. 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 jump in and find something to research and where do I start? Yeah, I think one thing, especially with vulnerabilities like, you know, there's just like vulnerabilities like news that, 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 like, see what the IoT device is doing or just see what some piece of software is doing. Or I mean, honestly, just any time you can intercept traffic and pick it apart and look at what stuff is doing. That's really helpful. I think actually even the first discovery of this was just remembering is, you know, it was when I like was doing SRF. So I accidentally like had an HTTP endpoint that I fed like an HTTPS URL. And I was like, I got an error like, you know, like Flask was saying like a bunch of random characters that that's not a valid request method. And I'm like, that's an interesting error. So, you know, then, you know, opening up Wireshark and just seeing like, Oh, what are some fields here I can use? And, you know, of course, previously people use SNI field, you know, but, you know, there may even be more stuff here. As well as I mean, you know, just PLS is, you know, really complicated. So there's definitely a lot of angles to explore with. Totally sounds like there's a lot of research to still be done. 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, you know, wait for them to best do it? Oh, yeah. 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 like infrastructure as code or just like better documentation. Or like, you know, introductory with me, that's definitely welcome. 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, you know, issues when they're trying to get this set up on their own? Oh, yeah. So my Twitter, Josh MDX, same as my username on this DevCon server. And I believe my direct messages are open at least on Twitter. You can also send in a friend request or try to reach out on the Discord too. Thanks for taking the time to answer these questions. And yeah, hopefully we'll see you again next year. It seems like you're on a roll with the subject. All right. Thank you. Thank you everyone for watching. Thanks, Josh.