Further to my earlier posting. Investigation leads me to believe that
the same basic vulnerability may exist in other VLE software products
both commercial and open source in addition to the one that was reported
to me last month.
I have started work on a suitable fix for VLEs based on the Java Servlet
specification - I'm afraid this may take a while since I have no access
to funding. I will _not_ be releasing the fix as open source since
analysis of the source code will in effect make public the vulnerability
which it addresses. However, I will make it available to my own current
and past clients at no cost in the form of plug-in binary code on
condition that it isn't redistributed or reverse engineered. I may
choose to release the source code at some point in the future when the
vendors of other products have had time to make their own fixes.
While trying to avoid giving away too much information in a public forum
I would like to impress on developers of other VLE software the urgency
of reviewing security in their own products. If you are a lead
developer and I can verify that you are a lead developer I will provide
more information in confidence - enough to allow you to determine if
your own product is vulnerable. Any server side application which for
any reason collects data from users for display to other users (e.g. a
message board, questionnaire etc.), which allows users to upload web
pages or fragments of HTML and which also makes use of a certain popular
method of user authentication may be at risk.
Sooner or later full details of which software products are vulnerable
and methods for exploitation will leak out. Therefore speed is of the
essence.
Getting back to advice for sysadmins - there may be some danger that the
VLE might open up access to other campus systems - if you are using
certain low-security types of single sign-on technique. At least review
the security offered by the single sign-on system that you are using and
if necessary consider a switch to something better. If your VLE itself
provides a gateway onto student personal data (e.g. address, date of
birth or national insurance number) I would seriously recommend that you
consider suspending that functionality for the time being. Making as
much obligatory use as possible of X509.3 digital certificates for
authentication to sensitive databases is advisable since this is a
proven high-security method and the development of necessary
infrastructure has been well supported by JISC and other organizations.
Some UK universities have considerable in-house expertise in the use of
digital certificates and have published very valuable information on
implementing them on a large scale.
Jon
Jon Maber wrote:
> A brief heads-up for VLE administrators.
>
> I learned today that one of the major commercial VLE products has a
> massive security hole in it which will allow a user with minimal
> security rights to hijack a more privileged user's account and
> possibly also log in to other enterprise systems in the same domain
> such as student information systems. The obvious malicious use would
> be for a student to edit his or her own marks but it could also be
> used to access personal details of other students for use in student
> loan fraud etc. Exploiting the vulnerability requires some technical
> expertise - at about the level of an average computer science
> undergraduate.
>
> I can't give further details since the vendor has not yet come up with
> a decent fix (although I understand that they have known about the
> vulnerability for at least a month.) My contact says that the vendor
> has provided hes university with some interim patches which are only
> partly effective. I would hope that their other customers have been
> told about these patches. My advice is that whatever product you are
> using you should contact the vendor and ask for the latest patches and
> repeat this frequently - there are likely to be a long series of
> 'sticking plaster' patches before the definitive solution is
> developed. I'll give more information if I find out that a proper fix
> has been produced and distributed to customers.
>
> If you know all about this please don't identify the vendor, the
> product or the nature of the vulnerability on the list since this
> could leak out and provide hackers with valuable information.
>
> Jon Maber
>
> ***************** List information: *****************
> Remember - replies go by default to the entire list.
> Access the list via the web on http://www.jiscmail.ac.uk/lists/vle.html
> To unsubscribe, email [log in to unmask] with the message: leave vle
>
***************** List information: *****************
Remember - replies go by default to the entire list.
Access the list via the web on http://www.jiscmail.ac.uk/lists/vle.html
To unsubscribe, email [log in to unmask] with the message: leave vle
|