Join the God Side, Jesus is Coming…….

Archive for April, 2011

IE9 versus Chrome: which one blocks malware better?

Source: zdnet

Social engineering has become the dominant method of distribution for fake antivirus software. And most modern browsers, with one exception, do a terrible job of dealing with this type of threat. Current builds of Chrome display a terrible flaw that puts you at greater risk than its competitors. In my testing, a malware author was able to exploit Chrome in four easy clicks. In stark contrast, Internet Explorer 9 used some new technology to flag the exact same sites and files as suspicious, providing unmistakable warnings that have been shown to stop 95% of these attacks in their tracks.

I’ve captured the experience for both browsers in these two videos and in an accompanying screenshot gallery so you can see for yourself. And if you make it to page 3, you’ll read about the new reputation-based technology that’s given IE9 the lead.

Interesting post read more…

Advertisements

Google Chrome To Protect Users Against Malicious Executables

Source: darknet

It looks like Google Chrome is stepping up to provide users with the most secure browsing experience. The browser has been built with security in mind since the beginning with it’s sandbox model and it escaped exploitation during the recent Pwn2Own contest.

Now they are infringing on the area of anti-virus vendors and stepping up in the fight againstmalware by proposing to block applications that are harmful to Windows users.

All we need to do now is make sure all new computers ship out with Chrome or Firefoxinstalled as the default browser.

Google says it’s expanding its blacklist of malicious websites to include those that use deceptive claims to push harmful Windows programs.

The addition to Google’s Safe Browsing API will warn people when they are about to visit websites that offer Windows-based trojans that are disguised as screen savers or other innocuous applications. The search behemoth introduced the service five years ago to alert users when they try to browse sites that perform drive-by downloads that exploit security vulnerabilities in the operating system or browsing software.

The underlying programming interface is already being used by browsers including Google Chrome, Mozilla Firefox, and Apple Safari. It’s also available to any webmaster who wants to use the wealth of information available from Google to prevent malicious links from being posted to their sites.

 

Two New Social Media Security White Papers Released

Source: spylogic

My employer (SecureState) has released two white papers as part of our Social Media Security Awareness Month.  You can also download some cool wallpaper for this month created by Rob our graphic designer (see the picture on the right).  🙂

First is some research several of my colleagues and I worked on.  The paper is titled:“Profiling User Passwords on Social Networks”.  The paper discusses the password problem that we all know and love as well as how you can determine passwords by what individuals post on their profiles.  We dive into tools from Robin Wood, Mark Baggett and others that can be used to pull keywords from profiles and other sources to create wordlists.  These wordlists can be used for brute force attacks on user accounts.  Next, we look at password complexity of several popular social networks with some research around brute force controls that some of the social networks have implemented, or in some cases haven’t.  Lastly, we discuss some things that users of social networks can do when choosing passwords.  You can download my paper here.

The other paper released is titled: “Security Gaps in Social Media Websites for Children Open Door to Attackers Aiming To Prey On Children” by my colleague Scott White.  In his paper he looks at the security of social media websites specifically designed for children.  This is some very detailed research and sheds some light on how predators are using these sites to target children as well as some issues that are unique to these types of social media websites.  You can download Scott’s paper here.

SSL and the Future of Authenticity

Source: it.slashdot

“There has been a growing tide of support for replacing SSL’s Certificate Authorities with an alternative authentication mechanism. Moxie Marlinspike, the security researcher who has repeatedly published attacks against SSL, has written an in-depth piece about the questions we should be asking as we move forward, and urges strong caution about adopting DNSSEC for this task.”

Oops. Info of 3.5 million Texans was publicly accessible

Source: blogs.chron

Personal information of about 3.5 million Texans — including names, mailing addresses and Social Security numbers — was posted on a publicly accessible server at the state comptroller’s office, much of it for more than a year, Comptroller Susan Combs said.

The information was in data transferred by the Teacher Retirement System of Texas, Texas Workforce Commission and Employees Retirement System of Texas.

The information was meant to be used internally at the comptroller’s office as part of the unclaimed property verification system.

Combs’ office said it contacted the state attorney general’s office and is working with that office on an investigation into the data exposure.

Combs’ office said there is no indication the personal information was misused.

 

Dropbox authentication: insecure by design

Source: dereknewton

For the past several days I have been focused on understanding the inner workings of several of the popular file synchronization tools with the purpose of finding useful forensics-related artifacts that may be left on a system as a result of using these tools.  Given the prevalence of Dropbox, I decided that it would be one of the first synchronization tools that I would analyze, and while working to better understand it I came across some interesting security related findings.  The basis for this finding has actually been briefly discussed in a number of forum posts in Dropbox’s official forum (here and here), but it doesn’t quite seem that people understand the significance of the way Dropbox is handling authentication.  So, I’m taking a brief break in my forensics-artifacts research, to try to shed some light about what appears to be going on from an authentication standpoint and the significant security implications that the present implementation of Dropbox brings to the table.

