Data loss incident news and data protection advice.

Sophos Disk Encryption for Mac & FileVault 2 Comparison

October 18, 2011 2 comments

If you have read my previous review of Apple’s FileVault 2, thank you.

This article is an updated version of my Lion FileVault 2 review to include a comparison of Sophos Disk Encryption for Macs. Enjoy.

History has shown that some things Apple does, Microsoft does later. I don’t want to distract you with the details so when you are done reading this blog posting, fire up your favorite search engine and hunt on ‘Microsoft copies Apple’. Enjoy!

This doesn’t hold true when it comes to Full Disk Encryption (FDE). BitLocker made it’s debut with Vista in January of 2007. A mere 4 and a half years later we have FileVault 2 (FV2) with FDE support for the Apple Mac OS X. Yipee!

Being the data protection junkie I am, as soon as possible, I upgraded to OS X 10.7 Lion to encrypt my MacBook Pro.

Sophos is also able to encrypted Mac computers at the sector level. As a comparitive, I also encrypted the same MacBook Pro using Sophos Disk Encryption (SDE) for Mac version 5.55 on OS X Lion.

This way, from a hardware perspective, everything is equal.

The objective was to give FV2 a test drive, see how it feels as well as share my data findings and opinion when compared to SDE for Mac version 5.55.

Keeping with the Apple theme, I’ve rated my observations with either CRISPY or ROTTEN based on my opinion of the finding. Personally, my favorite apple is a cool crisp Senshu in mid-September. Yum!

The Hardware

MacBook Pro 13-inch
Released: Early 2011
1 Processor: 2.7 GHz Intel Core i7
Total number of cores: 2
Memory: 4 GB 1333 MHz DDR3 both slots used
Storage: 500 GB SATA drive ST9500325ASG 5400 rpm
Format: Mac OS Extended (Journaled)

The Act of Encryption

FV2: Apple has a very useful article (HT4790) on how to get your FileVault 2 FDE on. My advice is to read through the article first before giving it a try to ensure there are no surprises on your system.

I found the article easy to follow and salacious enough to satisfy my technical curiosities. A great example is the first sentence of the article which states that FileVault 2 is using XTS-AES 128-bit encryption.

If you’re a crypto junkie or learning to be one, you can get your fix with this great Wikipedia page on Disk encryption theory where you will learn about cipher block chaining (CBC) and Xor-Encrypt-Xor (XEX).

If acronyms such as XTS and AES make your eyes glaze over, then keep reading because article HT4790 softens up the crypto-speak to be helpful enough for home users or IT pros without a cryptography background.

SDE: Sophos provides the standard Apple Disk Image (.dmg) file which contains a Readme.html and a package (.pkg) file.

The pkg file can be used for a manual installation or can be distributed for large scale deployments using tools such as JAMF’s Casper.

For enterprises, there are several command line (CLI) options available for the deployment. Not in scope of this article. Point being, you can really customize the heck out of your install.

Comparative: I searched for a way to deploy FV2 and SDE in enterprises and came up with JAMF can be used for both, but SDE offers many more options using the CLI.

Options such as adding users to the pre-boot, generating recovery keys and controlling encryption state. CRISPY for SDE.

With my 500 GB SATA drive and minimal usage during initial encryption it took roughly 7 hours at a rate of 1.19 GB/minute. This was nice and CRISPY for FV2. Keep in mind that’s 128 bit crypto.

Under the same usage conditions, SDE took 12 hours and 26 minutes at a rate of 0.67 GB/minute. While SDE’s initial encryption time is longer, the ability to pause and resume the act of encryption as often as you like makes up for it.

As you can see, with twice the key strength the initial encryption times will take longer, but with twice the protection.

Estimating time remaining

FileVault estimating the amount of time to complete encryption

I performed a couple additional tests in the area of the encryption resiliency.

About 5 minutes after the initial encryption process began I restarted the MacBook Pro. I did the same thing during the decryption process for both technologies.

I was very happy to see my MacBook Pro come back to life and not turn into a half-encrypted Franken-brick. CRISPY to both FV2 and SDE.

Another cool feature I find with very few encryption products is the ability to manually or script a pause, resume and/or revert the initial encryption process.

FV2: I was happy to see that after enabling FV2, I was also able to revert/disable FV2 in mid-encryption, but only once.

SDE: SDE has the same ability to begin encryption and while partially through, then decrypt. Where SDE comes ahead is you can stop decryption before completion and even go back and forth again as often as you like.

That’s awesome!

