Lyra Rebane - Reporting vulnerabilities to Estonian companies - 2026 edition

[music]

[music]

>> Hello everyone. Um so many of you here. Uh so, welcome to my talk about reporting vulnerabilities to Estonian companies for fun and very little profit. >> [snorts] >> So, uh I'm Lyra. Uh I am a security researcher focusing on web and web browsers. And these days I mostly target uh companies, like big companies that pay out bug bounties, such as Google. I target web browsers, Chrome, Firefox, Safari, and so on. Um and I get paid pretty well for that. But back when I was a kid, like 10, 11, 12 years old, I used to hack different kinds of websites. This is Miksike. It's >> [laughter] >> it's an Estonian website, used to be one,

uh for students. Had lots of educational materials, quizzes, games, math stuff, and so on. And because this is what I was using, um I started to poke around in because I was interested in how systems work. And I started finding vulnerabilities of all kinds. Uh I took those vulnerabilities and I reported them to the owners of the site. But I never really got like many good responses. I didn't really get good recognition. But that didn't deter me. I just wanted to make this site better that our school made us use. So I kept finding things. I kept reporting them. Until one day I found a vulnerability that let me access the entire web server and all of its files.

Now this was pretty serious because being able to steal the personal information of all of Estonia's students or all of the ones that use Meedia. Was pretty bad. So I reported it to them. But while messing around with it, I renamed a file on accident. Which broke the website. I emailed them about it and told them how to fix it. But they decided that that was bad. And they let the police know about it. They made uh me apologize for what I had done. I was at at the time 12-year-old. I had just gotten full access to their web server. And they are and and like I am the problem here? Uh So I don't think I even did any like

damages. I all they needed to do is was rename a file back. But I don't know if they maybe they didn't see my email or something. Um and they claimed that I caused them thousands of euros of damages and they made me promise to the police that I would never hack again. Which is a really bad lesson to teach our kids because computers are so interesting. I'm not going to stop hacking. I'm just going to make sure I don't get caught. And if I don't get caught, I might as well do illegal things. And this this is my background. This is where I come from. And that's not good. This is taking our youth who are

genuinely interested in cybersecurity and making them feel bad for doing the right thing. I'm sure the way I reported or did the security research or so on was not up to the industry standard, but I was a 12-year-old and this kind of vulnerability this kind of vulnerabilities I found would have been really easy for a state actor to find and exploit. Going forwards in time, this is the kind of stuff that happens these days. Um instead of taking kids who do like bad things, hacking, and like making them feel making them like feel like it's the wrong thing to do, uh we instead redirect that interest and curiosity towards places where it is more useful.

And I think that's the right thing. I think what the Mexican people should have done was thank me for the things, set up rules on how I could do security research without breaking anything, and let me improve their security. They also probably should have gotten some pen tests going, but um uh but okay. What this talk is going to be about is how Estonian companies respond to these kinds of vulnerability reports these days. Are they still going to call the police on me? I'm going to start off with Barbora. Now, these companies are are all companies that I've used because I like to do security research on things I actually use, that my family uses,

that my friends use, to make sure that they're secure and that the people I care about are safe. Barbora is an online web store or grocery store where you can order groceries to your home. It's pretty much Maxima online, but I don't think they want me to call that that, so I'm not going to do that, but um But okay, let's start hacking this website. What's the first thing we see where I can type in some malicious code? Well, it's the search box. So, I'm going to type in script alert. And what it should do is if a website is vulnerable, it pops up a little alert that says the number one, and I know

that I can run an like attack code on that site. But I get this screen. This screen is the Cloudflare WAF, web application firewall, and it's a layer between the server itself and the user that checks every request that goes through and sees if it might be doing anything malicious. In this case, it noticed that I was trying to use the script tag and thought it was suspicious and blocked it. But this doesn't mean that the website is vulnerable, nor does it mean that the website is protected from vulnerabilities. So, okay, let's try Try simpler. I'm just going to look up a string that I know doesn't exist as a product. And we get this page.

