 Without further ado, do you want to get started? Sure. All right, take. Well, thank you for coming to my talk. I appreciate it. I was kind of worried there'd only be like two people here. So I'm really happy that there's at least 20 people. So yeah, who am I? All right, so my name is Bill, if you didn't know that. I turned 18 this past July. I love breaking applications. I graduated from high school back in June. And I'll be attending RIT this fall. So what's my research about? So over the past three years in high school, I've really wanted to look at the different software that my school uses just because I think that it's a very valuable learning lesson. And I thought it was a really fun way of learning different aspects of web application testing by testing it on a real target like my own grading system. Yeah, so I kind of found more than I expected. That wasn't great. So yeah, let's quickly go over the different types of software I researched. The first piece of software I researched was the Follett Student Information System. But this usually goes by Aspen. My school specifically used them for grading, schedules, transcripts, pretty much everything that my school needed to use a school as software for. And my research into the Follett Corporation was primarily done maybe a little bit in ninth grade, but mostly in 10th, 11th, and 12th grade. Here's a map of Follett, and specifically the schools that were impacted by any vulnerabilities I found. So they primarily have a lot of schools in Massachusetts and Rhode Island, but they did have a few other schools in the United States. I just didn't think it was worth pulling up an entire map just because there are so few. So the second piece of software I researched was Blackboard Community Engagement. And so it was advertised of being capable of delivering news, academics, lunch balances, athletic details. Our school only used the notifications portions of the software, but I knew pretty fast after some basic research that other schools, you know, they used the entire suite of capabilities. And the research into Blackboard was done in two parts. First during 2017 to 2018, and then again near the end of 2018. So Blackboard does have a so-called bug bounty where they provide some sort of safe harbor for reporters, but this didn't really work out as expected. So here's a map of the Blackboard schools. This might not look as much as Follett, but it definitely is. I think it's about 10 times the schools Follett-Aspen had, so it's pretty prevalent in the United States. There were some schools internationally, but it was again only a few, so it wasn't worth putting them in the map. So to start off with, it starts with Aspen, you know, it's a Follett student information system. So for most user-supplied parameters, Aspen filters them for malicious input. The filter took the approach of sanitizing and removing malicious input rather than just dropping the request as a whole. So what would happen is if you gave it a malicious payload, it would reflect back the payload stripped of any malicious components, for example, a script tag. And then this was an interesting opportunity because if we can find a way to bypass the filter since the request still goes through, it would allow us maybe to do some attacks. Yeah, so it had a very big flaw by design. So if you took a basic string like script, prompt, hello world, Aspen removed the script tags because they blacklisted those and just ran out prompt to low world. But the flaw was that they only did this sanitizing run once. So what would happen is if I included a blacklisted tag inside of a script tag and then did prompt to low world and did the same thing with the end script, it would actually reflect back as script prompt to low world. This was a pretty simple vulnerability. I mean, cross-site scripting vulnerabilities are found all the time. The interesting part of that, this one was that this filter was used throughout the entire site. So if, for example, if you were able to bypass their little filter, you could pretty much reflect any XSS payload into a significant amount of parameters that were reflected into response. But also it was because this was like my first ever vulnerability in my school's grading system. And so it was really motivating to me to, you know, after finding one, it really encouraged me to look more because it just felt like, you know, when I was first starting, I would never be able to find a flaw in someone, you know, with a bachelor's degree in computer software, computer science. It just, you know, I kind of felt hopeless, but then after finding one, it really made me motivated that, hey, if there's one mistake, maybe there's more. So the next vulnerability was improper access control. Aspen runs on a Spring Framework on Java. And so for those uninitiated, the Java Spring Framework has these things called beans. From what I interpreted it to be, it seemed like they were structs or classes. But for example, you know, students have their own bean and there's instances of that bean. So in Aspen, a student bean has a name of SIS student. And I think this stands for Student Information System, but the issue again was that they had a security designed flaw. So they had a servlet called blob edit.do and this servlet was available for any logged in user, so including students, you know, I was able to access it myself. It took in three parameters. It had a read only, whether or not you wanted to edit the blob. It had an object ID specifier where you specify an object that you wanted to get the property from. And then property as string is the property name you actually wanted to get. And so what would happen is when you access this blob edit with, for example, a SIS student bean, you could read properties of that bean and you can do this for other bean instances as well. So when reading another student's bean instance, I was expected to be greeted by this insufficient privileges exception. I saw it before, you know, when I was trying to do an action that I probably shouldn't be doing, it would just raise this exception saying, by the way, Bill, you can't do this. But when I tried it on my friend's bean instance, I saw that I actually could access his properties, you know, the properties of his bean. And so after doing some investigating, I found out that I can edit and write to my own objects, you know, objects I own, and that I can read the properties of any other object, especially any other student object. So most of the properties of the SIS student bean were incremental in the form of like SCD field. It would be A through D, and then a number between zero to 110. And so this made it really easy to just write a simple utility to dump all the fields of a bean, especially a student bean. And the key thing is to remember is that if I had someone's student object ID, I could get all of these properties. And the student object IDs were, they're easily brute forceful, you know, it's like, I actually predicted it's like, it's very, my personal student ID was, bean ID was STD and then seven zeros. And then it was just MTA ASN. But, you know, the unique part of that was only the MTA ASN, which is five characters. So it wouldn't be that difficult to predict someone else's student ID, student object ID either. But, you know, I was able to access plain text passwords. My birth city, birth country, whether or not I can speak English, whether or not my family was into military, whether or not I had like financial problems and I needed, you know, assistance with the lunch, whether or not I was suspended, my special education status, my GPA. The funny part was that I could actually, for my own objects, like I said, I can edit it. So like, I can edit my own weighted GPA, which was pretty cool. And so the next vulnerability was external XML entity inclusion. So there's another survey called student recentactivity.do and it took in a parameter called preferences. Now preferences for some reason were supplied with XML. I don't know why they did that, but basically, you know, there'd be a preference set that would be passed in and different preferences you wanted to update. For example, one of them was a date range and it was an integer. And you would pass in, you know, the date range you want to see recent activity for. And Aspen did use Java's SACS parser to parse it, but the issue was that they didn't, again, they had a flaw by design. So in a secure system, the SACS parser would actually not allow document types or, you know, external entities, but the full corporation forgot to do so. I was able to send my own XML payload where I could, you know, grab file content from a system, you know, file path. I could say like file colon slash slash slash ATC slash password. And it would reflect back into date range, what I'd be setting for the date range preference. So Aspen actually had very verbose error messages, like whenever you trick the server into doing something, it would like print out a full stack trace of what happened. So it was pretty simple when, like I inputted file content for date range, it would try to parse it as an integer, but, you know, file content's probably not gonna be just a number. And so what would happen is it would say, hey, I can't parse this thing as an integer and end up actually reflecting the file content into response. So this was nice because, you know, I didn't have to send my data, sorry, file content over to like a remote server, which was a little bit complicated because of their internal firewall they had. But, you know, I made a small utility that allowed me to dump files and I found out that the Tomcat user, you know, I had access to anything the Tomcat user had access to. And having this, you know, file system access was really dangerous for them because it seemed like a lot of instances of Aspen were running on this one server. So the next vulnerability was a pretty straightforward local file inclusion. And how this worked was whenever you process the result of a tool, like a schedule tool or a grade tool, you'd be redirected to toolresult.do. And this sort of took into a get parameter file name and another parameter called download. So after running a tool, so as you say, like by or attempting to download a file using, you know, something that was generated by a tool, you'd be redirected. And so what you could do is actually use relative path escapes to escape, you know, the file name would be something like studentschedule.pdf and you can do, you know, ..slash, ..slash a couple of times to get to the root directory of the server and then you could do slash ETC password. And this really well complemented the previous vulnerability because what it allowed me to do was access binary files. XXC, you know, it has some trouble doing that. You can send it to remote servers but it gets a little bit complicated there. And this allowed me to get access to any binary files too. So it was a really neat vulnerability there to complement the previous one. So transitioning to Blackboard, I found some interesting pages while doing some subdomain scans. Two of them, the app manager and msupport subdomain looked interesting because I found out that they were running a little bit outdated version of Django but nothing too serious like critical remote code execution. But whenever I went to a page that didn't exist, I saw this neat verbose message saying that the page was not found and it also told me what other, you know, what regexes I could use to match a page on that root directory. And so I noticed that it said at the bottom, you're seeing this because debug is set to true. So what Blackboard had done is, you know, conveniently left debug set to true on two subdomains, the app manager and msupport subdomain. And so when I did some research into Django debugging, it apparently turns out that leaving this enabled is quite a serious issue because of how much Django prints out. So it turned out, you know, whenever you have an exception by code, it'll be really nice and actually print out the metadata for that code. So it would print out, you know, whatever server, you know, the settings that were running for that server instance. So the way I actually caused an error by code would be by using these two brackets and what it would do is it would tell the server, hey, I'm passing in an array. And since it was expecting, you know, not an array, just a normal value, it would throw an exception because it was trying to read a value that was an array and it wasn't expecting that. And so when an exception occurred, it would print out, you know, all the metadata and I found a lot of interesting stuff inside of that metadata. In the app manager subdomain, the metadata included to Jenkins Instance URL and an active API token to this Jenkins instance. This Jenkins instance was accessible to the public, meaning that, you know, I didn't have to go through their internal firewall or network to get to it. I had unrestricted API credentials to Blackboard Community Engagement. They had an API user that I think had access to pretty much all schools that were on the Blackboard instance. And I got admin credentials for M support subdomain and interestingly enough, I found 27 credentials to Apple's provisioning service. And, you know, these were 27 different districts. I think, you know, the subdomain suggested that, you know, app manager that these were school apps and school accounts for publishing apps to the app store. And so it was interesting to see that all this stuff just returned by metadata and the settings for the server. From the M support subdomain, I found out that the metadata included database credentials for pretty much every database and Blackboard Community Engagement had, admin credentials for the app manager subdomain and Jenkins credentials. Not an API key, but an actual user credential. Fortunately for Blackboard, the databases were behind an internal firewall. So, you know, an attacker couldn't just go and connect to it directly. But it was really interesting to see the passwords because let's just say they weren't very secure. One of them was like Romania, but with an at for DA. So going on to SQL injection, back in April of 2017, I, when I first learned that Blackboard Community Engagement was used by our school, I found out that, again, it was used for emergency notifications. And when I logged in, I could see that I had my cafeteria bounce on there. So I knew that my school didn't use it at all. You know, just very small stuff, maybe some notifications or some cafeteria stuff. But I researched a little bit into other schools using it. And I found out that a lot of schools use this as a main driver. So at the time I actually started looking at Blackboard, I think it was mid to late 10th grade. It was, you know, I barely knew anything. I knew a little bit of SQL injection, a little bit of cross-site scripting, but I was still a very much a beginner. And so I wanted to try to find a vulnerability on this because I knew that there was a lot of schools using this software. My method of finding vulnerabilities was, you know, really inadequate and unprofessional. It was just looking at pages I saw in Chrome web tools and trying to mess with the parameters. I saw this error message a lot, but unlike Aspen, Blackboard didn't have verbose error messages. So I didn't know what was going on, whether or not, you know, it was an SQL error or it was just some random code error. Like maybe it was expecting a type of input that I didn't give. But what I tried to do is, for parameters that responded to characters commonly used in SQL injection like, I don't know, apostrophe, double quotes, what I tried to do is I tried to put them through SQL map. So for the two people in here who don't know what SQL map is, it's basically a tool that you can use to automate SQL injection and you give it a parameter and you roll and it'll actually test the website for you automatically or that specific URL. You know, it won't scan an entire website for you, but it can really help you actual trade data and find any vulnerabilities that might not be as clear to a manual injection. Yeah, so I was just starting in InfoSec and I barely knew anything, but I actually struck gold and got an SQL injection. And it's this case it was Boolean-based blind, which actually was pretty good because time-based blind takes forever to exfiltrate data, but Boolean-based actually let me go mildly quickly with some multi-threading. So here's some very fun facts. In total, I found over four SQL injection vulnerabilities. Most of these SQL injection vulnerabilities were basic blind SQL injection and parameters related to user ID numbers. One of the SQL injection vulnerabilities I found in late 2018 was on the same URL I reported and in patched in early 2018. So what happened was in late 2018, in early 2018 what happened, I reported a page where there's a parameter vulnerable, but I guess I didn't look at the other parameters for that page. They patched that vulnerability, but then in the second set of research late 2018, I found that another parameter on the same page was vulnerable. So they basically patched this one parameter and didn't even look at other source code that was on the same page. Before we can see what I was actually able to, the impact of the vulnerability of the SQL injection, I needed to do some recon. So six databases were accessible. I found that the two interesting ones were primary one and a backup one. And the other ones seemed to be my SQL data default databases and there's a temp one that had nothing in it. The primary database had over 250 tables and they had very concerning names for sure. So basically what it seemed like was that I could access whatever the the web server itself can access, what it requested. There didn't really seem to be that many restrictions. Specifically, did tables exposed include school attendance information, whether or not students showed up to class, bus information, how they get home, cafeteria status and payment history, enrolled courses in course history, whether or not they've ever been disciplined before, their grades, their progress to graduating, their photos, some immunization and vaccination information, library balance and history, course schedule, whether or not they linked any social media accounts, but I don't know any student that would do that. I don't know why you would ever think that's a good idea. Their birth date, their hashed password, they use SHA-1. Yeah, crack station really helped with that. PIN numbers, school uploaded documents and contact information. So there's some more fun facts I'd like to share. There's over five million students and teachers in the system. I did this by counting the number of rows in the main, you know, account table. There's over 34,000 immunization records. Blackboard wanted me to say that apparently that in their terms of service, they don't actually, they tell you not to upload immunization table information, but it turned out that they dedicated a specific spot for it in the database, but they say in the terms of service not to upload anything. So I don't know how exactly that works, but there's over 5,000 schools impacted and you know in that map I showed you earlier, those were schools impacted and the database user's password is the lowercase version of the username. So it wasn't very nice to see that because it was my data too in there and seeing bad practices like that made me concerned. You know, what else was there? What else did they do wrong? To clarify though, this is from Information Access in March 2018. So I'm sure there's more students in there now, but or more immunization records. I'm not quite sure it's what's going on today, but this was the status back in March 2018 when I first, you know, right before I reported it. So I think it's kind of important to clarify, you know, what I accessed and what I didn't access, what my boundaries were. So I never accessed any other student data besides my, besides any authorized use. For example, you know, my own records, I did check to see that my information was in the account table. Any other information I gathered was either metadata, like number of rows. That's how I found out there's over five million students and teachers in the database, or it was not related to anyone's personal data, like database password hashes. The primary reason I kept investigating is because, you know, these guys were keeping my records as well and I didn't really feel comfortable until I knew how bad the situation was, just sending it over and saying, hey, here's the vulnerabilities. You know, it just felt like this was pretty crazy stuff that I was starting to see and I needed to see how much they really messed up. So disclosure time. I had a very, very interesting time trying to disclose vulnerabilities to the Follett Corporation. When I first found the XSS filter bypass vulnerabilities in ninth to 10th grade, I tried to reach out to Follett through my then school's director of technology. That pretty much led nowhere, you know, they weren't able to get a clear answer back from Follett. As I, you know, discovered the improper access control vulnerabilities, one of them stuck out to me. There was a vulnerability that allowed me to add a group resource to the group resources section. So Aspen has this group resources section where the school can upload helpful links and information, maybe the student handbook or, you know, back to school information. And so I found out that part of the improper access control vulnerabilities was that I can add my own group resource. So this meant I can add, you know, text and share it with what I thought was all students. So being an amateur or 11th grader, what I immediately did was I made a group resource and sent it out to everyone saying, yeah, Follett didn't really care about security. And yeah, so I just, you know, I did a little prompt, document.cokeys there down there. And what would happen is whenever you logged in to Aspen you'd see this on the bottom of your screen. Yeah. So I said my name in there because I didn't want them to make me look out like the bad guy, you know. Oh yeah, the student hacked into our systems and, you know, compromised student data. How bad of a person is he? And so what I did was, you know, I included my actual name and a message and I told them, you know, if they want to take it down just come straight to me. But what happened was I thought it would go to all students. It actually went to everyone in my district. So yeah, apparently like the director of technology got pulled out of their meetings and wasn't that good. This is a screenshot from my own phone and I actually got a notification saying, hey, from me. So the school wasn't really happy about it. I can understand. I only got off with a two day suspension and I was able to convince them that I didn't violate the acceptable use policy. Yeah, that's a big. I got suspended for creating a major disruption. Yeah, so, you know, two days off of school I think it's a pretty win-win. So looking back at it though now, you know, a few years later, I understand it probably wasn't the best thing to do. And for one of the biggest reasons I thought it would be a good idea was because at the time, you know, I was just getting into the industry, I didn't really know. So what do you do if a vendor doesn't have contact information or what do you do if a vendor, you know, doesn't even want to talk to you at all? So, you know, I was unaware of organizations like the CERC Coordination Center and so I took the mildly immature route of making a global message. So after tweeting images about what I'd done on Twitter, mentioning full learning in an attempt to get their attention, I actually got a reply. They were really helpful through direct messages and I'd set up a meeting with them, actually someone from the Aspen technical team. But then my school heard about this and they actually told them directly, don't talk to Bill. And I kind of feel bad for Follett because you know, my school was the one who paying some of the bills so they couldn't really be like, no, but we need to fix these vulnerabilities. But it was kind of, you know, shooting themselves in the legs because, you know, I was trying to help here and I was trying to get these vulnerabilities patched and they kind of delayed it for another semester. In March, 2018, after speaking with my principal, I actually coordinated with the district's director of technology and to set up a meeting with Aspen. So one thing I do have to notice once I reached out to my director of technology, Follett actually had a meeting set up, I think within a week. It was a pretty impressive response time. When I disclosed the bugs, they had to fix, you know, I think three weeks later in the mid-April of 2018. But overall the disclosure process was painless and they handled it pretty professionally. You know, they weren't like threatening me during our meeting. They're pretty chill and they're thankful for me disclosing these vulnerabilities. So fast forward to 2019, after I discovered and determined the impact of the XXC and L5 vulnerabilities, the disclosure process was a lot different. So, you know, school relation, me and the school, it wasn't that great of a relationship. You know, they were kind of pissed off that I was doing this security research into the software that they were using. They weren't really on board with that. And so I was able to coordinate with Carnegie Mellon University's CERC Coordination Center. And they actually helped me get in touch with the director of cybersecurity and privacy at the Follell Corporation. After a quick call, things were looking good. You know, he seemed happy to help and wanted to disclose these, wanted me to disclose the vulnerabilities to them. He's told me he was gonna set up a meeting with the Aspen development team. And I take a little bit, but, and I told them that specifically, I didn't wanna work with my school because like I said, our relationship wasn't that great. Understandably. So for a month, all I got was delays, like still working on the process, trying to coordinate a time. Please stay tuned. And before hitting a month of delays, I sent like a serious email, like dude, what's going on? And I had critical vulnerabilities to report. One thing I didn't really understand was my school's own district, director of technology was able to get a meeting with Follell within a week. But that was through like a customer success advocate. But now you're telling me the director of cybersecurity can't get a meeting in a month. That just seemed like a bit weird to me. You know, what's going on here? And so what does the director do when I tell him, you know, what's going on? Well, he tells my school everything and he tells them, hey, Bill is trying to report these vulnerabilities to us. And luckily at this time, it was like a few days after I graduated. Sorry, he had my diploma and they couldn't do anything. I was really happy about that. And so he contacted them, even though I told him not to. And the school basically banned all my accounts, even like unrelated email accounts. They were really unhappy about it. And so I was kind of tired of working with Follell there. I just sent a PDF with all the vulnerabilities and said, here it is, if you want to fix them, fix them. If not, that's your deal. And so it actually, you know, after I sent that PDF, they actually started paying attention and started working on fixes. This was fixed back in the end of July 2019, actually, right before DEF CON. So going to Blackboard, back in mid-2017, when I found my first test to injection vulnerability, I sent a report to Blackboard's security email. And their initial reply was good. They were like, yeah, thank you so much for reporting this to us. We're gonna do an investigation. We'll get back to you when we've completed it. After a month of no replies, I sent a follow-up saying, hey guys, what's going on? How's the investigation going? No response. A half a month later after that, I sent another email. No response. So yeah, I wasn't sure if I was just like losing it. Maybe I wasn't emailing the right email. This was 10th grade of me and I wasn't really used to vendors like leaving me on read. So yeah, I didn't really take it well. So what I did was I just said, okay, here's how I can tell if I'm crazy or not. What if I attach a mail tracker? And so that's what I did. And it said, Lauren security, read your email seven times. And so what I got really mad at this, right? Cause this is 10th grade of me. Like I think I was 16 at the time and these guys were ghosting me. It didn't really feel good. It hurt my feelings, okay? And so now looking back at it, I was like, wow, am I really that bad back then? And this was definitely one of those moments. And so I just wrote an email completely calling them out. Like guys, I know you're reading my emails. Please respond to me. And yeah, it was kind of bad too because this wasn't a paid bug bouncy program and it was kind of just wasting my time, my research, et cetera. And of course, they read that one too. So when they heard about this, they wanted me to include a fund statement. So their response to this entire thing was we're always working hard to improve. Sorry for ghosting you, Bill. And this is their wonderful, wonderful little statement. They had me say. So I never heard back from that email again, but I didn't give up. After disclosing default vulnerabilities, I decided to try to continue my disclosures and I wanted to work with my school back in March 2018. And I wanna work with them to try to report the Blackboard vulnerabilities. So the issue was, a few slides ago when I was talking about all the databases, all the tables, how many rows there were, et cetera, I kind of was worried that, how are they gonna take this? Did I break the CFAA? I didn't really know the law, but I knew that probably wasn't that cool what I did in the eyes of the court. So I said, hey guys, how about we negotiate a contract? Something that would protect me from, you know, hopefully prosecution. And so they sent me an initial contract within a week. But then I read the first thing it said, you know, it said, as of effective date, student agrees not to discuss with the vulnerabilities with any third party. And this was definitely a no-go for me. Because, you know, by the way, this didn't go through because I couldn't be here if I signed this. And so their own security policy said that after the vulnerabilities were patched, you can talk about it. So this was pretty crazy for me. I was under a lot of pressure from both the school and my parents because my parents had to co-assign the agreement. I was only like 16 at the time. And, you know, they were like getting worried as well, like, what are you getting me into, Bill? And so I compromised sort of second revision where it says that I tell Blackboard everything access and the vulnerabilities themselves. I don't disclose the vulnerabilities until they've been patched. I sent any publication 10 days in advance and comply with edit requests. That can be so-called reasonably deemed as exposing Blackboard clients or end users to security threats. And Blackboard agrees not to pursue legal action as long as I don't disclose personal data about other students or other confidential information. So Blackboard indeed did read some of the slides you've seen today. Specifically, they saw the SQL injection SQL lower slides and they saw the disclosure part. And they didn't see the other set of vulnerabilities like the sub-domain stuff because that was in the second set of research that I was doing. So after signing, disclosure was really stressful because the school, they were like, they didn't want to be in the middle of negotiations. I was kind of making a big deal. I was like, guys, this is not a fair contract. Apparently the school's own lawyer said, oh, this is a fair contract. And it was for the school, but it wasn't really one for me. He wasn't really representing my interests. And like I said, they weren't really happy about it, but after we signed a contract and my parents signed it, it was pretty painless. I disclosed our vulnerabilities in the meeting. The school grilled them a bit on why they ghosted me. And the vulnerabilities ended up being patched in the end of 2018, April at 2018. And so the next set of vulnerabilities including even more SQL injection and the information disclosure bugs that leaked important credentials was done with the help of the CERC Coordination Center at Carnegie Mellon University, their Software Engineering Institute. And they got in touch with Blackboard through their security email and we were able to work with them to patch to vulnerabilities. Something kind of fun was that I actually reported it anonymously and Blackboard didn't know that I was gonna disclose this CERC vulnerabilities about until a week ago. So, let's see what they think about that. It took a few months, but at the end of the day, the vulnerabilities were patched. The process that isn't that difficult and if you guys ever have any problems trying to contact a vendor, I strongly suggest you reach out to them because I think they might be able to help. So something kind of strange I noticed was that in October of 2018, I was trying to get a CVE for the vulnerabilities I found. And so I was trying to get, I tried to contact the CISO at the time and when I emailed her, it said that this email didn't exist in their system anymore. So I Googled, I thought maybe someone got a new CISO or something and then I saw this job offer from Blackboard. And so the interesting part about this was that the CISO apparently left right after my vulnerabilities were disclosed and fixed. So something kind of interesting. But you know, a few friends said, Bill, you should apply for it. I decided not to. I don't think I have the qualifications for it yet, maybe in a year or two. But it was still interesting to see that they left the company after my vulnerabilities. So to wrap up, a couple of suggestions for what we should do to prevent future incidents. First of all, no matter the company, schools should enforce companies to make sure that the products they use are safe. You know, schools have the most power here because they're the ones actually paying, you know, the school software vendors. And so they have a lot of control about what the company's doing, what the company's doing, what the company's doing. In schools, I think that they should require a third-party auditing of software where sensitive information is stored. It just, you know, it feels like when we take health data so seriously, but then we don't take the data of our own children as seriously, it just seems crazy to me because we're the next generation. I think we should hold companies accountable when negligent actions are taken. I hope the public does this with the revelation of my findings. And I think that we should understand where a sense of information is stored and not fall for marketing talk. You know, just because the company says, yeah, we take care of your data, doesn't actually mean that they take care of my data. So the reason I think this is such an important thing to take care of is because the next generation should be one of our number one priorities, you know, me included. It just feels like children can't defend themselves. You know, they don't know secure practices. They don't know how to make sure their data is being held in somewhere safe. And so I feel like parents and schools and should be the ones making sure that children's data are actually being stored in a safe environment. You know, I just can't believe we have so much regulation around health data and we don't have nearly as much regulation around school data or student data, especially because it's the data of minors. We shouldn't expect them to have their own data being controlled their own data. And so my question is that if a 16 year old can find a breach affecting millions of students and teachers, what can a nation state find? Do you feel comfortable with foreign nations having the data of your children? I wouldn't. So some thanks and they're very massively deserved is to the Electronic Frontier Foundation. They've been incredibly helpful throughout my entire research process and they offered me pro bono legal representation throughout the whole thing. The second thanks goes, the second piece of thanks goes to the CERC Coordination Center. They've helped with finding points of contact for both fallen and blackboard and assisting with disclosure in every step of the way. So I think we have a few minutes. If anyone has some dying questions they wanna ask me, I think we can ask them. So I don't know if my goon is here, the one running my talk, but he left, that's sad. Yeah, do you think if anyone has some questions they can come up and ask, I guess? All right, no one has questions, that's always great. Yeah, all right, come on. What were your parents' views on what was going on during this time? They told me not to do it. They were really unhappy with the contract, they didn't feel they wanted to be involved in anything like that. So it was mixed feelings, definitely. What are you gonna do next? Start college, maybe break their software. Did you ever get around to changing your grade? I can't answer that question. All right, well, thanks again for everyone coming out to my talk.