Archive for June, 2012

In particular, Microsoft has focused on improving security to ensure users of Windows 8 tablets can securely connect to corporate networks. It is building antivirus (AV) and secure, role-based authentication into Windows 8 to make the operating system (OS) enterprise-ready.

During the Windows 8 preview day in Amsterdam, Bill Karagournis, group program manager at Microsoft, demonstrated the work Microsoft had done with the UEFI (unified extended firmware interface), a group comprising hardware companies and chip makers, to validate the operating system when it boots up.

On a PC, the BIOS that runs as soon as it is switched on, loads what is called a boot loader program, that then starts Windows. Crackers can intercept the boot loader to make it run rogue software before Windows starts, circumventing Windows security. To prevent this, the firmware validates that the OS boot loader is clean.

Advertisements

Now that Intel offers hardware-based AES acceleration in a number of its mainstream processors, it’s time to take a look at two of the most popular system encryption tools, BitLocker and TruCrypt, both of which are able to harness the hardware feature.

Microsoft has been shipping BitLocker drive encryption tool with Windows Vista and Windows 7 operating systems, but it’s only available on the two highest-end editions, Enterprise and Ultimate. Fortunately, there is a powerful alternative to BitLocker for everyone else. TrueCrypt is open source and offers even more flexibility. We decided to compare the features and performance of both solutions.

I compare the process of how to encrypt a Windows system partition, and ran benchmarks, in addition to battery runtime tests on a notebook. The conclusion was promising: TrueCrypt  lets you encrypt and password-protect your entire system on the fly with only minor performance and battery life penalties.

By now, there’s really no need to rehash the merits of encrypting user data, especially for the folks who handle sensitive information. Losing information to a failed drive is one thing, and it can typically be addressed, even if it’s an expensive proposition (then again, you already know you should be running regular backups, right?). But data falling into the wrong hands can be an even direr problem for businesses.

This time around, I wanted to double-check our findings with TrueCrypt against Microsoft’s value-added BitLocker. Does it make sense to pay up for a higher-end Windows version to get this extra functionality, or will TrueCrypt do the exact same thing at no cost? Another reason to revisit encryption solutions is the availability of AES new instructions (AES-NI) in Intel’s Core i5 mainstream dual-core processors and the top-end, six-core Core i7. Can BitLocker and TrueCrypt truly showcase the benefits of hardware-based AES acceleration? Let’s find out.

June 24, 2012 is when Stuxnet’s replication mechanism leveraging CVE-2010-2729 is programmed to be deactivated. This means that that Stuxnet will no longer spread to USB keys using that vulnerability.

This is a welcome relief in the fight against the spread of the worm, even two years after the initial outbreak.  Users need to be aware that Stuxnet has not always taken advantage of the Windows Print Spooler Service vulnerability. Prior to March 2010, Stuxnet used a trick in Autorun in order to spread and this technique may still be used.

Reference:
http://technet.microsoft.com/en-us/security/bulletin/MS10-061
http://www.symantec.com/connect/blogs/stuxnet-lnk-file-vulnerability
https://www.securelist.com/en/blog/208193609/The_Day_The_Stuxnet_Died

The vulnerability ‘MS08-067‘ is a flaw in the Windows Server Service that when a specially crafted RPC request was sent could allow remote code executions.This vulnerability affected Windows 2000, XP, Server 2003, Vista, and server 2008 and has been assigned CVE-2008-4250.

There is a free Python Script, which will automatically scan for SMB Port and Will also Exploit ‘MS08-067’ Flaw using Metasploit. Try this tool as a poc can see the damage it can do to your system. So now it’s time to apply the patches. 🙂

Simple Certificate Enrollment Protocol (SCEP) does not strongly authenticate certificate requests.

IETF Internet-Draft draft-nourse-scep-23 “…defines a protocol, Simple Certificate Enrollment Protocol (SCEP), for certificate management and certificate and CRL queries in a closed environment.” Mobile Device Management (MDM) isdefined as “…software that secures, monitors, manages and supports mobile devices deployed across mobile operators, service providers and enterprises. MDM functionality typically includes over-the-air distribution of applications, data and configuration settings for all types of mobile devices, including mobile phones, smartphones, tablet computers, ruggedized mobile computers, mobile printers, mobile POS devices, etc.” Multiple MDM software packages use SCEP as a method to handle certificate management and certificate CRL queries within an organization.

When an user or a device requests a certificate, the SCEP implementation may require a challenge password. It may be possible for a user or device to take their legitimately acquired SCEP challenge password and use it to obtain a certificate that represents a different user with a higher level of access such as a network administrator, or to obtain a different type of certificate than what was intended. It is also possible for SCEP implementations or system administrators to not require the challenge password, or to share a static password across many users.

Impact : An attacker could elevate their permissions by requesting a certificate of a different, possibly higher privileged user that would allow them to access resources that they would not otherwise be able to access.

Solution : US-CERT currently unaware of a practical solution to this problem.

Possible Workarounds:

Use Certificate Management Protocol (CMP) or Certificate Management over CMS as a replacement for Simple Certificate Enrollment Protocol (SCEP)
Manually approve for certificates from unknown sources
Avoid reusing challenge passwords
Limit the number of individuals who can request certificates

Source: http://www.kb.cert.org

Major corporations, government agencies, and small businesses all hand out RSA SecurID fob keychains to employees so that they can log in to their systems for security reasons and If you’re used to seeing a device like this on a daily basis, you probably assume that it’s a vital security measure to keep your employer’s networks and data secure. A team of computer scientists beg to differ, however, because they’ve cracked the encryption it uses wide open.