No products found. But what I put in the search is reflected on the page. Let's take a look at the code. This is the HTML source code the page sends me. And we can see the search query I put in appears in multiple places. Let's pick one of these and try to exploit it. There's a string there. Um so the way we would exploit it is by doing something like this where we put a quotation mark, close the HTML tag, and write our malicious attacker payload. Let's try it. Oh, this annoying thing. Did you know this is not symmetrical? But okay, let's try something simpler. So this here is not a script tag, so maybe it won't get blocked.

We put that in, and sure enough, it works. But you'll notice that all of these like places where this string exists are escaped. They have these ampersand things to make sure that my attack doesn't work. So that's good. That's protected. Well, except for that part there. That part in the script tag is escaped differently. Let's take a closer look. So in the URL, we have angle brackets. And those are not escaped because in a JavaScript string, escaping angle brackets doesn't really matter, right? But the quotation mark does get escaped because otherwise we could put a like a quotation mark there and escape this and write our own attack code. So, no luck there. But, say we could put a quotation mark

in there somehow with some exploit. Would this attack work? Well, no. There's two reasons this attack wouldn't work. The first one is that this is not valid JavaScript code. And not even the like attack part, this here is not valid JavaScript. It looks like a JavaScript object, but it's actually a code block. Code blocks and objects use the same characters in JavaScript. This is why like funny stuff like that works because, well, that's a code block plus an empty array and then it gives a zero and it's really funny. But, beside that, even if we could make this code into a shape where it would work, we still would not be able to execute it

because this type attribute here tells the browser that this is JSON. This is not JavaScript. Do not run it. So, there is no way for us to put anything inside of there that would make the script tag execute code. However, remember how the angle brackets were not escaped? Well, we can think outside the box and just escape the script tag. Now, the browser goes, "Oh, wait. All of this is the script tag and what's after is just HTML." So, as an attacker, we can just put our HTML there and there we go. We can run code. So, let's try it out. Oh. Okay. Uh let's see if we can change our payload a little to make it work. So,

let's let's try with just like a H1 tag so it's not even like doing anything bad. And that's blocked. Well, let's just try closing the script tag. Uh that's blocked. Let's try like messing with the capitalization. Uh that's blocked. Let's like try removing the angle bracket at the end. Oh, wait. This one actually works. Um So, we can put this string in the source, but what does it actually do? Let's see. So, there we have the script closing tag. But for some reason, it doesn't really affect this at all. And the reason is that it has to like quotation mark after it. Um it it is not the script closing tag. But the solution is simple. Just add a space

to the query. And there we go. >> [snorts] >> So, now we have a closing script tag, but it's still not useful to us as an attacker because well, it's going to look for the closing angle bracket. It's going to go all the way down there, and all of that is just going to disappear. There's no place for us as an attacker to put code. So, is this site secure? Well, not so fast. This is a barber search page, and it has a filtering option. Let's apply some filters. And okay, there's no Estonian products that are made by fat server something, but um Let's look at the URL. The URL now has the filters we applied

in there. So, maybe it's in the code as well. Let's see. And yep, we can see in addition to the query, the little pieces of filters uh are all in there. So, what we can do now is we can replace them with our payload, something like that. Uh and then we're good to go. So, let's try it out. Okay, this thing again. So, why this thing keeps appearing is because Cloudflare looks for anything that looks like a HTML tag uh in the URL. So, it sees that oh, that is a script closing tag, and then at the other end we have an angle bracket. So, even as something as simple as that is going to get blocked.

But, it needs to find that ending there. What if we just move it around? Well, suddenly, this is all good for Cloudflare. Um so, let's do the same with our payload. And there we go. It works. Of course, we don't get script execution because that's not how HTML works. Um but we can figure that out. I'm going to spare you the details, but I just iterated over a bunch of ideas. We can use an on error to run code, but we can't run a function, we can't run uh tag template, we can't do a comment. Uh but what we can do is we can call a function with a single backtick, and then on the other side of the query,

close the backtick and put our actual payload inside of the uh formatting. So, does this work? Okay. That's good. We we hacked the site.

Uh so, pretty awesome. We have code execution as an attacker. Uh let's report it. I looked around. Barbara does not have a bug bounty. Uh but they do have a contact email. So, I sent them a message where I told them to forward this message to the correct uh uh people, and I included all of the technical details as usual. On the very same day, I got a response where they thanked me for it. And then, a few days later, I got this email where the chief information security officer of Barbara uh let me know that uh they were thankful for this. They fixed the bug, and even though they don't have a bug bounty, they gave me a €100 gift

