Wednesday, April 9, 2014

HeartBleed vulnerability

Was about to write about this, meanwhile found this post very useful. Why to reinvent the wheel?
So here you go:
Written by Rahul Sasi.

Tuesday, March 11, 2014

Password reset feature in single user, isolated environment applications

I came across one application while doing security assessment and found that they were using default admin account.And that too the admin account was having credentials as admin:admin. Catastrophic, isn't it?
I raised this issue before completing the assessment with the developers. They had their usual excuse- this was introduced to help user reset their passwords through the web application and since the web application was supposed to be used by singles user. It was essentially a single user environment. The web application was running locally on their individual laptops and the laptop was being plugged on the LAN just for few moments to reset some device readings.

Now the risk was:
Even a momentarily the laptop was connected to local network, the default admin account's presence was known to every other user. If they change the password using the default account then?
Though this was single user environment and only very few users were supposed to use the application on their individual laptops, we can't ignore the risk.

But then there's was no mechanism to reset the password as there was no email accounts associated or nor admin present to reset the password. It was very simple web application to just record and generate reports about some sensors' health.

So after brainstorming, we proposed the following solution in this kind of single user and isolated environment without compromising with usability:
Implementing a feature of local password reset in this single user environment. Develop a CLI (Command Line Interface)/ console based utility which changes the password locally on the machine, rather than providing this facility as web interface as this might be accessed remotely. The utility directly resets the password into database from command line. This approach provides both security and usability in current single user

Monday, February 3, 2014

Testing strategy for Controllers

Controllers are an essential part of ICS (Industrial Control Systems) network. Generally they are interface to many field devices such as sensors and placed within closed network. Exposing them outside world may be disastrous and they can be configured/ mis- configured to carry put attacks which can have dangerous impact on human being's life and safety.

So, it's necessary to do a security assessment of ICS networks to uncover potential vulnerabilties.
In brief, to test a controller we need to:
  • Understand the entire architecture- the platform, technologies, protocol it understands. Do a quick threat modeling here.
  • Review Network architecture, see how the controller is placed, ideally it should not be reachable from internet.
  • Firmware testing: Most of the controllers have embedded systems on them. Do a firmware testing here-
  • De compiling, modifying, patching, looking for hard coded sensitive credentials. How the firmware is uploaded/ downloaded- how secure is the mechanism.
  • Do host level review- Check if the controller is running any unnecessary/ insecure services, open ports, older software versions etc.
  • If web interface is enabled, do a testing from web app level security assessment.
  • If controller is using any proprietary or open source protocol, read the manual and try to understand the stack, what all security issues were discovered historically, what all tools are available in market to test them.
  • Get in touch with developers who work day in out with the technology.

Monday, January 6, 2014

Some general guidelines for a secure firmware

Encryption: It prevents reverse engineering of the firmware. The firmware might be stored in
encrypted form and only decrypted when it is to be executed, or it might be decrypted during the
firmware update process.
• Signing: is concerned with ensuring that a message has not been corrupted or modified while in
transit. This is important since a malicious user cannot be allowed to alter the firmware originally
delivered by the firmware producer.
• No hardcoded credentials: The presence of hard-coded accounts that can serve as backdoors to
• Code obfuscation: it makes runtime analysis difficult.
• Authentication: Make it difficult for unauthorized users to obtain the firmware updates. Make it
restrictive, less exposed.
• If the device is capable of being networked, no unnecessary services are running and ensure that it can also alert and log when firmware has been updated.

Wednesday, December 4, 2013

Reversing Firmware

The article will explore various strategies for reversing firmware, with some examples. Finally, some best practices are mentioned.

LINK here: 

Thursday, November 7, 2013

Salted hash implementation in Login, in nutshell

The best approach would be hashing the passwords, instead of encrypting them as key management becomes an issue.

Benefits of passwords in form of salted hash:
·         Real passwords are never stored/ displayed/ logged in the system
·         Salts makes dictionary attack very impractical as it’s very difficult to generate    re-computed hash table as salts are random
·         It’s easier to implement as no need of key management

A general approach would be like this (when storing):
·         Generate a long random salt using cryptographically strong functions such as SecureRandom in Java, when user is first time registering himself
·         Use the above salt and hash it with the user’s chosen password using standard and strong hashing algos like SHA 256
·         Now strore the Username, salted hash and respective salt in DB

When retrieving (authenticating user):
·         When the user submits his username-password, retrieve the user’s corresponding salt
·         Concatenate the salt with the user supplied password and apply the same hashing algo (SHA 256) and compute the salted hash
·         Now compare the newly computed salted hash with already stored salted hash against the username
·         If they match, let him in otherwise throw a generic login error, such as ‘Invalid Credentials’

Client side vs. Server side:
·         Always do hashing on server side, irrespective of client side hashing
·         The issue with client side hashing is , even it’s not in clear text, it is as good as a clear text password
·         If you do client side hashing, you need to depend on Javascript, which sometimes is disabled by user, or some browsers may not execute properly
·         Client side hashing is not replacement for TLS/ SSL. Protect all sensitive pages, such as login page over SSL

·         You may not be able to recover user’s original password, if user forgets it as the passwords are not in clear text. You can just users to update with a new password

Monday, October 7, 2013

Ajax Security Issues

My article on Ajax issues: