Security Issues in OpenStack Object Storage

Presenting the results of Master thesis project concluded my 2-year study program at NordSecMob Master's Programme in Security and Mobile Computing. During my thesis project I analyzed security issues in OpenStack Object Storage - an open source cloud storage software. Even though I worked on the project in Norway, the presentation itself was given in Denmark.

Some of the findings were quite interesting. For example, isolation of files belonging to different users is implemented using hashing algorithm. Your account name, file name, and directory where the file is stored are combined with secret hash and passed to MD5 hash function. The output determines the location of file on the server. When we changed MD5 to a dummy hash function that returned the same value for every input, users could read and even overwrite files belonging to other users. Even though MD5 is resistant to pre-image attacks (we can't find input that will hash to a known output), MD5 is not resistant to collision attacks (we can find two inputs that will hash to the same value.)

The isolation approach allows an interesting attack to be executed against a cloud provider that uses OpenStack. First, attacker negotiates contractual agreement with the provider according to which the latter is responsible to prevent loss of data of the former. Second, attacker generates two file names that will hash to the same value. Then, attacker uploads these two files to OpenStack and second file will overwrite the first one. Now, attacker can sue provider for data loss. OpenStack has a mitigation against such an attack, which is a secret hash value that is stored on the server and used as a salt to hash function. But with an insider knowledge of this hash the aforementioned attack is possible.

Another issue we found is scary. In the default authorization system that ships with OpenStack Object Storage, there is one type of administrators that can download or even delete files belonging to any user on any of the accounts. This admin is called Reseller Admin, and of course his broad permissions are mentioned nowhere in the documentation. So, if you your company has divisions in US and Europe, and you are a Reseller Admin in, say, Germany, you can view files belonging to users in US. Quite cool, isn't it?

Full text of the thesis is available at this link. The presentation slides are here.

Security Issues in OpenStack

---

http://www.linkedin.com/in/oldbam

From Proof-Carrying Code to Agent Technologies

I am taking a course on "Language-Based Security" at Danish Technical University. After listening a couple of lectures on Proof-carrying code (see [Nec97]) we were given a task to devise a proof-carrying architecture (PCA) for data exchanges. The idea of the PCA is the following. The data provider specifies the security policy for the data consumer to obey, and the data consumer provides a proof that he can satisfy the defined requirements. For example, in case of a customer submitting his credit card data to the web-shop, the former might demand from the latter to use specific data encryption algorithm, say 3DES, and to check that all communication partners encrypt data before sending it on.

The problem with the above requirements is the control over the data. Even if the web-shop can provide a proof that it is capable of using 3DES on the way from the customer to the web-shop, there are no guarantees that on the way from the web-shop to the bank the same security standards will be used. While thinking over the possible implementations of the PCA, I came to the conclusion that a possible solution lays in utilization of the agent technologies.

Here is the description how this scheme can work. The customer creates an agent, sets data and specifies the security policies for the data transfer and manipulation. An example of such a security policy might be the following:

• Encrypt data before sending over the web using Triple-DES
• Allow Visa payment provider to retrieve the credit card data
• Allow web-shop to redirect the agent to the payment provider
  

Before executing operations (eg. "get data") the agent will check the caller's credentials to verify that such an operation is allowed for the given caller. The idea behind this is that the web-site does not really need to see the credit card data, all it wants is the confirmation from his bank or payment provider that money were transfered. That is why, the agent allows web-site to redirect itself to the payment provider, but not to get the actual credit card details. And of course additional data (eg. account details to which the money should be transfered) can be set upon an agent with its own security policy.

Here is the possible flow of interactions:



Well, the above approach has a lot of issues to consider.

[Edited on May 20, 2010] Below each issue there are some hints I received from Lawrie Brown :

1. How to verify caller credentials (probably the agent may consult the certification authority, like Verisign)?
   

   Lawrie: Check the certificate signature using the well known public key of the signing CA, and also contact the CA to check the Certificate Revocation List (CRL) to ensure that the certificate has not been cancelled for some reason.

2. Which encryption techniques to use? Let's say we want to allow both Visa and Mastercard payment providers to get actual card information. But we do not know in advance when we configure the agent which exactly provider will be used by the web-shop. And the web-shop should itself not be able to decrypt this data even if it obtains it from the agent's code. If we use asymmetric cryptography we will need to store two copies of encrypted data for each of the providers. But if we use symmetric cryptography, we would probably not want to send the key within the agent.
   

   Lawrie: You would store ONE copy of the data, encrypted using a block or stream cipher with a temporary randonly created session key. And then store two copies of that key, separately encrypted using the providers respective public keys. This means the agent can send the encrypted data, along with the relevant public key encrypted session key, to the desired recipient. And no-one, looking at the data carried by the agent, would be able to recover the encrypted info apart from the two providers who are the only ones with suitable private keys needed to recover the session. This process can of course be extended to more than two providers.



3. How to secure data within the agent from illegal obtaining by code inspection or disassembling?
   

   Lawrie: This to me is the really big issue, how does the sender know the agent has not been corrupted, or the actions/answer compromised? Thats the fundamental issue behind the use of agents, and I don't know the answer.

Despite the problems and immaturity of the agent-based systems, my prediction is that in some years we will use agents on a regular basis. Time will show... ;)

[Nec97] George C. Necula. Proof-carrying code. pages 106-119. ACM Press,
1997.

---

http://www.linkedin.com/in/oldbam

Security: Monitoring Your Geographical Log-in Location

When eliciting software requirements for the student project I have found the draft of the OWASP guidelines for identification and authorization here. One item in the list attracted my attention:

1.15 Concurrently, the system should perform velocity checking against the IP address of the last known valid log-in from that user so as to ensure the user is logging in from an IP address range originating from within that country of origin. It would be not be feasible to expect a user logging in from one geographic location and then from another within a specified amount of time, e.g., Correct credentials supplied from a user originating from the United Kingdom at GMT 10:00Hrs and a second log-in attempt from a user in Venezuela at GMT 10:27Hrs.


Earlier I have seen that Facebook performs a similar validation. When you are logging in from a different location, Facebook provides the following validation screen:



However, there might be problems with Facebook's approach, since it might be not difficult to discover the person's birthday (try a google search to find out your own birthday, chances are that you will be impressed ;).

---

http://www.linkedin.com/in/oldbam