About Studia.is and the exploit that was in it

During my last blog post, some people may have misunderstood my motives for this hack and the reasons why I would want to hack studia.is. For that reason I will try to explain my motives as well as a detail explanation on how it worked in hopes other people don't make the same mistake.

As of now, the exploit has been fixed and the website is no longer vulnerable through that exploit.

My intentions

One of the things that scare me the most is the amount of information stored in Inna.is. All of students grades, their history as well as their password is stored in cleartext. If you have email access on one of the teachers registered at Inna, you can retrieve their password in cleartext by clicking “forgotten password”. Through this method, you will be sent the original password because the system doesn't generate a new one. It scares me how much information is stored there, personally as well as professionally.

This brings me to Studia.is. Studia developed a School Management system called MySchool that has direct access to Inna. Inna has a protocol that allows you to communicate with it and MySchool, caching personal information like username and password. If you gain the password from MySchool, you have direct access to the source from there. That is why I feel that it is very important for MySchool to be properly secured. If their system is secured, I can rest easily. That is why I did that penetration test.

After locating this vulnerability I sent the administrator there an email informing him about this vulnerability as my intentions were purely from a pentester point of view. As such, this exploit was locked before the previous article was even posted.

Here's hoping the system administrator also checks other parts of the system as well. Once an vulnerability of this scale is published, all of the site code could have already been leaked. A good website is secure even if the source code is public.

About the exploit

The exploit is most likely due to old codes dated back when the system was being created. It is obvious from checking the Download.asp that the code has been build on and modified many times. The most obvious evidence for this is the switch for 'action' that gets posted:

select case action  
case 0:  Call Show_Directory(sFileName) 'This is the default if no action is posted. This is where the exploit is  
case 1:  call Download_skil_nemenda  
case 2:  call Download_Lysingu  
case 3:  call Download_Material  
case 4:  call Download_Lectures  
case 5:  call Download_Exams  
''    Case 6:  Call Download_Exams_Image  
Case 7:  Call Download_Application_Attachment  
Case 10: Call Download_Library  
Case 11: Call Download_CV  
case else:  
if bError then  
response.write "Error: " & sErrorText  
else  
response.write "Error: Unknown action"  
end if  
end select  

You can't use the exploit unless you are logged in. Unfortunately the session from namsnet.is/tskoli bypasses that. The website checks if the user is logged in, not if he is admin or not. You can see this from the following line:

Private Sub Show_Directory(sFileName)  
  Dim s

  If len(Session("User")) > 0 then
    'Continue with the code
  Else
    Response.write "You are not logged in"
  End If
End Sub  

The second thing about this exploit is that usually when an error occurs the error gets logged and the userid gets saved along with it. Unfortunately the Show_Directory is the only function in the Download.asp that does not log the error if any occurs. For this reasons, this exploit could have gone unnoticed for weeks, months or even years.

One last thing about the code is that it seems to be a test code created way back when the system was new. The reason one might think it's secured is because you have to be logged in. However during the course of the system growth, session info was transferred between the systems and made this vulnerable open. If the session was from a different domain and a different part of the system then this would not have be a problem.

My last note is to everyone that might end up reading this: Please secure any part of your code that sends files directly to the user. This is the most easiest way to accidentally leave vulnerabilities.

That's it for me today.

Show Comments