Posted in Security Training & Awareness
Amit Sethi is a principal consultant at Synopsys. He specializes in mobile security, online game security, and cryptography. Amit’s work includes extracting cryptographic keys from embedded devices using side-channel attacks, designing mechanisms to make those attacks more difficult, and designing a format-preserving encryption algorithm based on well-studied cryptographic primitives for a Fortune 500 company. Even in his free time, Amit enjoys reverse engineering binaries, analyzing open source software, and experimenting with new technologies.
Posted in Security Training & Awareness
Google started releasing monthly security updates for Android back in August 2015. Modern Android devices show you the latest monthly patch level that has been applied. The responsibility for deploying the patches ultimately falls on original equipment manufacturers (OEMs) and carriers, who need to test the security updates on their devices to ensure that they do not break any functionality. Google does provide updates for its Nexus and Pixel devices directly to end users, but given how Android is designed, Google cannot simply push out arbitrary security updates to all Android devices. Do OEMs have to push out updates? The problem is that OEMs and carriers are responsible not only for pushing out the updates but also for displaying the latest month for which Google’s monthly updates have been applied to a device. There may be legitimate reasons why an OEM or carrier may choose not to push out a security update for a particular type of device. For example:
Posted in Mobile App Security
More vulnerabilities were publicly disclosed in 2017 than ever before. What do the biggest data breaches from 2017 say about the future of cyber security?
Posted in Data Breach Security
In recent days, more details concerning the Equifax breach have come to light. There’s now speculation that attackers exploited a vulnerability in Apache Struts to steal data. There has also been plenty of speculation regarding the exact vulnerability that may have been exploited. The Apache Struts theory The Apache Struts Program Management Committee released a statement regarding the hack. It reaffirms the uncertainty as to the specific vulnerability. At this point, we don’t have any official confirmation whether the exploited vulnerability was in Apache Struts.
On Sept. 7, Equifax announced that attackers had stolen information from about 143 million people in the United States. Canadian and U.K. residents’ data was also stolen. However, Equifax has not yet revealed the number of people affected. We do not know the exact vulnerability that was exploited. Equifax stated only that “criminals exploited a U.S. website application vulnerability to gain access to certain files.” Whenever these types of events happen, it’s natural to ask questions such as what the vulnerability was, how this could have been prevented, and what lessons can be learned. Let’s try to answer some of these questions. The vulnerability We don’t have much information about the exact vulnerability that was exploited. However, based on Equifax’s statement, it was probably a directory traversal vulnerability, a command injection vulnerability, or an insecure direct object reference vulnerability. All these are well-known web application vulnerabilities that can be used to get unauthorized access to files. Could this have been prevented? These types of events are generally the result of organizations not following secure software development practices. There are many layers in which problems can often be prevented but aren’t:
The DES encryption algorithm was designed in the early 1970s by researchers at IBM. It was adopted as a FIPS standard in 1977. The algorithm uses 56-bit keys, which were long enough to be secure at the time. However, as it became feasible to brute-force 56-bit keys, 3DES was adopted as a standard in the 1990s. 3DES involves performing three DES operations to encrypt/decrypt each 64-bit block of data using either two or three distinct 56-bit keys. The result is an encryption algorithm with an effective key strength of 112 bits, which is still considered secure against brute-force attacks today.
Posted in Application Security
Java SecureRandom updates as of April 2016 There have been several changes to Java’s SecureRandom API since creating this post back in 2009. According to Oracle, the following interesting changes have been made: