Have you ever met an old stubborn mainframe guy that just can't think outside of his archaic box? I bet you did. This is a story about this guy I met sometimes ago..... (My friend Adriano called them "The Dinosaur". BTW, if you time, you should check out his piece on this.)
Application Owner dude: We are using mainframe and we have tight ACL in place. No one can access the data inside. It's a very secure environment. I don't see any security issues here... That web interface is just a front-end for customer to see their order status...We developed this one ourselves and manage the user accounts. It's not even open to public or guest, by the way....
Information Security lad: Well... we see that there are other internal applications interfacing with this mainframe as well. How do you ensure these interfaces are secure?
Application Owner dude: Again. As I have said and stressed for so.... many times. We have strong and tight ACL in place. Those interfaces are connecting to our mainframe with their own credentials and we make sure they can only access their part of data... <* keep bragging about how fantastic ACL works on Mainframe *>
Information Security lad: <* I need to do more to than just talking to this guy to show him that ACL alone is not enough *> We going to run some test.....
Application Owner dude: Go ahead lad... No one ever broken into our mainframe before. I'll bet my every pint of beer on that.
Information Security lad: <* Looking at applications interfacing diagram: I have an idea how to get that beer....>
Here are some facts:
1. Application A is accessible from internet. It's a demo site for Company XYZ's order management software.
2. Application A process data (order data) and stored some of the info in Mainframe.
I'll share what I've done... (it's a bit more complex in reality, but you'll get the big picture...). Basically the strategy was - "Attack A in order to exploit B"....
1. Poking around "Web Interface", tried XSS and SQL Injection. No luck. The login fields seem not vulnerable....
2. Poking around and noticed that Application A is a demo site and allows user to register an account to try the "order system".
3. Registered a dummy user. Created a test "order", insert some XSS script into some of the fields in the order form. Hit the "go' button. Order "saved" as ID 1337. Nice... :)
4. Went back to the Application Owner, asked him to login via the "Web Interface". Ask him to search for order ID 1337. Guest what? He just got XSSed.... his session cookie got hijacked (remember the XSS script I put in Application A?) and sent to my test mailbox somewhere...
5. I fired up my Firefox, went to "Web Interface", used the cookie info I captured.... viola! I managed to get access into"Web Interface" ;)
Application Owner dude: How did you do that..... I thought my Web Interface is secure.
Information Security lad: It is... but only from internet point of view. We know you did a good job in implementing the input validation mechanism there. We tried poking around with XSS and SQL Injection but no luck there. The issue here is not just your application. It's the environment itself because of the need to share data among various systems. Data is created in Application A, got transferred and saved into your Mainframe system. What we did was that we inserted some malicious code within the data in test "order" created in Application A. This "order" was then saved in your Mainframe. As one can view "order" from "Web Interface" as well, the malicious script got executed when you viewed that "order ID 1337". The malicious script contains code that capture your cookie information and send to my mailbox. We then use the captured cookie info to access your "Web Application".
As you can see, ACL did not help you in this type of attack... few issues here:
1. There is no input/output validation in Application A, hence malicious script was "accepted" by the Application A.
2. There is no input/output validation by Mainframe as the malicious code got saved there.
3. There is no input/output validation in "Web Interface" when retrieving data from Mainframe. If there was one, it's certainly not effective...
Application Owner dude: But I don't own Application A... I can't fix that... I have no control...
Information Security lad: Agree. But you have control over "Web Interface" and Mainframe. What can be done is to develop a input/output validation everywhere within you application. In a nutshell, your application will need to protect it's own ass. Don't just trust the incoming data, even it's from internal. In addition, you'll need to fix the session management mechanism in your "Web Interface" application as well. My recommendation would be for you to look at OWASP for development guideline and perform security test against OWASP TOP 10. And, rest assured that we will ask the Application A folks to do the same.
Application Owner dude: I see.....
Information Security lad: Now.. where is my beer? ;)
Moral of the story?
1. Protect your own ass. Don't trust any data even it's coming from internal. You have to have input/output validation on all application interfaces, especially in large organization where sharing and transferring of data between various applications is common.
2. Think out side of just ACL. The attack nowadays are more on application layer and data flow.
3. Always perform pen-test against OWASP TOP 10, during SDLC and before Go Live.
Ain't security fun? ;)
acknowledgement - photo taken from http://www.flickr.com/photos/origamiancy/3595747075/
No comments:
Post a Comment