Welcome to When TLS Hacks You. 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 a lot of Quora. And yeah, this is my second Black Hat Talk.
Which you'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 kind of get into this and, you know, 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.
We just covered a lot of SRF vulnerabilities and, you know, different ways of exploiting them.
They weren't super obvious internal endpoints to hit. 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 to go into?
Yeah. So just during exploring this, I ended up needing to create a fair amount of SSL certificates.
And that's where I was really glad 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 could do it for free. It's really handy.
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 in 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 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. And because memcache is so permissive,
it will actually
parse that memcache insert as long as it's delimited 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 just kind of the SRF trigger for this. Is that, you know, say for a practical example,
let's see, say you're, you know, wanting GitHub to notify you.
You know, usually it'd be on a Slack channel, but GitHub would notify you of commits to your repo.
But GitHub provides a URL field
that you can say, like, anytime someone commits to my repo, post to this URL.
So with SRF, people have
discovered that, you know, if you can enter a URL and a website hits it, that can be dangerous.
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, 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.
So it 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 asked me about how you're getting whatever, you know, whether it be SMTP or memcache to actually interact or to bring in DSL.
Yeah.
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,
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.
I'm sorry.
You're doing great.
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?
Oh, 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
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 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.
Cool.
Let's see. Go ahead.
On that point, is there a list of, you know, prerequisite conditions for this attack to be successful?
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.
And I believe the slides are posted.
But it's the three of those together are effectively the prerequisite. So you need to have a something that looks like SSRF.
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.
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.
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 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.
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
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 unauthenticated services, you know, people are using to do srf attacks.
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
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.
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?
I do think so.
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
Finding some webcam that has like a telnet port open, right, which that has happened in the past.
And then, you know, having the phishing demo then get like a shell on that webcam or something like that.
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
To order them all and explore them.
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?
Um,
So I think
See,
I think really
It seems to boil down to severity.
I don't want to gossip too much about Chrome.
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, if you get something to load up someone to load a fully 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 doing an email and doesn't click a link.
Then, you know, I can still attack them by using TLS and 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 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.
Like it's not consistent with the implementation, but it actually makes Mozilla safer or Firefox safer by default against this stuff.
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?
I'd say it was kind of mixed, especially at first.
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, 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 diverge from the spec in order to like address this particular attack.
Is there a way on the DNS side to be able to protect yourself from this?
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 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.
Or I think it might be built into like DNS mask and stuff.
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.
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 memcached and when would you report it?
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.
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.
It does get more difficult if you don't have that level of transparency onto something you're attacking.
Um, I think the way that I've, you know, kind of, I've had a few attempts at this.
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?
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.
Discover that port 11201 or like 205, that something like that is like open.
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,
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.
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.
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.
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.
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
you know, that's one way you could have evidence that this is actually happening against memcached.
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.
Sorry, I said that one wrong. Cross-site request forgery.
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.
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
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.
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.
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?
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?
Um, oh man, let's see. I have different directions. Um, 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 onto your work as well.
Right, right. Just trying to figure out how, how much I want to delve into detail.
Sure. Don't want to 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 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.
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, HTTPS URLs that act as go for payloads, right, you know, we can kind of like revive that line of research a bit.
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.
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
and leaving the fix there, whereas here you can actually go back and unfix those vulnerabilities.
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,
let's see.
Trying to think what's on my GitHub.
Putting you on the spot there.
What?
I said, we're really putting you on the spot today.
Oh, yeah.
Specifically about your TLS Poison repo?
Oh, right. Yes, the TLS Poison repo.
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. 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.
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.
But I definitely wrote these instructions up pretty hastily. 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, you know, jump in and find something to research and where do I start?
Yeah, um, I think one thing, especially with vulnerabilities, like, you know, there's just like vulnerabilities like 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 see what the IoT device is doing, or just see what some piece of software is doing.
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.
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. And I got an error, like Flask was saying, a bunch of random characters,
but that's not a valid request method. And I'm like, that's an interesting error.
Then, opening up Wireshark and seeing, what are some fields here I can use?
And, of course, previously people used S9 field, but there may even be more stuff here.
As well as, I mean, just TLS is 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 a way 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 infrastructure as code,
or just better documentation, or introductory read-me's, 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 issues when they're trying to
get this set up on their own? Oh, yeah. So, my Twitter,
joshmdx, same as my username on this DEF CON server. And I believe my direct messages are
open at least on Twitter. You can also send me 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.