To fully understand the security implications, you need to understand how Dropbox works (for those of you that aren’t familiar with what Dropbox is – a brief feature primer can be found on their official website).  Dropbox’s primary feature is the ability to sync files across systems and devices that you own, automatically.  In order to support this syncing process, a client (the Dropbox client) is installed on a system that you wish to participate in this synchronization.  At the end of the installation process the user is prompted to enter their Dropbox credentials (or create a new account) and then the Dropbox folder on your local system syncs up with the Dropbox “cloud.”  The client runs constantly looking for new changes locally in your designated Dropbox folder and/or in the cloud and syncs as required; there are versions that support a number of operating systems (Windows, Mac, and Linux) as well as a number of portable devices (iOS, Android, etc).  However, given my research is focusing on the use of Dropbox on a Windows system, the information I’ll be providing is Windows specific (but should be applicable on any platform).

Under Windows, Dropbox stores configuration data, file/directory listings, hashes, etc in a number of SQLite database files located in %APPDATA%\Dropbox.  We’re going to focus on the primary database relating to the client configuration: config.db.  Opening config.db with your favorite SQLite DB tool will show you that there is only one table contained in the database (config) with a number of rows, which the Dropbox client references to get its settings.  I’m going to focus on the following rows of interest:

  • email: this is the account holder’s email address.  Surprisingly, this does not appear to be used as part of the authentication process and can be changed to any value (formatted like an email address) without any ill-effects.
  • dropbox_path: defines where the root of Dropbox’s synchronized folder is on the system that the client is running on.
  • host_id: assigned to the system after initial authentication is performed, post-install.  Does not appear to change over time.

After some testing (modification of data within the config table, etc) it became clear that the Dropbox client uses only the host_id to authenticate.  Here’s the problem: the config.db file is completely portable and is *not* tied to the system in any way.

Of course, if an attacker has access to the config.db file (assuming that it wasn’t sent by the user as part of social engineering attack), the assumption is that the attacker most likely also has access to all of the files stored in your Dropbox, so what’s the big deal?  Well, there are a few significant security implications that come to mind:

  • Relatively simple targeted malware could be designed with the specific purpose of exfiltrating the Dropbox config.db files to “interested” parties who then could use the host_id to retrieve files, infect files, etc.
  • If the attacker/malware is detected in the system post-compromise, normal remediation steps (malware removal, system re-image, credential rotation, etc) will not prevent continued access to the user’s Dropbox.  The user would have to remember to purposefully remove the system from the list of authorized devices on the Dropbox website.  This means that access could be maintained without continued access/compromise of a system.
  • Transmitting the host_id/config.db file  is most likely much smaller than exfiltrating all data found within a Dropbox folder and thus most likely not set off any detective alarms.  Review/theft/etc of the data contained within the Dropbox could be done at the attackers leisure from an external attacker-owned system.

So, given that Dropbox appears to utilize only the host_id for authentication by design, what can you do to protect yourself and/or your organization?

  1. Don’t use Dropbox and/or allow your users to use Dropbox.  This is the obvious remediating step, but is not always practical – I do think that Dropbox can be useful, if you take steps to protect your data…
  2. Protect your data: use strong encryption to protect sensitive data stored in your Dropbox and protect your passphrase (do not store your passphrase in your Dropbox or on the same system/device).
  3. Be diligent about removing old systems from your list of authorized systems within Dropbox.  Also, monitor the “Last Activity” time listed on the My Computers list within Dropbox.  If you see a system checking in that shouldn’t be, unlink it immediately.

Hopefully, Dropbox will recognize the need for additional security and add in protection mechanisms that will make it less trivial to gain long-term unauthorized access to a user’s Dropbox as well as provide better means to mitigate and detect an exposure.

5 of the Best Free Linux Disk Encryption Tools

Source: linuxlinks

The importance of security should never be underestimated. The consequences of losing data can be disastrous for any organisation. For example, the loss of a single unencrypted laptop may have huge repercussions. This could include breaching data protection legislation with the risk of a significant fine, a loss in the confidence of an organisation, as well as the risk that sensitive data may fall into the hands of a competitor or third party with malicious intent.

Disk encryption is one method to help minimise the risks by preventing unauthorised access to data storage, to ensure safe information exchanges, safeguard against data leakage, and manage compliance. This form of security is useful for any computer that holds personal information, not only laptops. Disk encryption uses disk encryption software to encrypt the entire hard disk. The onus is therefore not on the user to determine what data should be encrypted, or to remember to manually encrypt files. By encrypting the entire disk, temporary files, which may reveal important confidential data, are also protected. Security is enhanced further when disk encryption is combined with filesystem-level encryption.

So, let’s explore the 5 disk encryption tools at hand. For each application we have compiled its own portal page, a full description with an in-depth analysis of its features, screenshots, together with links to relevant resources and reviews.

loop-AES Encrypt disk partitions, removable media, swap space and other devices
dm-crypt Transparent disk encryption subsystem
cryptsetup Configures encrypted block devices
SD4L Hides complete file systems within encrypted regular files
TrueCrypt Used for on-the-fly encryption  ( Platform: Linux and Windows )

 

Tag Cloud