Re: Blackboard Authentication Error

["Joshua Ogle" <jdo24 () cornell edu>]

> 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