While I still don’t have a use case to turn it on and off multiple times, it goes to show that there was a lot of thought in SDE’s design.

Comparative: In the event when someone decides to jump into the FDE pool and forgot to backup with Time Machine beforehand having an exit strategy is a relief.

It’s always good to backup before you encrypt your drive, you can never be to cautious.

I give them both a CRISPY for being able to back out of initial encryption, but SDE gets a double-byte CRUNCH for adding the extra features to pause and resume.


Performance is generally a top priority for the majority of Mac users. When your time is spent manipulating images, recording/editing audio, compiling iOS apps and/or rendering video, speed and available resources counts.

That’s generally why you got a Mac to begin with.


Updated: After having completed this article I’ve decrypted my drive because the performance hit was too great to bare. I found whenever launching and using GIMP and even when using Finder, I got the rainbow wheel of patience.

A big thanks to AnandTech who put in a great effort to analyze performance with FileVault 2 enabled on an SSD (Solid State Drive). After analyzing various I/O intensive operations, including but not limited to, random read/writes and sequential read/writes at varying file access sizes, they wrote, “Overall the hit on pure I/O performance is in the 20 – 30% range.” ROTTEN

This level of analysis is still pending with SDE. If AnandTech desires to execute the same performance analysis on SDE, please contact me directly for assistance.

I decided to do some tests of my own around boot times. After all, apart of the pleasure I get with my MacBook Pro is how well it performs when opening and closing the lid.

It’s important to keep in mind that when you add drive encryption, for best protection you want to shut down. No more sleep mode for me.

*Boot times were recorded using an iPhone 3Gs Clock app with stopwatch feature. Keeping things level on the Apple technology playing field.

Hopefully making the data easier to read, I used a matrix.

FileVault 2 Boot Times Matrix

FV2 State Encryption State Boot type Time to (in seconds)
POA Login Usable Total Increase
OFF OFF Cold N/A 46.4 12.3s 58.97s N/A
ON Not started Warm 10s N/A 98.6s 108.6s 49.63s
ON Started Cold 10s N/A 78.4s 88.4s 29.43s
ON Completed Cold 10s N/A 83.9s 93.9s 34.93s

FV2 State means if FileVault 2 was enabled or not
POA means Power-On Authentication
Time To POA means the time it took to get to POA for authentication
Time To Login means the time elapsed after POA to get to a Mac OS X login prompt
Time to Usable means until Mac OS X 10.7 was usable. To keep things fair, I used a script that Automator launched at boot. When the called application presented a password prompt Mac OS was considered to be usable.
Total = POA + Login + Usable
Increase means the time added to the overall boot process

The average of three boot attempts is the value presented in each matrix. As you can see, the average boot time with no encryption took just under 59 seconds. This number is subtracted from the Total boot times recorded to get the Increase in boot times.

After initial encryption completes, the overall boot time increase for FV2 is 34.93 seconds.

Some people may argue this with me, but considering that Apple controls the operating system and the source code this is pretty ROTTEN

Sophos Disk Encryption for Mac Boot Times Matrix

SDE State Encryption State Boot type Time to (in seconds)
POA Login Usable Total Increase
OFF OFF Cold N/A 46.4 12.3s 58.97s N/A
ON Not started Warm 7.0s 43.9s 17.8s 68.7s 9.73s
ON Started Cold 7.1s 66.6s 6.3s 80.0s 21.03s
ON Completed Cold 7.0s 59.4s 11.1s 77.5s 18.53s

Performing the same tests, under the same conditions, after initial encryption completes the overall boot time increase for SDE is 18.53 seconds.

If boot times are a top concern for your organization, this is going to definitely be CRISPY for you.

Comparative Boot Times Matrix

Technology Encryption State Time to (in seconds)
POA Login Usable Total Increase
FV2 Completed 10.0s 83.9s 93.9s 34.93s
SDE Completed 7.0s 59.4s 11.1s 77.5s 18.53s
Variances Completed 3.0s 24.5s 16.4s 16.4s

The net result is that when a MacBook Pro released early 2011 starts from a cold boot with encryption, you should expect to see SDE perform 16.4 seconds faster than FV2.

Keep in mind that different models with different drive speeds, processor speeds and RAM will yield different results.


Recovery is a hugely important capability with *any* encryption solution. It’s a horrible feeling when your data looks like it’s lost.

It’s even worse when you could have avoided it if using encryption and you lost your recovery key.

FV2: During the FV2 activation process, you will be presented with a recovery key. That key can either be stored with Apple or with yourself.

