Onderwerp: Blackboard Authentication Error

Hello,

Here at my university we use Blackboard as the chosen tool for having online class websites, grading, chatrooms, announcements, quizzing, etc., in a convenient fashion.

Blackboard works alongside our Kerberos authentication to be sure that the person who is accessing the information is the correct one.

Tonight I discovered that there is a way that Blackboard fails in doing this. When Blackboard has been idle for so long (ten minutes or so, I think), it will de-authenticate you from accessing resources. So, let's say I'm logged in as mrm5, I use it, th
en I walk away from the computer. If someone comes up and tries to gain access to the still-up Blackboard site, after they click a link they will be prompted with a password entry screen.

This presumably means that in order to access mrm5's stuff, you need to enter mrm5's information. But, instead, if you enter another user's information, such as ppq2, and enter the correct password for ppq2, you will now be logged in under mrm5's account
instead of ppq2's, and able to do everything that mrm5 could have if they were logged in, including changing personal information, "enrolling" in class, making posts on boards, taking quizzes, etc.

I have no idea and no way of checking to see if other universities are susceptible to the same problem, but either way this is something that
needs to be fixed.

-jehnx/Josh

Sounds like they have a session fixation issue on their hands as well
since they are reusing the session id upon reauthentication. But based
on your description it doesn't sound like they completely abandon all
data associated with the session upon the reauth.

-george

jdo24@cornell.edu wrote:

>Hello,
>
>Here at my university we use Blackboard as the chosen tool for having online class websites, grading, chatrooms, announcements, quizzing, etc., in a convenient fashion.
>
>Blackboard works alongside our Kerberos authentication to be sure that the person who is accessing the information is the correct one.
>
>Tonight I discovered that there is a way that Blackboard fails in doing this. When Blackboard has been idle for so long (ten minutes or so, I think), it will de-authenticate you from accessing resources. So, let's say I'm logged in as mrm5, I use it, t
hen I walk away from the computer. If someone comes up and tries to gain access to the still-up Blackboard site, after they click a link they will be prompted with a password entry screen.
>
>This presumably means that in order to access mrm5's stuff, you need to enter mrm5's information. But, instead, if you enter another user's information, such as ppq2, and enter the correct password for ppq2, you will now be logged in under mrm5's accoun
t instead of ppq2's, and able to do everything that mrm5 could have if they were logged in, including changing personal information, "enrolling" in class, making posts on boards, taking quizzes, etc.
>
>I have no idea and no way of checking to see if other universities are susceptible to the same problem, but either way this is something that
>needs to be fixed.
>
>-jehnx/Josh
>
>

jdo24@cornell.edu wrote:
> Hello,
>
> Here at my university we use Blackboard as the chosen tool for having
> online class websites, grading, chatrooms, announcements, quizzing,
> etc., in a convenient fashion.

> Blackboard works alongside our Kerberos authentication to be sure that
> the person who is accessing the information is the correct one.

What version of Blackboard are you talking about? Do you realize that the
Kerberos Authentication you're describing is non standard (to Bb), and the
problem you are warning about could be due to something unique to your
site?

For example, the issue really could be that Kerberos credentials are still
stored on the machine running the web browser you were using, and they are
being reused by the browser.

> Tonight I discovered that there is a way that Blackboard fails in doing
> this. When Blackboard has been idle for so long (ten minutes or so, I
> think), it will de-authenticate you from accessing resources. So, let's
> say I'm logged in as mrm5, I use it, then I walk away from the computer.

For longer than 10 minutes? Did the session timeout in Bb?

> If someone comes up and tries to gain access to the still-up Blackboard
> site, after they click a link they will be prompted with a password
> entry screen.

Session timeouts are a site-tunable parameter. If sysadmins of your
installation want to make this even less than 10 minutes, they probably
can.

> This presumably means that in order to access mrm5's stuff, you need to
> enter mrm5's information. But, instead, if you enter another user's
> information, such as ppq2, and enter the correct password for ppq2, you
> will now be logged in under mrm5's account instead of ppq2's, and able
> to do everything that mrm5 could have if they were logged in, including
> changing personal information, "enrolling" in class, making posts on
> boards, taking quizzes, etc.

What a user can do (enroll, etc) is also a site-specific parameter. Not
all installations of Bb allow the users to do all of the tasks you
describe here.

> I have no idea and no way of checking to see if other universities are
> susceptible to the same problem, but either way this is something that
> needs to be fixed.

I believe there was a bug and fix reported (at least 6 months ago, maybe
as much as a year) for some instances where sessions were not being
completely cleared out, and one user could "inherit" the previous session
of a different user. Probably your best bet for getting this fixed is to
report it to your local sysadmins. It's a distinct possibility that all
they need to do i install a patch or service pack.

Presumably, being a concerned and responsible person, you reported this
to Blackboard, Inc.'s support months ago, before mailing it to bugtraq,
right? In case you aren't, here's some contact information so you can
report the bug to the vendor, now that you've already reported it to the
world:

Blackboard customer support: (888) 788-5264

