Back in 2009, when I was still a college student, I was required by one of my online class to use a web-based application that allowed us to train and practice with Microsoft Office in a simulated environment. Without providing details on what the name of this application is, I can assure you that it is owned by a reputable educational company. Looking back over some of my much older blog posts you can see that while using this application, I discovered that it lacked any encryption at all. In other words, when you logged into the application, your password and all other subsequent data was sent in "plain text" across the network.
I tried countless times, through e-mail correspondence, to explain to the application's support staff that they had provided an insecure application for numerous college students to use. Each and every time I attempted to explain the problem, along with how to rectify it, I was "brushed off." Initially, their support explained to me that users' passwords are stored in an encrypted database on their servers. While this may be true, that doesn't help with how the password are transmitted as plain text into said "secure" server. I even explained, in as simplistic of a manner as I could, how I was able to capture the network packets associated with a user's login request and could easily read the password from within them. This, however, was rebutted with, "you can only capture the packets from the computer you are on and not someone else's." Alas, I finally gave up. Clearly, support either did not understand what I was explaining to them, or they didn't want to admit that there system was unsecured.
Fast forward to the present day. It has been over four years since I made my initial discovery, and surely the very same web application now has some level of security implemented, right?
Upon first loading the website, which is now quite spiffy looking, I once again notice the lack of an "S" within the URL. Thinking that I might be able to manually specify that I would like to load the SSL variant of the login portal, I change the URL from "HTTP" to "HTTPS." Alas, an error.
Oops! Looks like it doesn't allow HTTPS...
Looks like we've ran into a problem all ready. Still having some hope that the web application may have some level of security, I start up WireShark to begin my packet capture and attempt to log into the system. Naturally, the login fails, however it still provides me with the network packets I wish to analyze. After digging down through the packets, I see the following:
What could this "gibberish" mean?
Looking through this part of the packet, you can see the username I chose, testuser, and what seems to be an encrypted password. Could this be true? Did they really implement encryption, finally, after all these years? In order to verify this, it seems like a look at the source HTML code is in order.
This JavaScript function doesn't look quite like what I was hoping for...
Going through the login portal's source code, it seems as if I've found the JavaScript function that performs the encryption of any provided password. Unfortunately, merely looking at the name of the function destroys what little hope i had left. It looks as if they have implemented MD5 hashing for their password "encryption." If you've never dealt with MD5 hashing, I implore that you do a little research into and and as to why it is a flawed method of securing password. Essentially, it has been outdated for quite a long time as a means of security. In order to show how very little security it has provided to this web application, let's see what happens when I take my "encrypted" password and upload it to an online MD5 decrypter.
Not so secure, is it?
As you can see in the provided image, that so-called "secure" portal is still quite insecure. Yes, they have made some changes to the way the login portal works, however there is still a lack of security.
I tried countless times, through e-mail correspondence, to explain to the application's support staff that they had provided an insecure application for numerous college students to use. Each and every time I attempted to explain the problem, along with how to rectify it, I was "brushed off." Initially, their support explained to me that users' passwords are stored in an encrypted database on their servers. While this may be true, that doesn't help with how the password are transmitted as plain text into said "secure" server. I even explained, in as simplistic of a manner as I could, how I was able to capture the network packets associated with a user's login request and could easily read the password from within them. This, however, was rebutted with, "you can only capture the packets from the computer you are on and not someone else's." Alas, I finally gave up. Clearly, support either did not understand what I was explaining to them, or they didn't want to admit that there system was unsecured.
Fast forward to the present day. It has been over four years since I made my initial discovery, and surely the very same web application now has some level of security implemented, right?
Upon first loading the website, which is now quite spiffy looking, I once again notice the lack of an "S" within the URL. Thinking that I might be able to manually specify that I would like to load the SSL variant of the login portal, I change the URL from "HTTP" to "HTTPS." Alas, an error.
Looks like we've ran into a problem all ready. Still having some hope that the web application may have some level of security, I start up WireShark to begin my packet capture and attempt to log into the system. Naturally, the login fails, however it still provides me with the network packets I wish to analyze. After digging down through the packets, I see the following:
Looking through this part of the packet, you can see the username I chose, testuser, and what seems to be an encrypted password. Could this be true? Did they really implement encryption, finally, after all these years? In order to verify this, it seems like a look at the source HTML code is in order.
Going through the login portal's source code, it seems as if I've found the JavaScript function that performs the encryption of any provided password. Unfortunately, merely looking at the name of the function destroys what little hope i had left. It looks as if they have implemented MD5 hashing for their password "encryption." If you've never dealt with MD5 hashing, I implore that you do a little research into and and as to why it is a flawed method of securing password. Essentially, it has been outdated for quite a long time as a means of security. In order to show how very little security it has provided to this web application, let's see what happens when I take my "encrypted" password and upload it to an online MD5 decrypter.
As you can see in the provided image, that so-called "secure" portal is still quite insecure. Yes, they have made some changes to the way the login portal works, however there is still a lack of security.
0 comments:
Post a Comment