If stored with Apple, you will be asked to answer three security questions to encrypt the recovery key. Apple is quite clear that if you forget your answers, they are not responsible for recovering your key.

Store Recovery With Apple

Storing the recovery key with Apple

I actually like this feature for non-technical home users that are good at remembering their security question and answers. CRISPY

If you choose to not store the recovery key with Apple, then put that 24 character, alpha-numeric string someplace safe and not on the same computer you encrypted.

Perhaps in the cloud?


Recovery provided with FileVault 2 when you forget your password

Let’s say for some reason in the future you need to change that recovery key, Apple provides that capability.

In order to change the recovery key you will need to fully decrypt your drive and fully encrypt your drive again. We already know that it takes 7 hours for encryption, to change the recovery key it will take roughly 14 hours. ROTTEN

For more information on OS X Lion Recovery, Apple wrote a really detailed and understandable article HT4718. In the event you only have one computer, my advice is to print it out today and file it.

You never know.

SDE: Password recovery keys are generated with SDE either in the GUI or the CLI and doesn’t require changing the encryption state.

This is especially handy for small to medium organizations or large enterprises that want to automate generating the recovery centrally.

In the event of boot failure, SDE has a pre-boot environment that can be used to authenticate to and used to recover encrypted data. CRISPY

Comparative: As critical as data and password recovery is for encrypted disks, Apple still has much growth in this area.

SDE provides a few methods for data and password recovery which is essential in the event one method isn’t successful.

Let’s face it. I can’t think of anyone who would volunteer to tell the CEO of their company that the encryption is the reason the family vacation photos are lost forever.


It’s one thing to say your encrypted, it’s another to prove it.

FV2: As of this posting I couldn’t find a method for centralized reporting without scripting.

If someone out there really needs reporting, I found a command diskutil cs list which will provide status of the CoreStorage logical volume groups.

Grepping the command and redirecting the output to text file and massaging the output to meet your needs is plausible. The raw output on my MacBook Pro looked like this:

David-Schwartzbergs-MacBook-Pro:~ IluvNakeSec$ diskutil cs list
CoreStorage logical volume groups (1 found)
+-- Logical Volume Group 31D7AED9-6AE4-44B2-80A5-2CBE0E7AA4E6
Name: Macintosh HD
Sequence: 1
Free Space: 0 B (0 B)
+- Logical Volume Family A88A8F6F-AABC-4ADA-853E-7F1FC3F3D71D
Sequence: 9
Encryption Status: Unlocked
Encryption Type: AES-XTS
Encryption Context: Present
Conversion Status: Complete
Has Encrypted Extents: Yes
Conversion Direction: -none-
+-> Logical Volume 34FB0CAC-800D-4222-9030-178AE32765B3
Disk: disk1
Status: Online
Sequence: 4
Size (Total): 498929332224 B (498.9 GB)
Size (Converted): -none-
Revertible: Yes (unlock and decryption required)
LV Name: Macintosh HD
Volume Name: Macintosh HD
Content Hint: Apple_HFS

The bolded line above which reads, “unlock and decryption required” is the indicator that FV2 is enabled.

While I like using command line and grepping, it goes against Apple’s history of technology being easy and just working. ROTTEN

SDE: While out of the box, SDE isn’t much better when it comes to reporting.

It’s better because the sgadmin command will yield the encryption status.

Volume info :
| Index | Name | UUID | State | Encrypted | Capacity |
| 0 | Macintosh HD | 5BE8216E-AF64-40B0-AA89-09FE5069EFC3 | Partially encrypted | 58.30 % | 300.1 GB |
| 1 | Data | D761FC9C-FB4C-42F2-9C7C-0BCCAC523013 | Encrypted | 100.00 % | 199.5 GB |

If CLI gets you down and you really want something more 21st Century. JAMF’s Recon Suite will provide reports in different formats including PDF.

When I last checked, Recon does support reporting for FileVault (notice the ‘2’ is missing). If you decide to use FV2 with Recon, I couldn’t find anything on their Support site so please contact JAMF directly to confirm supportability.

Comparative: Both SDE and FV2 fair about the same in the reporting category. The extra nudge forward goes to SDE for having better CLI options to provide encryption status without the need to grep the heck out of ASCII scrolling across Terminal.

I was also able to find logs (Yes LOGS!) of when SDE started and completed initial encryption (/var/logs/secure.log is your friend).


In an effort to reduce the length of this review (yeah I know, too late) I put down some additional thoughts covering other categories.

