Smart Security by Dharmesh M Mehta
An Application Security Blog
Wednesday, September 28, 2011
Wednesday, July 27, 2011
7 UID bogus centers shut down
In what comes as an addition to fraud incidents in the city, seven Unique Identification Centers were shut down by the civic corporation on Monday. The Thane Municipal Corporation (TMC) closed down these seven bogus UID centers where several citizens have already got their UID forms enrolled.
However, the process will be declared as void as these centers are not legal. The seven mentioned centers were operating without any permission from the authorities since the past few months. Two centers in Panchpakhadi, Lokmanya Nagar and Khopat each and one center in Vrindavan society were shut down by the municipal corporation. The TMC has made it clear that citizens who enrolled themselves in these centers will not get their UID cards and will have to enroll themselves all over again at an authorised centre in the city.
Informed sources from TMC maintained that Vakhrangee Software Ltd. was using a bank's name to provide UID cards to citizens and some Maharashtra Navnirman Sena activists were believed to be running the bogus centers. It is learnt that a corporator informed the civic body about the bogus centers following which the TMC took a stern action and Additional Commissioner of TMC, L R Gupta, summoned Rahul Devpal, the owner of the software agency. During interrogation, it was revealed that these centers were bogus.
Many citizens have already enrolled themselves for the scheme but will again have to redo the process. A woman requesting anonymity said, "My son went to the center at Vrindavan Society and waited there for around four hours to get himself enrolled. All those efforts have proved futile. The civic body had opened 40 such centers in the city this year and each center enrolls 50 person's UID forms each day. The government had allotted the work to authorised banks, government undertaking organisations and others. The central government started the UID scheme which is also known as Aadhar to provide citizens a 12-digit identification number under the Unique Identification Authority of India.
However, the process will be declared as void as these centers are not legal. The seven mentioned centers were operating without any permission from the authorities since the past few months. Two centers in Panchpakhadi, Lokmanya Nagar and Khopat each and one center in Vrindavan society were shut down by the municipal corporation. The TMC has made it clear that citizens who enrolled themselves in these centers will not get their UID cards and will have to enroll themselves all over again at an authorised centre in the city.
Informed sources from TMC maintained that Vakhrangee Software Ltd. was using a bank's name to provide UID cards to citizens and some Maharashtra Navnirman Sena activists were believed to be running the bogus centers. It is learnt that a corporator informed the civic body about the bogus centers following which the TMC took a stern action and Additional Commissioner of TMC, L R Gupta, summoned Rahul Devpal, the owner of the software agency. During interrogation, it was revealed that these centers were bogus.
Many citizens have already enrolled themselves for the scheme but will again have to redo the process. A woman requesting anonymity said, "My son went to the center at Vrindavan Society and waited there for around four hours to get himself enrolled. All those efforts have proved futile. The civic body had opened 40 such centers in the city this year and each center enrolls 50 person's UID forms each day. The government had allotted the work to authorised banks, government undertaking organisations and others. The central government started the UID scheme which is also known as Aadhar to provide citizens a 12-digit identification number under the Unique Identification Authority of India.
Tuesday, July 26, 2011
Mobile Apps Security – Are you worried?
Smart Mobile devices are now increasingly been adopted by the consumers and in the enterprise leading to a number of organizations interested in custom development of mobile applications. Software vendors developing mobile applications are on most occasions feeling enormous pressure to meet extremely tight Go to Market timelines. This often leaves security neglected or compromised.
The trends already mention mobile apps taking a plight in the financial sector, with online banking, online trading apps. Security, although a prime driver for custom development, is one of the hardest aspects to get right. The industry is starting to see the security & privacy concerns in developing mobile applications. Initiatives and best practices are been released by groups like OWASP that have been addressing mobile security in a big way. There is a need to leverage the native security APIs of the platform, handle sensitive data with care, and choose the right data protection classes for the mobile application architecture. Let us make an attempt to look at few critical weaknesses you should be worried about while developing mobile applications.
Data Stored on Mobile Devices
In most mobile application designs, it is observed that the mobile device stores or caches some information. Due to limited constraints on the space availability on today's mobile devices architects go ahead and exercise this option. People often default to storing the sensitive information too in clear text. Mobile platforms like Android and iOS are susceptible to rooting or jail breaking, which gives users unrestricted access to the underlying file system. Using this root level access, malicious users or malicious applications can easily retrieve the sensitive information stored on the device.
Weak Cryptography
Data security is another concern when in transit or stored. While choosing to store sensitive data on mobile devices, designers often employ encryption techniques. Few platforms like iOS do provide API's to encrypt data; however, these platforms are yet to get a strong key management technique or protocol. Android too provides APIs for cryptographic primitives, but no built-in protocol for key management. Designers may find themselves having to make decisions about what to use to generate keys, how to use them, and where to store them. Often they end up selecting a strong encryption algorithm, but choose a poor key management protocols. When you have weak cryptography design and keys are stored on the device, shared between users, or hardcoded, they do not provide adequate protection to the data.
Moving Substantial Business Logic Client Side
Designers tend to move a substantial amount of business logic to mobile devices unaware of it implications. When developing rich client applications, users are given direct access to a particular service, while maintaining a simple and attractive user experience. Incorporating business logic such as password re-verification can often lead to unexpected security issues. Like web based attacks, a malicious attacker could use a simple HTTP proxy that captures requests and responses and alter the response from the server to bypass security controls built in by the application’s logic.
Relying on Client Side Data Validation
In current business scenarios, users need to access enterprise applications both from the web and the mobile devices. Attackers have been abusing the weakness of client-side data validation in web since long time now. Data validation weakness has crept into application development in the mobile application space. Hackers can easily bypass client side data validation by using a proxy between the mobile app and the server.
There’s the old joke about two hunters running from a lion, and the one runner says to the other: we can’t outrun the lion. And his buddy replied, “I don’t have to outrun the lion, I only have to outrun you.” Many, over the years, have applied the same logic to application security: If their software is ‘secure enough’ attackers will move on to easier targets. Mobile application security is an easy target for attackers currently and you need to address security on priority.
The trends already mention mobile apps taking a plight in the financial sector, with online banking, online trading apps. Security, although a prime driver for custom development, is one of the hardest aspects to get right. The industry is starting to see the security & privacy concerns in developing mobile applications. Initiatives and best practices are been released by groups like OWASP that have been addressing mobile security in a big way. There is a need to leverage the native security APIs of the platform, handle sensitive data with care, and choose the right data protection classes for the mobile application architecture. Let us make an attempt to look at few critical weaknesses you should be worried about while developing mobile applications.
Data Stored on Mobile Devices
In most mobile application designs, it is observed that the mobile device stores or caches some information. Due to limited constraints on the space availability on today's mobile devices architects go ahead and exercise this option. People often default to storing the sensitive information too in clear text. Mobile platforms like Android and iOS are susceptible to rooting or jail breaking, which gives users unrestricted access to the underlying file system. Using this root level access, malicious users or malicious applications can easily retrieve the sensitive information stored on the device.
Weak Cryptography
Data security is another concern when in transit or stored. While choosing to store sensitive data on mobile devices, designers often employ encryption techniques. Few platforms like iOS do provide API's to encrypt data; however, these platforms are yet to get a strong key management technique or protocol. Android too provides APIs for cryptographic primitives, but no built-in protocol for key management. Designers may find themselves having to make decisions about what to use to generate keys, how to use them, and where to store them. Often they end up selecting a strong encryption algorithm, but choose a poor key management protocols. When you have weak cryptography design and keys are stored on the device, shared between users, or hardcoded, they do not provide adequate protection to the data.
Moving Substantial Business Logic Client Side
Designers tend to move a substantial amount of business logic to mobile devices unaware of it implications. When developing rich client applications, users are given direct access to a particular service, while maintaining a simple and attractive user experience. Incorporating business logic such as password re-verification can often lead to unexpected security issues. Like web based attacks, a malicious attacker could use a simple HTTP proxy that captures requests and responses and alter the response from the server to bypass security controls built in by the application’s logic.
Relying on Client Side Data Validation
In current business scenarios, users need to access enterprise applications both from the web and the mobile devices. Attackers have been abusing the weakness of client-side data validation in web since long time now. Data validation weakness has crept into application development in the mobile application space. Hackers can easily bypass client side data validation by using a proxy between the mobile app and the server.
There’s the old joke about two hunters running from a lion, and the one runner says to the other: we can’t outrun the lion. And his buddy replied, “I don’t have to outrun the lion, I only have to outrun you.” Many, over the years, have applied the same logic to application security: If their software is ‘secure enough’ attackers will move on to easier targets. Mobile application security is an easy target for attackers currently and you need to address security on priority.
Thursday, March 17, 2011
Simple Autocomplete
IRCTC - India's Rail Ticket Booking Website which is sought to be a secure platform for the citizens booking their tickets has few simple security configurations missing.
An example is the auto-complete not set to off on their payments page - a practice which most of the secure web applications follow for sensitive pages right from login page. Below is a snapshot.
An example is the auto-complete not set to off on their payments page - a practice which most of the secure web applications follow for sensitive pages right from login page. Below is a snapshot.
Tuesday, March 15, 2011
Past few months
Readers,
For the past few months or rather lemme say a year, I haven't been actively writing out here. I have been spending my time on other security aspects of my life. I secured myself from being a bachelor (got married :D), secured my Post Graduation (completed my Executive Management from IITB) and secured my job too. :)
Interestingly am back into security work doing a product development in space of data privacy. There have been many trends that I have been watching and techniques which I have learnt. Will be sharing via blog posts often now.
For the past few months or rather lemme say a year, I haven't been actively writing out here. I have been spending my time on other security aspects of my life. I secured myself from being a bachelor (got married :D), secured my Post Graduation (completed my Executive Management from IITB) and secured my job too. :)
Interestingly am back into security work doing a product development in space of data privacy. There have been many trends that I have been watching and techniques which I have learnt. Will be sharing via blog posts often now.
Monday, November 01, 2010
OTP adoption from India to the US?
One Time Password (OTP) is a password that is valid for only one login session. It is a popular authentication mechanism in India. It is essentially in use with Banking and Stock Broking Apps to do a two-factor authentication. SMSes on your registered mobile phone is been predominantly used as a medium to accomplish this second factor of authentication.
Recently, Facebook announced to users that they now have the option of texting "otp" to 32665 from any U.S. mobile phone to receive an OTP via SMS that is good for 20 minutes of log-in time to their Facebook account.
Nice to see Facebook working on the security front for once rather than endless feature updates. It has had its fair share of security woes so it’s nice to see they are doing something which I think may be genuinely useful for it’s burgeoning user base.
In India, a lot of banks use a similar way called Transaction Authorization Code. A OTP when you want to carry out a transaction which involves moving money out from your account (bill payment, fund transfers etc).
This method can provide security but it will not eliminate hackers from getting access to Facebook account. Using non secured network without encryption and other security measures will get the situation back to square one.
It would be also nice if you had security like GMail account security feature, which provides the information if there is a connection opened on my account from another location and monitor all latest ip’s logged into the session.
Recently, Facebook announced to users that they now have the option of texting "otp" to 32665 from any U.S. mobile phone to receive an OTP via SMS that is good for 20 minutes of log-in time to their Facebook account.
Nice to see Facebook working on the security front for once rather than endless feature updates. It has had its fair share of security woes so it’s nice to see they are doing something which I think may be genuinely useful for it’s burgeoning user base.
In India, a lot of banks use a similar way called Transaction Authorization Code. A OTP when you want to carry out a transaction which involves moving money out from your account (bill payment, fund transfers etc).
This method can provide security but it will not eliminate hackers from getting access to Facebook account. Using non secured network without encryption and other security measures will get the situation back to square one.
It would be also nice if you had security like GMail account security feature, which provides the information if there is a connection opened on my account from another location and monitor all latest ip’s logged into the session.
Labels:
facebook,
one time password,
Social Networking
Monday, June 28, 2010
Getting Hands Dirty with Ettercap Tool
Ettercap is a suite for man in the middle attacks on LAN. It features sniffing of live connections, content filtering on the fly and many other interesting tricks. It supports active and passive dissection of many protocols (even ciphered ones) and includes many feature for network and host analysis.
Over last few weeks, I have been fiddling around with this tool to test one of the applications. I found the tool has some real good capabilities. Sniffing over a switched network is not easy. However, using Ettercap, I managed it quite nicely.
In an Ethernet network computers communicate with each other via Ethernet MAC addresses. So, there is a mechanism needed for matching of IP addresses with the addresses in an ethernet network. The mechanism is called ARP (Address Resolution Protocol).
What ARP does is exactly what most people do, when they have to find Mr. X in a crowd of people - they shout loud enough, so that everyone can hear them and expect Mr. X to answer, if he is there. When he answers, we will know who is he. When ARP wants to know whats the Ethernet address matching a given IP address it uses an Ethernet technic, called BROADCASTING, with which the datagram is addressed to all the workstations in the network. The broadcast-datagram sent by ARP contains a request for the IP address. Every computer, received that request compares the requested address with its own IP address and if they match, it sends an ARP reply back to the asking computer. After rreceiving the reply, the asking computer can get the Ethernet address of the computer it is looking for, from his reply. After the computer finds an Ethernet address, he stores it in its ARP cache (ARP table), so he won't need to look for it the next time he wants to send a datagram to the same address. However, it is not good this information to be stored forever (the Ethernet adapter of the other host may be replaced for some reasonm and the entry for the computer's IP in the ARP cache will become invalid). So the entries in the ARP cache expire after a period of time. Most operating systems will replace an entry in their ARP cache even if they haven't sent and ARP request before. That allows a MITM (Man-In-The-Middle) attack to be performed.
Over last few weeks, I have been fiddling around with this tool to test one of the applications. I found the tool has some real good capabilities. Sniffing over a switched network is not easy. However, using Ettercap, I managed it quite nicely.
In an Ethernet network computers communicate with each other via Ethernet MAC addresses. So, there is a mechanism needed for matching of IP addresses with the addresses in an ethernet network. The mechanism is called ARP (Address Resolution Protocol).
What ARP does is exactly what most people do, when they have to find Mr. X in a crowd of people - they shout loud enough, so that everyone can hear them and expect Mr. X to answer, if he is there. When he answers, we will know who is he. When ARP wants to know whats the Ethernet address matching a given IP address it uses an Ethernet technic, called BROADCASTING, with which the datagram is addressed to all the workstations in the network. The broadcast-datagram sent by ARP contains a request for the IP address. Every computer, received that request compares the requested address with its own IP address and if they match, it sends an ARP reply back to the asking computer. After rreceiving the reply, the asking computer can get the Ethernet address of the computer it is looking for, from his reply. After the computer finds an Ethernet address, he stores it in its ARP cache (ARP table), so he won't need to look for it the next time he wants to send a datagram to the same address. However, it is not good this information to be stored forever (the Ethernet adapter of the other host may be replaced for some reasonm and the entry for the computer's IP in the ARP cache will become invalid). So the entries in the ARP cache expire after a period of time. Most operating systems will replace an entry in their ARP cache even if they haven't sent and ARP request before. That allows a MITM (Man-In-The-Middle) attack to be performed.
Subscribe to:
Posts (Atom)