search

openwebwork / webwork2

Course management front end for WeBWorK
http://webwork.maa.org/wiki/Main_Page
Other
140 stars 164 forks source link

cookies for courses I haven't entered #2424

Open Alex-Jordan opened 4 weeks ago

Alex-Jordan commented 4 weeks ago

I have a bizarre issue that started happening Thursday morning. We did not make any changes to the WW server recently, and the local IT team doesn't think anything changed with the surrounding ecosystem. I should say that this is my production server, which is still basically the develop branch from roughly April. (I will upgrade to the release candidate in a week or two.)

Starting Thursday morning, many students across many courses began reporting that they were not getting into WeBWorK. Neither through LTI nor with password. The error message they get is the same as when I would try to log into four or more courses at the same time. (When this started, I had not yet applied the changes from #2391, but I did that this morning Friday). So I am instructing people to clear cookies, and now that they are under 300 bytes instead of around 1500, it will hopefully hold up.

Here's the weird thing: why are all the students accumulating session cookies? I managed to get two on Zoom and look, and both students had session cookies for many of our demo courses (listed at https://webwork.pcc.edu/webwork2 with demo-). But there is no reason they should have those. They did not recall trying to enter those courses. Then I looked at my own cookies, and I had session cookies for some of those demo courses too. And I still have them after applying #2391 and clearing my own cookies. Of course, I have not been entering those courses. I'm not sure yet what action triggers the creation of those cookies, but I will experiment.

And why did this all start roughly Thursday morning? On Wednesday, I was setting up one course for LTI 1.3, including adding an entry in the LTI course mapping. But that is the only thing that's happened to the server in recent times.

Alex-Jordan commented 4 weeks ago

These demo courses all have a guest login button. Is there any imaginable way that could lead to this?

drgrice1 commented 4 weeks ago

Finally. I found the right node to delete, and then was able to delete the post. That was annoying.

Now to the real issue. I am not sure how cookies for a course you have not signed into could get set. If you can find a definitive way to reproduce this, then I can probably figure it out.

Alex-Jordan commented 3 weeks ago

I have a working hypothesis about this. First, I think the extra cookies on my own device were legitimate. I suspect that after applying #2391, I logged into a bunch of courses to test that, and the demo courses were just easy to do that with.

In the course of investigating this, I found that starting very early Thursday, a bunch of SQL injection attempts were made. It looks like it was a systematic attempt, visiting every course's login page, and trying on the order of 100 variations on an injection attack. As far as I can tell it did not work. Good. But then I took the IP address from the failed login attempts and searched for successful logins from that IP address, and found many: in the courses where guest login is allowed. The attacker bot also was using guest login.

So my working hypothesis is that a bunch of students have some sort of trojan horse malware that is able to use their web browser to crawl and attempt SQL injection. And it is responsible for generating all the cookies. I guess the malware might be coordinated and all instances are trying these past few days to get in. Does that seem possible?

I've disabled guest access on all courses. I've hidden courses except for the ones that just have a week left, and we will hide all courses starting this summer. Even after doing that last night, at least one of the now-hidden courses that formerly had guest login access has been attacked in the same way this morning. So somewhere something remembers the paths to the courses.

On top of what I mentioned, I think I will start strongly encouraging WeBWorK only be accessed through LTI now. Once I upgrade next week I will enable 2FA for all users, which will help nudge people in that direction. Thanks for all the security work @drgrice1. We can see that it is needed.

drgrice1 commented 3 weeks ago

You hypothesis certainly sounds reasonable. If someone observed that guest logins were available and set malware up to act on that, it certainly would be possible (and probably not hard to do) to make it start signing in repeatedly.

Perhaps another thing to implement for guest logins is a captcha. That would potentially prevent that sort of thing, and still allow for having the guest login feature.

Alex-Jordan commented 3 weeks ago

I'm going to confer with our IT team on Monday. The most outlandish thing about my hypothesis is that all these students have the same infection that executed a coordinated probe/attack. It seems a little far-fetched, but not impossible. If it's true, maybe PCC should help them clear the infection.

Captcha would be good. Maybe for regular login too if 2FA is not is use.

Guest login seems like a hack. Instead of having "practice" users, there would ideally be no user associated to a guest login. I imagine that would raise all kinds of issues with code that presumes there is a user though, and that's ultimately why things are the way they are.

drgrice1 commented 3 weeks ago

Yeah, I have no better explanation for the cookies showing up in these students browser though at this point.

I agree that guest logins should not need a user. It was probably implemented that way because that was the easiest way that could be imagined withing the webwork2 authorization system at that time. I am certain it could be implemented without a user though.