However, their support system is geared towards known contacts at
customer sites calling in, so you are probably much better off reporting
this to Cornell's help desk and giving the Bb sysadmins there the info
they need to determine if the issue is a local problem or something
Cornell can take up with Bb.


-johan

>
> jdo24@cornell.edu wrote:
>> Hello,
>>
>> Here at my university we use Blackboard as the chosen tool for having
>> online class websites, grading, chatrooms, announcements, quizzing,
>> etc., in a convenient fashion.
>
>> Blackboard works alongside our Kerberos authentication to be sure that
>> the person who is accessing the information is the correct one.
>
> What version of Blackboard are you talking about? Do you realize that the
> Kerberos Authentication you're describing is non standard (to Bb), and the
> problem you are warning about could be due to something unique to your
> site?
>

I'm not sure of what version, as I am awaiting the IT folks here at
Cornell's response to that question. I do indeed realize everything
you've said.

> For example, the issue really could be that Kerberos credentials are still
> stored on the machine running the web browser you were using, and they are
> being reused by the browser.
>

That's true. What I think it is, though, is a session id problem that
fails to do any authentication at all. We'll figure that out in due time.

>> Tonight I discovered that there is a way that Blackboard fails in doing
>> this. When Blackboard has been idle for so long (ten minutes or so, I
>> think), it will de-authenticate you from accessing resources. So, let's
>> say I'm logged in as mrm5, I use it, then I walk away from the computer.
>
> For longer than 10 minutes? Did the session timeout in Bb?
>

Nope, the Kerberos authentication timed out. It was a library computer,
so it's set to a very low time, but apparently it doesn't matter one way
or the other how low it's set to, because it doesn't protect from anything
at all.

>> If someone comes up and tries to gain access to the still-up Blackboard
>> site, after they click a link they will be prompted with a password
>> entry screen.
>
> Session timeouts are a site-tunable parameter. If sysadmins of your
> installation want to make this even less than 10 minutes, they probably
> can.
>

I realize this. This isn't a problem.

>> This presumably means that in order to access mrm5's stuff, you need to
>> enter mrm5's information. But, instead, if you enter another user's
>> information, such as ppq2, and enter the correct password for ppq2, you
>> will now be logged in under mrm5's account instead of ppq2's, and able
>> to do everything that mrm5 could have if they were logged in, including
>> changing personal information, "enrolling" in class, making posts on
>> boards, taking quizzes, etc.
>
> What a user can do (enroll, etc) is also a site-specific parameter. Not
> all installations of Bb allow the users to do all of the tasks you
> describe here.

Right, but that's not the point at all. The point is that people can get
into BB and do whatever has been allowed to someone else's account. It's
really irrelevent, IMO, what they can do... I was just putting those there
as examples, and to show the severity in my case, and - judging by the
emails I've received - many other peoples'.

>
>> I have no idea and no way of checking to see if other universities are
>> susceptible to the same problem, but either way this is something that
>> needs to be fixed.
>
> I believe there was a bug and fix reported (at least 6 months ago, maybe
> as much as a year) for some instances where sessions were not being
> completely cleared out, and one user could "inherit" the previous session
> of a different user. Probably your best bet for getting this fixed is to
> report it to your local sysadmins. It's a distinct possibility that all
> they need to do i install a patch or service pack.
>

I think you're right, and I think the people here have not updated it. It
has been reported to them before, I've learned, a few months ago, and
they've done nothing about it.

It may not be that issue at all, though, but it certainly could be.
Likewise, the information I heard about them not having updated it could
be untrue as well, though I *did* hear this from a higher-up IT person.

> Presumably, being a concerned and responsible person, you reported this
> to Blackboard, Inc.'s support months ago, before mailing it to bugtraq,
> right? In case you aren't, here's some contact information so you can
> report the bug to the vendor, now that you've already reported it to the
> world:
>

Thank you for the presumption, and I have already emailed Blackboard (from
another email address) with the issue's details.

> Blackboard customer support: (888) 788-5264
>
> However, their support system is geared towards known contacts at
> customer sites calling in, so you are probably much better off reporting
> this to Cornell's help desk and giving the Bb sysadmins there the info
> they need to determine if the issue is a local problem or something
> Cornell can take up with Bb.

The fact that people can't easily call in and report things to Blackboard,
and you need to be a "known contact," I'd also call a flaw in their
system, albeit in a bit of a different way.

I actually work at Cornell's helpdesk, and this is not an issue we deal
with. The higher up Cornell IT folks had been contacted, though, before I
submitted this bit to bugtraq.

>
>
> -johan
>

-jehnx/Josh

This is a customer specific issue related to their Kerberos authentication single sign-on application and not a vulnerability in the Blackboard product. The customer has been contacted and will be updating their environment. Customers running the Blackb
oard products do not need to apply any patch for this issue. Security issues about Blackboard products should be reported to security-alerts@blackboard.com

Doesn't seem to be the same on 6.3 with webserver passthrough as the authentication mode. Stuff like this is probably why they encourage closing the browser after logout (that's the default screen on logout since 6.0). At least the session keys don't ap
pear to be unsalted md5 hashes of an incremental session number anymore.