voucher. Yay. >> [applause] >> Now, I'm sure that they did not intend on doing this, but the gift voucher they gave me uh required me to spend at least €130.

But no, I was happy because, well, I could I could feel my addiction of uh hacker foods, cheese boxes. Yay. Uh so yeah. Uh I'm pretty happy with them. What are the lessons to learn? Um always escape your HTML characters. Um that example over there is actually what happens if you put that string in the Chrome DevTools. If you put that string in the Chrome DevTools, it automatically escapes it for you. Another lesson is that web application firewalls can be bypassed. They should never be used as the only security boundary. They can be used as like an additional protection, but if your web server, the underlying one, is vulnerable, then your service is vulnerable, and

it's only a matter of time until a bypass for that WAF is found. A- And I would go as far as to say that WAFs should be ignored in the context of vulnerability reports. If a vulnerability exists, but a web application firewall blocks it, I think it should still be considered a valid vulnerability, because all they need is to find a bypass for it. And you can see even the like ones from like Cloudflare are bypassable. And and lastly, it's it's a nice gesture to give me the like €100 coupon that I need €130 purchase to use, but no, I that's genuinely like a good gesture. It shows to me that they do care. The response was good. So, it's a

good example of how to treat the vulnerability. Next one. Elisa. This is an Estonian ISP and mobile service provider. I hacked their website. That's good. And then I went to look for a bug bounty. And I found one on HackerOne. That's good right? Well, this one is invite-only. And it's sadly like common to see many companies do invite-only bug bounties, but I do believe this is kind of the wrong thing to do uh because invite-only bug bounties mean that if I as a security researcher find the vulnerability, I may not be able to tell you about it. The only people who will listen are the bad guys. So, yeah, but okay, whatever. I'm a hacker, I can let myself in. I'm in the

the program. Sorry about this. They told told me I'm not allowed to talk about anything. Um Okay, I submitted the vulnerability. Um they gave me a bounty. I can't tell you what it is. I can't tell you what the vulnerability is. Um and then I asked to uh disclose this publicly because it was a fun vulnerability. I think it was interesting and I think it would have made for a good story for the stage. I think you would all would have loved it, but they never responded to me. And notice how it was reported in April. It's September now, and this vulnerability is still not patched. Okay, so what are the lessons here? Uh don't do private bug bounty programs

unless absolutely necessary. I know that these days spam and like slope submissions are a thing and are a problem, but private programs really do keep out the people who mean well and they give criminals more opportunity to snatch up vulnerabilities. Uh, and second thing is you should let security researchers talk about stuff because I had a really fun story to tell about this. Uh, but I can't tell you about it because well, I'm not allowed to disclose it. And lastly, you should fix your vulnerabilities because well, if I I go through the effort to show them to you, you should do something about it. Okay, next company. This is a company called Ravi and they are an Estonian healthcare

provider that I use. And recently, I had to check out one of my appointments uh, in the history. So, I went to download the PDF. You can see there's the PDF downloads. I clicked on the PDF and I get the document. But something stands out stood out to me. It was this request. This is the URL the file was downloaded from. This is a URL that has like a number in it. Is that the document number? Well, what I did to try this out was I put this URL in my browser and I changed the last digit of the URL. And you know what I saw? A 403 forbidden. Okay, this is good. I'm not supposed to

access those documents, so it's good that I don't get to access this. But then I changed the number back to mine and it still didn't work. So, then I realized that this site actually requires me to use an authorization header uh to access the document. So I set that up. I visit the thing again. I get my document. I change the number and I get a 404. So does it mean it's secure? Well, a 404 means that it something was not found. A 403 means that it was forbidden. So maybe there are documents out there. Let's Let's get searching. I started incrementing the number one by one. 7 8 9 Oh no. This is someone else's

medical history. That's not good. Um and what I did like I did the right thing that you should do in the situation and I stopped all research on this target. And instead I documented everything I did and brought it up in an email. The reason you do that is because this is very sensitive information and it also belongs to someone else. So if within your research you encounter someone else's information you know that you've already got there. There is no reason absolutely at all to access anyone else's information uh beyond that point. So I stopped. Ideally you would actually use two of your own accounts and try to access one from the other, but it is not

