In order to fully demonstrate my Xssive project to my lecturers, I had to try and come up with something worthwhile. I needed a good way of showing them that it does in fact serve a purpose, and that through this tool, it is easier to demonstrate the dangers inherent in XSS vulnerabilities.
I took it upon myself to have a little look at DCU's Moodle for any potential Cross site scripting vulnerabilities. What I found surpassed my expectations. It was possible to embed malicious SWF files into any message a user could send. This included blog postings, profiles, private messages, calendar events etc... All of which could be set to be viewable by your class or your lecturers or inherently the Moodle admins. I knew I was going to have some fun demonstrating this. My lecturer got me two test accounts to play around with. A student account and a staff account.
I was able to create a malicious flash file that contained the vital hook code I needed to demonstrate my tool. I did this using flasm. You can see the malicious javascript within this dump of the disassembled hook.swf file. It was possible to embed this malicious object using the string mentioned in my previous SWF blog post.
The next step was checking if it worked on different users which is when I acquired the Test accounts. I Immediately began plotting escalation such as sessions stealing. This turned out to be quite difficult on moodle as it has methods of identifying a user based on their IP address. The next option available to me was to see if I could take advantage of CSRF, which it turned out was also easily possible.
Almost every page on moodle has a form of sorts within it, that normally contains the lovely sesskey item, this is a Session key that is used when submitting forms to verify the sender has the right permissions. It is normally useful at preventing cross-site request forgery attacks but in this case it was rendered useless. Thanks to Javascript injection I now have full access to all of the elements within the page. The hooked victims current user Id was also readily available. I took advantage of this and started creating Xssive modules for certain types of posts.
I was successfully able to carry out many actions as a lecturer. This included making forum posts ( ) along with basically any other type of post/submission. I could post course content that would be viewable by all of a class and show up in a notice on each of their own personal moodle pages.
Being able to carry out actions as a lecturer of a course is more dangerous than a little alert popup that is normally associated with and used to demonstrate XSS. You can carry out actions with escalated privilege, such as removing students from a class, heck maybe even changing exam results. My tool successfully made this clearer to the lecturer, which was the goal of the project. A tool to demonstrate the dangers of XSS in a simple way.
I also showed how this vulnerability could be abused to take over moodle further. Since it was possible to make posts to any of the various services moodle offer. It was also possible to post the same hook code I originally used in the initial attack. This results in a self spreading xss worm. Thanks to the Xssive tool you could potentially control all of the hooked victims individually. I only tested it with maybe 10 people simultaneously but it was indeed possible.
As I didn't have an admin account and didn't want to set up my own moodle app, I never tested the potential for abuse in this scenario but I assume the risks are the same. It may well have been possible to escalate your privileges indirectly to a moodle administrator. The XSS vulnerability has since been patched on our college moodle, it was exciting to find and I feel that my project went well overall as it carried out it's function.