In a paper called “Efficient padding oracle attacks on cryptographic hardware,” researchers Romain Bardou, Lorenzo Simionato, Graham Steel, Joe-Kai Tsay, Riccardo Focardi and Yusuke Kawamoto detail the vulnerabilities that expose the imported keys from various cryptographic devices that rely on the PKCS#11 standard.

 
They managed to develop an approach that requires just 13 minutes to crack the device’s encryption. RSA Security, a division of the data storage company EMC, is one of the largest makers of the security fobs. A spokesman for the company, Kevin Kempskie, said that its own computer scientists were studying the paper to determine “if this research is valid.”
 
Commonly referred to as the ‘million message attack,’ it usually requires an average of 215,000 queries to reveal a 1024-bit key. The refined method suggested in the document improves the algorithm and only requires an average of 9,400 calls to reveal the same key. They accomplished this by using a theorem that allows not only multiplication but also division to be used in manipulating a PKCS# v1.5 ciphertext to learn about the plaintext. The paper says that “the attacks are efficient enough to be practical.”
 
Among the other vulnerable devices are SafeNet’s iKey 2032 and Aladdin eTokenPro, Siemens’ CardOS  and Gemalto’s CyberFlex (92 minutes). Also vulnerable is the Estonian electronic ID Card, which contains two RSA key pairs

A database is a fundamental component for most web applications. If you’re using PHP, you’re probably using MySQL–an integral part of the LAMP stack.

PHP is relatively easy and most new developers can write functional code within a few hours. However, building a solid, dependable database takes time and expertise. Here are ten of the worst MySQL mistakes I’ve made (some apply to any language/database)…

1. Using MyISAM rather than InnoDB

MySQL has a number of database engines, but you’re most likely to encounter MyISAM and InnoDB.

MyISAM is used by default. However, unless you’re creating a very simple or experimental database, it’s almost certainly the wrong choice! MyISAM doesn’t support foreign key constraints or transactions, which are essential for data integrity. In addition, the whole table is locked whenever a record is inserted or updated; this causes a detrimental effect on performance as usage grows.

The solution is simple: use InnoDB.

2. Using PHP’s mysql functions

PHP has provided MySQL library functions since day one (or near as makes no difference). Many applications rely on mysql_connect, mysql_query, mysql_fetch_assoc, etc.

mysqli, or the MySQL improved extension, has several advantages:

an (optional) object-oriented interface
prepared statements (which help prevent SQL-injection attacks and increase performance)
multiple statements and transaction support
Alternatively, you should consider PDO if you want to support multiple databases.

3. Not sanitizing user input

This should probably be #1: never trust user input. Validate every string using server-side PHP — don’t rely on JavaScript. The simplest SQL injection attacks depend on code such as:

  1. $username = $_POST[“name”];
  2. $password = $_POST[“password”];
  3. $sql = “SELECT userid FROM usertable WHERE username=’$username’ AND password=’$password’;”;
  4. // run query…

This can be cracked by entering “admin'; --” in the username field. The SQL string will equate to:

  1. SELECT userid FROM usertable WHERE username=’admin’;

The devious cracker can log in as “admin”; they need not know the password because it’s commented out of the SQL.

4. Not using UTF-8

Those of us in the US, UK, and Australia rarely consider languages other than English. We happily complete our masterpiece only to find it cannot be used elsewhere.

UTF-8 solves many internationalization issues. Although it won’t be properly supported in PHP until version 6.0, there’s little to prevent you setting MySQL character sets to UTF-8.

5. Favoring PHP over SQL

When you’re new to MySQL, it’s tempting to solve problems in the language you know. That can lead to unnecessary and slower code. For example, rather than using MySQL’s native AVG() function, you use a PHP loop to calculate an average by summing all values in a record-set.

Watch out also for SQL queries within PHP loops. Normally, it’s more effective to run a query then loop through the results.

In general, utilize the strengths of your database when analyzing data. A little SQL knowledge goes a long way.

6. Not optimizing your queries

99% of PHP performance problems will be caused by the database, and a single bad SQL query can play havoc with your web application. MySQL’s EXPLAIN statement, the Query Profiler, and many other tools can help you find that rogue SELECT.

7. Using the wrong data types

MySQL offers a range of numeric, string, and time data types. If you’re storing a date, use a DATE or DATETIME field. Using an INTEGER or STRING can make SQL queries more complicated, if not impossible.

It’s often tempting to invent your own data formats; for example, storing serialized PHP objects in string. Database management may be easier, but MySQL will become a dumb data store and it may lead to problems later.

8. Using * in SELECT queries

Never use * to return all columns in a table–it’s lazy. You should only extract the data you need. Even if you require every field, your tables will inevitably change.

9. Under- or over-indexing

As a general rule of thumb, indexes should be applied to any column named in the WHERE clause of a SELECT query.

For example, assume we have a usertable with a numeric ID (the primary key) and an email address. During log on, MySQL must locate the correct ID by searching for an email. With an index, MySQL can use a fast search algorithm to locate the email almost instantly. Without an index, MySQL must check every record in sequence until the address is found.

It’s tempting to add indexes to every column, however, they are regenerated during every table INSERT or UPDATE. That can hit performance; only add indexes when necessary.

10. Forgetting to back up

It may be rare, but databases fail. Hard disks can stop. Servers can explode. Web hosts can go bankrupt. Losing your MySQL data is catastrophic, so ensure you have automated backups or replication in place.

 

11. Bonus mistake: not considering other databases!

MySQL may be the most widely used database for PHP developers, but it’s not the only option. PostgreSQL and Firebird are its closest competitors; both are open source and not controlled by a corporation. Microsoft provide SQL Server Express and Oracle supply 10g Express; both are free versions of the bigger enterprise editions. Even SQLite may be a viable alternative for smaller or embedded applications.