Nabeel's Blog
Information technology and what not!
Wednesday, December 14, 2016
Wednesday, February 3, 2016
My Take on Information and Cyber Security Defense
Information and Cyber security have never been more critical than today as computer and control systems are increasingly connected to the Internet and they have become targets of enemies and attackers from inside and outside of organizations. Therefore we need to continuously find better approaches to protect our systems against increasingly sophisticated attacks. Specifically, attempts to compromise the confidentiality, integrity and/or availability of systems are on the rise. The first line of defense is to have preventive measures such as strong authentication, access control, and encryption. However, it has been proven time and time again that preventive measures alone are not sufficient to protect ever sophisticated and interconnected systems we currently have. As we all know, it is an elusive goal to build exploit free systems due to, but not limited to, design and implementation errors, configuration errors, vulnerabilities in the third-party systems and libraries, and social engineering attacks. For example, buffer overflow vulnerability has been known for many decades, but we are still hearing damaging attacks exploiting this vulnerability in current systems. Given the disadvantaged situation we are in, what can we do to protect our systems? In my humble opinion, there is no single silver bullet solution that solves the issue. Instead we should take a holistic approach where multiple lines of defense are utilized along with attack detection and mitigation techniques.
Friday, February 27, 2015
Is your data more (or less) secure in the cloud?
The basic concept behind public cloud computing is to consolidate traditional behind the firewall services, data, and applications into an elastic on-demand multi-tenant third-party hosted environment. So, is your data more secure in the cloud compared to in the enterprise? One could argue both ways.
Less secure:
- cloud is more attractive and a lucrative target for hackers - higher RoI - if hacked, they get access to consolidated data of all customers.
- virtualization/multi-tenancy creates more attack surface compared to traditional computing model
- you loose control of your data
More secure:
- cloud may protect your data with the very latest security technologies by an expert security team while enterprises may not have that luxury.
- security patches/updates may be updated timely and in a consistent manner across all resources (better security management).
- easier to protected centralized consolidated resources than distributed resources.
- have the ability to correlate audit information from multiple customers to provide better detection and mitigation of attacks.
Less secure:
- cloud is more attractive and a lucrative target for hackers - higher RoI - if hacked, they get access to consolidated data of all customers.
- virtualization/multi-tenancy creates more attack surface compared to traditional computing model
- you loose control of your data
More secure:
- cloud may protect your data with the very latest security technologies by an expert security team while enterprises may not have that luxury.
- security patches/updates may be updated timely and in a consistent manner across all resources (better security management).
- easier to protected centralized consolidated resources than distributed resources.
- have the ability to correlate audit information from multiple customers to provide better detection and mitigation of attacks.
Labels:
cloud computing,
cloud security,
security,
thoughts
Monday, January 5, 2015
[Research] Privacy Preserving Data Services in the Cloud
When you utilize a data service in the cloud to store your business data, among other concerns, there are security and privacy implications. Two key concerns are data confidentiality and access privacy. In this post, I am briefly discussing these two concerns and highlight the related research work.
Data confidentiality - prevent the cloud from seeing the plaintext data.
Access Privacy - prevent the cloud from inferring information about data from the queries made.
Data confidentiality research:
Access Privacy research:
Data confidentiality - prevent the cloud from seeing the plaintext data.
Access Privacy - prevent the cloud from inferring information about data from the queries made.
Data confidentiality research:
- The challenge is to allow query processing while keeping the data and query oblivious
- Researchers have mainly taken two approaches
- Encrypted database and encrypted query processing
- Trusted computing - keep the sensitive content in a trusted container
- Projects: TrustedDB, CipherBase
Access Privacy research:
- The challenge is to support minimal leakage of query access pattern while keeping the computational cost to reasonably low so that the approach is practical.
- There are two main paths that researchers have taken to solve this problem:
Friday, January 2, 2015
[Basics] Two-factor authentication
It's also called token based authentication. It sounds like something new, but we have been using it for ages. Virtually all ATMs use two-factor authentication for debit cards.
What is two-factor authentication?
Before I explain, what two-factor authentication is, let me list the three possible way to authenticate a person or a thing based on the following criteria:
- what you know (e.g. password, pin)
- what you have (e.g. debit card, mobile phone, USB stick token)
- what you are (e.g. fingerprint, iris, face)
Most systems reply only on one of the above three factors to authenticate a user. For example, a bank website asks you only for your username and password (what you know) to login to their site. The idea behind two-factor authentication is simple; use two of the above factors to authenticate a user.
Examples of two-factor authentication
As mentioned above, debit cards on ATMs use two factor authentication:
- Debit card (what you have)
- 4 digit PIN (what you know)
Google supports mobile based two factor authentication. You use your regular username and password (what you know) along with the code sent to your mobile phone (what you have).
- mobile phone (what you have)
- username and password (what you know)
RSA SecurID supports two factor authentication.
- token generated either from a hardware device (USB dongle) or a software app. (what you have)
- any of the other two factors listed above
Most common form of two factor authentication is to use a token and a username/password. So, it is important to safeguard tokens to have a secure two factor authentication system. Tokens are basically OTPs.
Where can an attacker exploit in a token based authentication flow?
- token infrastructure
- token vendor
- token itself
- client using the token (mostly attackers exploit this as clients are usally the weakest link the whole flow)
Example attacks on token based authentication systems
- Attack on RSA SecurID (attacking token vendor)
- Differential power analysis attacks to recover tokens/keys (attacking token itself) - recovering DES/AES keys, recovering smartcard keys
- malwares to steal tokens from clients (attacking clients) - Zeus trojan in 2007-2009
There are security measures that you can take in order to defend against above types of attacks.
What is two-factor authentication?
Before I explain, what two-factor authentication is, let me list the three possible way to authenticate a person or a thing based on the following criteria:
- what you know (e.g. password, pin)
- what you have (e.g. debit card, mobile phone, USB stick token)
- what you are (e.g. fingerprint, iris, face)
Most systems reply only on one of the above three factors to authenticate a user. For example, a bank website asks you only for your username and password (what you know) to login to their site. The idea behind two-factor authentication is simple; use two of the above factors to authenticate a user.
Examples of two-factor authentication
As mentioned above, debit cards on ATMs use two factor authentication:
- Debit card (what you have)
- 4 digit PIN (what you know)
Google supports mobile based two factor authentication. You use your regular username and password (what you know) along with the code sent to your mobile phone (what you have).
- mobile phone (what you have)
- username and password (what you know)
RSA SecurID supports two factor authentication.
- token generated either from a hardware device (USB dongle) or a software app. (what you have)
- any of the other two factors listed above
Most common form of two factor authentication is to use a token and a username/password. So, it is important to safeguard tokens to have a secure two factor authentication system. Tokens are basically OTPs.
Where can an attacker exploit in a token based authentication flow?
- token infrastructure
- token vendor
- token itself
- client using the token (mostly attackers exploit this as clients are usally the weakest link the whole flow)
Example attacks on token based authentication systems
- Attack on RSA SecurID (attacking token vendor)
- Differential power analysis attacks to recover tokens/keys (attacking token itself) - recovering DES/AES keys, recovering smartcard keys
- malwares to steal tokens from clients (attacking clients) - Zeus trojan in 2007-2009
There are security measures that you can take in order to defend against above types of attacks.
Tuesday, December 30, 2014
[Basics] Software flaw vs. bug
Have you ever thought about the difference between a software flaw and bug? Or are they referring to the same thing? This mini post will explain.
It is true that both software flaws and bugs result in vulnerabilities that hackers can exploit, but these two terms refer to two different things. The former is more serious than the latter.
Software flaw - caused by a design failure
Software bug - cause by a implementation failure (design is perfectly fine)
Note that software can be vulnerable due to both software flaw and bug at the same time - incorrect design and incorrect implementation.
Let me quote a famous bug which was exploited to produce one of the first Internet worm, Morris worm, in 1988. Morris worm exploited a buffer overflow vulnerability in Unix finger daemon. Specifically, finger used get() function to obtain user input. The problem with get() is that it does not have provision to limit or check user input string length. So, the bug is not checking/validating input string. It is not a flaw as it is an implementation issue and has nothing to do with the design of finger.
Another recent one is heartbleed bug. It is a serious software bug in OpenSSL library. Exploiting this vulnerability, attackers can eavesdrop on OpenSSL encrypted communication, steal data from server and clients, and also impersonate either of the entity. It is caused by an implementation failure of the heartbeat part of OpenSSL library and it has nothing to do with the design of TLS.
Now let's look at a recent design flaw vulnerability. iOS 6 had a vulnerability in mobile hotspot passwords. A hacker can do a simple dictionary/brute-force attack to recover this password. This vulnerability is not an implementation issue, but rather resulted from the design flaw in how passwords are generated. This password is generated from a set of predefined words. These words are randomly selected and padded with a 4 digit random number. The flaw here is that selection of words from the pool of words is not truly random and also the number of words in the pool is also small.
Good read: Avoiding the top 10 software security design flaws
Bottom line is that use secure design principles and coding techniques to avoid such vulnerabilities.
It is true that both software flaws and bugs result in vulnerabilities that hackers can exploit, but these two terms refer to two different things. The former is more serious than the latter.
Software flaw - caused by a design failure
Software bug - cause by a implementation failure (design is perfectly fine)
Note that software can be vulnerable due to both software flaw and bug at the same time - incorrect design and incorrect implementation.
Let me quote a famous bug which was exploited to produce one of the first Internet worm, Morris worm, in 1988. Morris worm exploited a buffer overflow vulnerability in Unix finger daemon. Specifically, finger used get() function to obtain user input. The problem with get() is that it does not have provision to limit or check user input string length. So, the bug is not checking/validating input string. It is not a flaw as it is an implementation issue and has nothing to do with the design of finger.
Another recent one is heartbleed bug. It is a serious software bug in OpenSSL library. Exploiting this vulnerability, attackers can eavesdrop on OpenSSL encrypted communication, steal data from server and clients, and also impersonate either of the entity. It is caused by an implementation failure of the heartbeat part of OpenSSL library and it has nothing to do with the design of TLS.
Now let's look at a recent design flaw vulnerability. iOS 6 had a vulnerability in mobile hotspot passwords. A hacker can do a simple dictionary/brute-force attack to recover this password. This vulnerability is not an implementation issue, but rather resulted from the design flaw in how passwords are generated. This password is generated from a set of predefined words. These words are randomly selected and padded with a 4 digit random number. The flaw here is that selection of words from the pool of words is not truly random and also the number of words in the pool is also small.
Good read: Avoiding the top 10 software security design flaws
Bottom line is that use secure design principles and coding techniques to avoid such vulnerabilities.
Top data breaches of 2014 and lessons
May - eBay [1, 2]
September - Home Depot [1]
December - Sony Pictures [1]
- 145 million
- The problem has been exploited at least from February
- Information compromised - encrypted passwords, usernames, emails, DoBs, phone numbers, postal addresses
- How - eBay allows sellers to use active content such as Javscript and Flash. Hackers have embedded password harvesting scripts in listings and used XSS attack to gather information from logged in users
- Lessons - If you allow active content in your web site, you need to have preventive (such as limiting what is allowed) as well as risk mitigation techniques (detection, monitoring, etc.) in place. If not, it is better to block active content.
September - Home Depot [1]
- 56 million
- Information compromised - credit and debit card numbers
- How - resulted from the compromise of a third-party vendor
- Lessons - Organizations should evaluate the security measures taken by third-party vendors and also have intrusion detection in place.
- Attack discovered in July and disclosed in September
- 76 million households (83 million accounts)
- Information compromised - names, addresses, phone numbers and email addresses
- How - Hackers got access via a neglected server which is not upgraded to two factor authentication
- Potentially took 2 months to notice unusual activities after the initial attack
- Lessons - Security is only as strong as the weakest link in your system. Make sure you do not leave any unguarded holes in your network. Cannot emphasize more of the need for better and faster detection techniques in place.
- Number of people affected is still not known
- Attack initially detected in November
- Information compromised - unreleased movies, company emails, executive salaries, personal information, internal strategy information
- How - wiper malware (still it is not known how it got into the system). It is likely that lapses in internal security measures may resulted in this attack.
- Lessons - Never take security lightly. Internal security measures and auditing should always be a top priority.
Labels:
2014,
attack,
compromised,
data breach,
ebay,
hack,
home depot,
jpmorgan chase,
security,
sony pictures,
wiper,
xss
Subscribe to:
Posts (Atom)