Security – A company called Passware has a product named Passware Kit Forensics v11 (cost $995) which analyzes a Mac’s live memory via FireWire even if the computer is locked or sleeping. It can even extract passwords in the Mac’s keychain password store; regardless of strength and with FV2 enabled. ROTTEN

As noted above, the defense is to turn off the computer when not in use, which Naked Security recommends.

Software Updates such as security updates and patches to Mac OS X are supported by both encryption solutions which is always CRISPY.

BootCamp support for FileVault 2 is available but according to a forum posting at Notebook Review there are some steps necessary before encryption on the Windows partition.

There are additional conversations happening on the BootCamp + FV2 topic in the Apple Support Communities.

SDE supports BootCamp, see article 112825 for details on setting it up.

Network User support for FileVault 2 is currently not available. In order to get a network user to access a locked FV2 drive, a local user needs to login first to unlock the disk. This is explained in Apple article HT4652.

Non-boot volumes can only be encrypted using the diskutil cs 'disk' -password 'password' command with FV2. The only documentation I found for additional internal volumes pointed to using Terminal.

SDE is able to encrypt additional volumes from the GUI or the CLI during deployment.

Updated: Thanks to a reader who reminded me about making a mention of how to add multiple users to the FV2 pre-boot authentication. User Provisioning is a big part of deploying any encryption solution.

FileVault 2 leverages the native user accounts to the operating system, which is cool.

Nonetheless, in order to add multiple users to the FV2 pre-boot authentication, the user needs to physically be there to enter their password. If they are not present during initial setup, then another user who can unlock the drive needs to later add that tardy user when present, assuming they can also change the FV2 settings in System Preferences. ROTTEN

SDE pre-boot users (one or more) can be added in the GUI or via the CLI during deployment without the user’s attendance as a requirement.

Closing remarks

In summary, Apple has joined the ranks of Microsoft by providing native operating system full disk encryption to the consumer market.

Congratulations for your hard work and efforts!

OS X 10.7 Lion FileVault 2 has some great features such as initial encryption speed, easy key recovery method for home users, ability to reboot during encryption or decryption process and you can change your mind if you started encrypting before your Time Machine backup or just chicken out.

FileVault 2 clearly falls into the shadows of Apple’s position of not catering to the corporate marketplace.

Which is fine because that is Apple’s choice and the majority of their customers love them for that philosophy.

For home users and small business owners with the need for encryption, paying $29.99 to upgrade to OS X 10.7 Lion is a steal.

Any organization looking at FV2 with the need for central management, network user support, central deployment, centralized reporting, high performance and strong security I heed a word of caution.

There are third party commercial alternatives which will meet your needs such as Sophos Disk Encryption.

For an interactive review of FileVault 2 between Chester Wisniewski and myself, plug into the Chet Chat 69 podcast.

Until next time, keep it safe and secure online.


Interviewed on Sophos Security Chet Chat 69

FileVaultChet Wisneiwski invited me to be a guest on his podcast Sophos Security Chet Chat for episode 69.

There was interesting news that week, especially the capture of Topiary from Lulz Security. Chet went through the news headlines and then moved on to interview me on my initial impressions of Mac OS X 10.7 Lion’s FileVault 2.

FileVault 2 is partition level encryption which replaces the previous version of file level encryption. My advice it to listen to the podcast first, and if the interview strikes a chord with you, then read my blog posting here at DSPN for more details.

Until next time, stay safe and secure online.

Can simple Google searches reveal your secrets?

Encrypted data
My apologies for not doing a better job of keeping this blog a bit more current.

On July 5th, I posted a blog titled “Can simple Google searches reveal your secrets?” at Naked Security touching on how security information is available on public servers which are getting crawled by Google. This is not a jab at Google, but more of an awareness blog of how good security solutions can be compromised with bad security practices.

My recommendation is to revisit your security practices with a new pair of eyes. Hopefully you will gain from it.

I hope you enjoy the blog posting and please comment either here at DSPN or Naked Security. If you make a reasonable comment which invokes the need for me to reply, I will make every attempt to engage you in a conversation.

Until next time, keep it safe and secure online.

Sophos is a Platinum Sponser at SC Congress Canada

Sophos is a Platinum Sponser at the SC Magazine Congress in Toronto, Canada. I’ll be attending and looking forward to speaking with people on June 14th and 15th during the SC Congress in Toronto, Canada. Come by the booth to talk security or attend our session on “Where’s your data?”