possible in all cases. So if you do happen to see someone else's info make sure you don't continue. But okay, I sent this in an email and I never got a reply to the email. Instead I got this mysterious text message. >> [laughter] >> Uh I I I asked about like they they wanted me they wanted me to meet up with them. I asked where, they gave me a place. Uh okay. So, I went uh I went to this mysterious place and I talked to them. And they were actually really nice. Um, but yeah, that's that's a bit um Uh, okay. I went there. I discussed this with them and what we ended up doing was

we ended up uh doing an agreement an NDA where I am not allowed to disclose the name of this company. This is why like Ravi 67 is not a real company like obviously made it up. I'm really happy with the like heart logo. Do you like it? But uh okay, no. Um yeah, I'm not allowed to disclose this company name. But we reached an agreement where they paid me a bounty and I was still allowed to talk about the vulnerability. And well, I'm not allowed to tell you how much they paid. But you know, it's not an insulting amount when I was willing to sign this document. What are the lessons learned? One is that you should get good pen

tests on your site because I feel like this kind of a vulnerability should be found in a pen test. I believe that the reason this was not found oh, this is just a guess. I don't know for sure. But I think the reason this was not found maybe that maybe their pen testers didn't have access to accounts with proper sample data because well, I had actual data in there of my own and I could poke around. So, when you do pen test, make sure that the environment those are being done in the pen testers can actually have multiple accounts, sample data, they can try all sorts of things out. And also do bug bounties. That's a

really cheap way for a company to increase the amount of eyes on the code. Also, don't contact people or text if they have not given you their phone number. It just feels sketchy and weird, and it might end up with like it might the number they pulled out may have been from some like may have been outdated. Maybe the number now belongs to someone else, and now someone else knows about this vulnerability or someone. If you want to text or call someone and they have emailed you, reply back and ask for a number and ask if it's okay. Not everyone wants to do calls or not everyone can do calls. And lastly, allow security researchers to talk about

vulnerabilities. I think that full transparency around uh like everything is really good. And that's my preferred way of doing things. I prefer to tell you the actual names of the company and like show you what they did good or what they did bad. But if you're going to do a non-disclosure agreement, do one like this where you find a middle ground where the vulnerabilities and the process can still be talked about. Because this is very useful information to the community and it would be a shame if it was just locked away under some NDA. So, I I think this is like I I I know this like seems a bit negative, but I'm actually really happy

with the company, their handling, and uh the um agreement uh we agreed on. Because, yeah, it's it's cool I can show you this, unlike the Elisa example. Okay. Um let's do one more. It's the last one. Omniva. Omniva is an Estonian postal service. Packages, deliveries, so on. Um and they have a nice little website where you can do stuff with your own packages. Let's Let's log in. So, it is on this URL. We can log in. And then we can see our packages and we can, you know, do stuff and so on. Pretty cool. But, what is the URL of this page? Well, it's that, but >> [snorts] >> what was the URL of that page a moment

ago? I did see it change in my browser. Ah, it was this. So, when I logged in, I was redirected to this URL. Where is this URL from? Well, the URL we saw earlier has this little target uh parameter, which is this URL here. And also, this URL has some kind of a token. It's a bit more complicated than that, but for the purposes of this talk, that's just the secret token I as an attacker need to log in to your Omniva account. And what's even more fun is that if I were to go on this URL in my browser now that I've logged in, it automatically redirects me there. With the secret key, of course.

So, can we steal the secret key somehow? Can we change that target value? Let's try it. I change it to my website. And oh, it doesn't work. Well, I guess they thought of that. But, can we do like an Omniva URL in there, like that? With my name on it. Well, that works. Let's just try Omniva's URL without without anything. And that works, too. So, I guess it just looks to make sure that the URL begins with that and doesn't care what's after that. Let's try putting in this thing. Oh, no. This is my website, but for some reason, the URL has the Omniva secret token in it. So, what this attack is here is I can craft a URL where if somebody

visits it, it will send my website their Omniva token, and I can take over their account. The reason this happens is because Omniva is asking the wrong question about the URL. It is checking whether the URL begins with this string, but it's not checking what the actual domain is. This kind of an URL consists of a username, an at symbol, and then the domain, like so. It's kind of similar to how email works. So, that there is the actual domain, and this here is just the username. So, what this means is that I can make a website where you can visit it, and you'll have no idea that anything happened at all cuz all of this can be

hidden away, but once you visit it, I get your session token or yeah, I can I can access your Omniva account. I can perform actions. I can read information, and so on. I of course put it all in an email and sent it over to Omniva. And a few days later, I got uh response back that told me uh that that that thanked me for this, told me that they're working on fixing it, and I can confirm that it has been fixed. And also they included an email for a direct contact in the future, which is really nice because yeah, but that's that's really good. Uh in the future if I find something, I can just email it

there. They also wanted to meet up with me. So, I went to the big scary Omniva building. And we discussed this vulnerability and things around it. And um they don't do bug bounties right now, but they said that maybe in the future they'll do it and maybe they'll pay me something or so on. Um but they did not pay me a bounty or anything, which is fine because they didn't have a program like that. But I did not leave empty-handed. I got the cool merch bag, whatever. Those things are great. Uh so yeah, what are the lessons learned? Uh I guess uh be careful with anything regarding redirects. Um open redirects and semi-open redirects by themselves maybe

are not vulnerabilities, but in the wrong context with the right attack chain they could be vulnerabilities, as you could see here. And also parsing URLs is hard, dangerous, and complicated. So, just make sure that you're doing things in a way where it's right, but uh I guess that's easier said than done. Uh and I guess one more lesson is that I don't know have a merch bag or they let it go. It's it's cool. Uh but yeah, that's the last company. And uh in general, I feel like I'm pretty happy with uh how this companies well exploiters uh before this companies like handled the situations these days. None of them threatened me. None of them, you know,

called the police on me. And yeah, some of them them rewards. And I think that's nice. Um I think we're going in the right direction. Uh so uh I guess Estonia is getting better at this stuff. I would love to see more bug bounties and things like that, but yeah, I'm I'm feeling very hopeful. So, that's my talk. This is my website if you would like to check it out. Uh it has my contact information and blog and also my slides if you would like to see them. Now, the slides they are not up right now, but they should be up very soon. Maybe by the end of the day. So, yeah. Uh thank you.

>> Thank you very much.

Um we'll have some questions as well. Um I know some of you are eager to go to Elisa's website and try stuff out now, but but uh do we have any questions? Uh any anybody? Yes, I can see a hand up there first of all. We'll get the mic to you in a moment. >> Hey, thanks for the talk. Really interesting stories. Uh I wonder the healthcare company, uh did you have to negotiate about the NDA uh so that you could publish or did they press first for like full non-disclosure? >> Uh so, the way it went is at first I suggested just disclosing it publicly. Uh but they didn't want that and then offered a

bounty um instead. But uh we didn't really have to negotiate too much over that. Uh I didn't feel like threatened. I felt like they were friendly. >> Any more questions? Yes, uh up here in front. Yes, we'll get a mic to you in a moment. >> Hi. Uh thanks for a really interesting presentation. And then maybe from the top of your head, like one best and one worst experience of response from, you know, companies that you have been where you have found some exploits. >> Well, the worst one I showed it at the beginning of the talk. Uh best one is definitely FastMail. Uh they've just been really, really good with the security from my experience and

I've been really happy with them. Last year in my talk I mentioned them and since then I've done more security research uh for them and they've been really good at it, so yeah, they get a big thumbs up. >> Okay, cool. Thank you. >> And uh also I've had great experiences with uh from Estonia I've had great experiences with Zone. Um so yeah. >> Mhm. >> Yep. No questions there. >> Oh, thanks thanks to you your talk. I have similar background but in Finland. So, so I have been hacking stuff in Finland and I I I saw that it's hard to report uh vulnerabilities to companies and I started to report them to CERT-FI only.

And they are uh they are doing the proxy stuff, so I don't need to do any more with the companies if I found something. Does CERT-AA offer that kind of services in in Estonia that you can report findings to that there and they will negotiate and do stuff with the companies? >> Uh yeah, uh CERT-EE is um like it's willing to help with stuff like that and often times when I do report a vulnerability I CC CERT-EE in the email so that if the company decides to you know, go against me, CERT knows that no, actually, this was reported responsibly and this are real thing they should be fixing. So, yeah, that that's a good tip if you're