For my impressions of the conference, please see my guest blog posting at Sophos Naked Security.

click for SC Congress Canada

Facebook privacy under scrutiny…again.

I heart Thessa

When I first heard about Thessa’s birthday party in Germany grew to a head count of 1,500 it reminded me that I forgot to go.   Her birthday party was actually not intended to be so large and only 10% of the positive respondents to her Facebook event crashed the party. It’s apparent that this was evidence of poor privacy settings. Both parties are at fault here, Facebook for having too loose of default settings and Thessa for not changing those settings.  Wait, she’s a teenager, so should she be exempt from fault?  It might be a gray area for some, but not me. At what age does the hall pass go away when it comes to being safe and secure online?

The coming of age in this information privacy era is up to the individual.  Once that individual is able to go online and read at a level to understand that there are privacy settings is when the hall pass goes away.  Smaller children using a computer at home still need to rely on their parents to protect them and educate them about better online etiquette and safe computing.  The parents should be changing the less fun sections of their favorite social media web sites to protect their children.  In case you are having trouble getting through the techno-babble and computerese, I provided some basic steps on how to be safer online with Facebook.

Keep in mind that these instructions may change the next time Facebook relaunches their interface.

1. In the upper right hand corner of Facebook there is the Account drop-down menu you see here. After the menu appears, click on the ‘Privacy Settings’ menu option.
2. The ‘Privacy Settings’ menu option will take you to a page to choose your privacy settings. As you can see in my example, the dots are almost all to the right. To achieve this, click the ‘Customize settings’ link that you see in the red triangle.

Click to enlarge

3. The ‘Customize settings’ link will take you to a page that is much longer than shown here. There is the important part where you will need to go through each setting to restrict who can see what information about you. Please do this with your children, of any age, to protect them.

Click to enlarge

As far as Thessa, when I heard she fled her own party. I wondered if she was heading to the Hamburg-Bramfeld Costco to get more chips. Those chaps look hungry.

Health Information Privacy –

From the website:
“As required by section 13402(e)(4) of the HITECH Act, the Secretary must post a list of breaches of unsecured protected health information affecting 500 or more individuals.  These breaches are now posted in a new, more accessible format that allows users to search and sort the posted breaches.  Additionally, this new format includes brief summaries of the breach cases that OCR has investigated and closed, as well as the names of private practice providers who have reported breaches of unsecured protected health information to the Secretary.  The following breaches have been reported to the Secretary:”

Breaches over 500

Breaches affecting over 500 individuals

While searching for statistics on data breaches, I stumbled upon the U.S Department of Health and Human Services web page for Breaches Affecting 500 or More Individuals. As of this posting there are 288 recorded incidents of unprotected health information leaking since September 9th, 2009. I like how the HHS offers to save the entire data set of information in CSV and XML formats for personal consumption. For example, this gives you the ability to sum the total of ‘Individuals Affected’ column to put things in perspective.

Sony Data Breach Timeline

In an effort to keep things straight in my head, it made sense to create a timeline of the Sony data breaches (and near data breaches) which were reported either by Sony or by the individuals themselves. This chronology is primarily the attacks which resulted in data loss pieced together by different news sources and not any of the other events in the timeline, such as PSN coming back online. If you find something that’s in need of being updated, please send me an email through this blog.

Hopefully Sony will get their security straightened out in time before the next attack occurs.

Sony Business Unit

(or suspect)

1 April 17th
Sony PlayStation Network/Qriocity Anonymous
2 May 2nd
Sony Online Entertainment
3 May 5th
Sony Electronics, Inc. Sony
Sony Electronics, Inc.
  • The Hacker News coverage of this data breach, which doesn’t look like a hack attack, explains how this is negligence. Using a Google search for on “ filetype:xls” resulted in access to an Excel spreadsheet containing 2,500 pieces of user data. As the THN puts it “Huh, is this called Hacking ????” Well said. It’s called searching.
  • Naked Security Blog Posting
4 May 17th
Sony PlayStation Network/Qriocity
  • The Hacker News coverage of this attack explains that it’s not a true hack, simply reuse of already exposed user data.
5 May 20th
Sony Thailand
  • No public claim has been found for this attack.
  • In this attack a phishing website was setup targeting an Italian credit card company on the Sony Thailand web server. I couldn’t find any definitive quantity of lost user data, but it’s safe to say there’s a high probability of a breach. Magnitude unknown, nonetheless, a breach.
  • source from Digital Trends posting