reporting something, CC CERT >> Very cool. Any more questions? Um yep. >> We have two mics. >> I thank you for the great talk. I just have a quick question regarding the healthcare website. Any reason why you didn't go for the patient ID because that looks like the low-hanging fruit. >> Um >> Or did you try it and it was unsuccessful, so you just decided to cut it from the talk? >> Yeah, with all of these things I've shown, all of these services, I have like actually poked at like a lot of different things on their services, but of course, it would not be reasonable for me to make a presentation multiple hours long showing how I try everything

and fail. But maybe it would be a good talk so something to consider. But yes, I did try a lot of different things in all of the services. >> Okay, any more? Let's just check. Yep, in the very back there. >> Um great presentation, as always. Uh I've got a question around the security.txt files. I'm sure you're familiar with them, right? Um what has been your experience in Estonia like in terms of just hygiene around the organizations having security.txt files on their website, uh which makes it easy for for you to contact them when you do find the vulnerabilities? >> Yeah, so I don't know, I haven't I guess it's sort of a hidden miss. I

sometimes see them, sometimes don't. I don't have like a direct ratio to of numbers to tell you, but uh when they are there, I really appreciate it because it does make it easier to find what to contact and so on. >> Okay, in the middle there as well. One more question. We We have We have time for questions. >> Hi, thank you for the talk. I wanted to ask if you had any experience with Estonian governmental agencies and if they pay any bounties and what's your experience with them? >> No, I don't have any experiences with them in regarding to security research. Unfortunately. >> Okay. Um anybody else? Uh like yep, you'll get a mic. No

worries. >> Yeah, thank you. It was a great talk. How long do you usually spend on a target and when when do you decide that hey, maybe there's nothing here. I'll just go with another target? >> I would say it ranges from an hour to multiple weeks. And for me it's less of this looks secure so I should not poke at it, but more of a I've touched all the interesting bits. There's nothing interesting for me to look at because this research I am doing it because it is fun and interesting for me. Once it becomes boring, well, I'm just going to move on to the next target. >> Hey, I actually have a question as well.

You've been doing it for a while now as I understand like and you said you're you feel quite happy about the state where Estonia is with it right now. But has the sort of change been gradual or sort of sudden or have the company sort of started to understand now just lately or has it been a gradual thing? It's just >> I think it has been a gradual thing over a very long time. Yeah. >> Okay, and is it sort of just one thing that has it like has have the company started to give out more bounties or is it just different factors or how how would you say the progress has been here? >> I think the general

understanding of security and privacy and so on has shifted a lot uh for companies. Uh I think one thing to thank for it is GDPR, which made it so that companies can just leak an entire database of Estonian students. Uh but also just seeing all of the like cybercrimes and things evolve and affect all of us probably makes companies think about it more and customers also value it more. >> Okay. Were Did you get any more angry sort of angry uh emails back or something beforehand? It has it sort of changed to put more positive now, I guess, or >> Uh I would say it's more positive these days yeah. >> Okay. Any any more questions in the room

as well? I've taken Yeah, I see he's there in the middle. We'll get a mic to you, no worries. Yep. >> Hello, hello. Uh the question about these ethical aspects of performing these tests on real systems. Uh so, there are there is a belief that again that maybe shouldn't do it without the permission of the of the website owner. Where do you draw this line? >> So, the where I draw this line for myself, which is not where it's drawn legally, is that uh bad actors don't care if you don't allow you them to hack the website. So, if I want to be sure the website is secure, I'm allowed to do the same thing

cuz otherwise, only the bad actors will do it, and then that's bad. Now, what I do make sure to do is keep all of my security research um as visibly good intentions as possible. So, even things like where you saw that I got access to someone else's document, I try to avoid that wherever possible. I try to use my own test accounts. I try to make sure I'm always on my main IP. Uh I make sure that it is clear who I am, how to contact me, and that I am the person doing this in good faith. So, yeah, and if companies don't like it, well, that sucks, but I don't like it when my data

gets stolen. >> Good trade. Anybody else? Or wrapping it up? Don't see any more hands. So, I I think that's it. Thank you very much. Great.