6 May 21st
So-net Entertainment
  • No public claim has been found for this attack.
  • Computer World reported that So-net, an ISP subsidiary of Sony, had a breach of about $1,200 virtual tokens by the intruder redeeming 130 accounts. In addition, 73 accounts were breached, but not redeemed, and 90 e-mail accounts were compromised.
7 May 21st
Sony Music Indonesia Defaced k4L0ng666
  • While no actual data was taken during this defacement, it existing in the timeline.
  • The Hacker News report on this defacement.
8 May 22nd
Sony BMG Greece b4d_vipera
9 May 23rd Sony Music Japan Lulz SecurityLulzSec
10 May 24th Sony Ericson
11 June 2nd Sony Pictures Lulz Security
  • Lulz Security made is very clear they were behind this data breach. They broadcasted their activities under operation “Sownage” which is a pun on ‘Sony’ + ‘ownage’. The most disturbing aspect of this is that Sony didn’t use any obfuscation/hashing/encryption on the passwords.
  • “Over 1,000,000 users’ passwords, email addresses, home addresses, dates of birth, as well as administrator login passwords acquired by hackers ”
    (source DATALOSSdb ID: 3790)
  • This incident 3790 also includes data from Sony BMG Belgium and Sony BMG Netherlands.
  • Naked Security blog posting
12 June 3rd Sony Europe idahc_hacker
  • Idahc was at it again using another simple SQL Injection method to gain unauthorized access to 120 usernames, passwords (plain text), mobile phone numbers, work emails and website addresses.
  • Naked Security blog posting
13 June 5th Sony Pictures Russia
  • An undisclosed group or individual used another simple SQL Injection method to gain unauthorized access. Extent of the data breach is still undetermined. This could have possibly been an upstart hacking club testing the waters and their salt.
  • Data loss included the database structure of the cosmocard_1 catalog.
  • Naked Security blog posting
14 June 6th Sony CED Network Lulz SecurityLulzSec
  • In a couple of tweets LulzSec presented Sony Computer Entertainment Development Network source code out into the wild. SQL Injection method to gain unauthorized access to 120 usernames, passwords (plain text), mobile phone numbers, work emails and website addresses.
  • Via they shared the source code in a 58MB download in the form of a torrent.
  • The Hacker News coverage
15 June 6th Sony BMG Music NA Lulz SecurityLulzSec
  • In the same torrent made available on, Lulz Security made publicly available Sony BMG internal network diagrams.
  • The network diagrams included a great deal of detail about the Sony BMG Music network. Unfortunately for the author, Shawn Gyorfy, it included his name. I like to take pride in my work as well, but not when it’s labelled ‘INTERNAL USE ONLY’ for the world to read. In addition to the diagrams, there were PDFs which included hub sites, router IDs, Circuit IDs, IP addresses, site contact names and phone numbers, VLAN information, networking product make, model, hostname and management IP address.
  • The Hacker News coverage
16 June 8th Sony BMG Music Portugal idahc_hacker
  • Idahc the Lebanese hacker in a pastebin post declared that he or she is not a black hat hacker, but a gray hat. Idahc backed this statement up by only dumping Sony customer’s email addresses and not the entire database.
  • The attack was conducted by exploiting 3 flaws in the Sony web site, which were 1) SQL injection, 2) XSS and 3) iFrame injection.
  • Naked Security blog post
17 June 8th The Sony Marketing Co.
  • This is from the Sony Japan web site:
  • The Sony marketing company, to dawn on June 8, “spoofing” occurs for unauthorized access attempts by a third party e-mail address and password, and Sonisutoa earn by shopping for Sony products in Sony ” “point, and we found that there is a possibility that the exchange coupon and shopping available in Sonisutoa.
    We have so minimize the damage done to the following measures.
    The evidence of leakage of personal information including email address and password from us is not confirmed.
    The situation, apologize for the inconvenience and worries that your customers and everyone in between.
  • Number of potential email addresses used to exchange illegal exchange status by fraud masquerading Sony Points ■: Number of points that were considered illegal to exchange coupons shopping 278,000 95 points (about 280,000 yen worth)
18 June 19th Sony Pictures France idahc_hacker
  • Idahc the Lebanese hacker did a duet with his French friend Auth3ntiq on Sony Pictures France. In a pastebin post declared again that they are not black hat hackers. Possibly in a ruch but this time they didn’t state that they are gray hat hackers.
  • Using another SQLi, the data breach included the /etc/passwd file dump and a snippet of “emails found : 177172”.
%d bloggers like this: