STE WILLIAMS

Google and Microsoft have both increased the cash on offer under their bug bounty programs.

Google’s increases are permanent, in recognition of what security program manager Josh Armour says is an environment in which “high severity vulnerabilities have become harder to identify over the years.” Google’s therefore going to pay more to reflect the time it takes to find nasty flaws.

Google’s priority remains remote code execution flaws, which can now earn white hats up to US$31,337. Google’s ceiling for payments used to be $20,000.

Finding a bug that permits “unrestricted file system or database access” can now result in $13,337 heading your way, up from $10,000.

A full list of what Google is looking for, and will pay for, can be found here.

Microsoft’s also increased its payouts, but only for two months and for a handful of services.

The good news is that Redmond’s doubled payouts for vulns that meet its criteria, namely any of the following:

• Cross Site Scripting (XSS)
• Cross Site Request Forgery (CSRF)
• Unauthorized cross-tenant data tampering or access (for multi-tenant services)
• Insecure direct object references
• Injection Vulnerabilities
• Authentication Vulnerabilities
• Server-side Code Execution
• Privilege Escalation
• Significant Security Misconfiguration (when not caused by user)

The bonus bounties apply only on the following platforms.

• portal.office.com
• outlook.office365.com
• outlook.office.com
• *.outlook.com
• outlook.com

Microsoft’s not said why it’s made the special offer for those domains, but clearly it feels they need to be given a thorough going-over. The Register can offer a couple guesses as to why. A simple reason could be that they just haven’t attracted many bounty hunters. Another could be that they are running new code worthy of extra probing. The timing of the bloated bounty is also interesting, because as by the start of May we’ll be very close to the launch of the Windows 10 Creators Update. That release, we already know, will link with Office 365 Advanced Threat Protection. Coincidence? With $30k up for grabs, does it even matter? ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/03/06/google_microsoft_bump_bug_bounties/

“Data breach hunter” Chris Vickery has claimed that he will shortly reveal a “1.4 billion identity leak”.

1.4 billion identity leak story incoming Monday morning.

Thanks go to @SteveD3 (and someone else) for cooperating on investigation.

— Chris Vickery (@VickerySec) March 3, 2017

He later offered a teaser of the leak, also reducing the number of identities by 30,000.

Teaser screenshot of that DB’s summary data: pic.twitter.com/PEnpJbDZRt

— Chris Vickery (@VickerySec) March 4, 2017

Vickery, of MacOS security software house MacKeeper, has good form finding breaches: he spotted one involving US Military Special Operations Command healthcare professionals and the Trump-for-president campaign’s leaky AWS server.

Speculation as to the identity of the victim is naturally rife and as the size of the breach is huge, the list of candidates is short.

Close to the top of the list is “Aadhaar”, India’s biometrics database of its citizens. But the Government of India quashed what it labelled “misinformation in some news items and articles appearing in various print and social media during the last few days” by issuing a statement saying, in part, that there has been “no incident of misuse of Aadhaar biometrics leading to identity theft and financial loss during the last five years.”

The only other nation with the potential for a database to contain 1.37bn identities is China, and it’s been busy with the set piece of the National People’s Congress over the weekend.

Which brings us to other candidates, namely:

• Facebook: And wouldn’t plenty of folks love to see The Social Network™ take a fall? Is thought to have over 2bn subscribers for its main service, about the same for Messenger and around half that for subsidiary WhatsApp;
• YouTube: See above for schadenfreude value, but don’t get excited as is not thought to have 1.37bn users;
• WeChat: Chinese chat platform is thought to have 1bn+ users, with a fair few beyond the Middle Kingdom
• Tencent: Chinese IM platform QQ and social network Qzone are both thought to have over a billion users;
• Yahoo!: As we discovered last week, Yahoo!‘s security processes were dysfunctional and its billion-plus user database has already been raided twice. Bad news comes in threes …
• Apple: Cupertino has sold a billion iPhones, plus stacks of iPods and Macs. Lots of repeat customers mean it may struggle to hit the 1.37bn identities mark, but Vickery hasn’t said they’re unique Identities;
• Microsoft: With more than 2bn PCs in operation, Redmond has data on an awful lot of people. Can’t be ruled out. See logic for Apple, too;
• A data harvesting company: The likes of Oracle, Salesforce and Wayin have colossal databases of individuals and businesses they sell to marketers and others, and claim to have hundreds of millions of records. Can’t be discounted.

Whoever it is, come Monday US time it looks like plenty of us will be changing passwords and/or deleting accounts. Again. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/03/06/researcher_warns_of_one_point_four_billion_identity_leak/

Beta users of Apple iOS 10.3 are reporting that they’re receiving push notifications from Apple to enable two-factor authentication (2FA) for their Apple IDs, which is used on Apple devices (like iPads, iPhones and Macs) to synchronize and share iCloud user data.

Apple’s 2FA provides an extra layer of security for iCloud data as well as for devices registered to an Apple ID, and it seems with iOS 10.3 that Apple is taking stronger measures to encourage its users to enable this feature.

Two-factor authentication isn’t new on iDevices, as it has been available for well over a year since iOS9 and OS X El Capitan – notably, the feature became available first for iCloud after a spate of celebrity iCloud hacking incidents, and then more broadly to secure Apple devices soon after.

Until iOS 10.3 leaves beta, you may not get the notification from Apple to enable 2FA, but the good news is that as long as your device fits the system requirements, you don’t need to wait for Apple’s friendly reminders.

Here’s how you can enable 2FA on your iPhone right now (if you are running iOS 9 or later):

• Tap the “Settings” app
• Scroll down and tap “iCloud” (assuming you are logged in with your Apple iCloud ID already)
• Tap your Apple ID, which will appear at the top of the screen
• On the next screen, tap “Password Security”
• In the middle of the screen, you will see “Two-Factor Authentication,” likely already set to “Off.” Tap “Turn on Two-Factor Authentication” and follow the prompts to set up 2FA for your device. You may be asked to verify your identity by answering security questions and confirming the credit card details you have on file tied to your Apple ID.

Note: If you do not have a passcode set up on your mobile device, you will be prompted to create one before you can enable 2FA.

Follow @NakedSecurity
Follow @mvarmazis

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/fjQF_QC6vg8/

Earlier this week we wrote about OSX/Filecode, a Mac ransomware family that follows a path of digital extortion that is well-known to Windows users.

Generally speaking, ransomware hits when you download a file, or are tricked into running an attachment, that claims to be one thing, anywhere from a fake invoice to a software crack…

…but turns out to be quite another.

Filecode pretends to be a cracking tool.

The malware pops up a dialog to say that it “may take up to 10 minutes” to do its job, which is supposedly to hack Adobe Premiere or Office 2016 so you can keep on using it without paying the licensing fees:

Software cracks of this sort do exist, and some of them may even work, but figuring out when you can trust shady software from shady corners of the internet that you downloaded for your own shady purpose…

…is always going to be a hard task.

The good news is that Filecode doesn’t contain any software cracking code that might get you in trouble with the piracy police.

The bad news is that it is entirely focused on scrambling your data, using a randomly-generated 25-character encryption key that exists only in memory while the malware runs.

After that, the malware author gives you instructions on how to pay him a ransom, in return for which he’ll unscramble the data for you.

This raises two questions.

If the decryption key is lost after the malware finishes running, how can the crook possibly recover your files?

And if he can do it, what’s to stop you following the same process and recovering them for yourself for free?

Most ransomware creators deal with these decryption issues in one of these ways:

1. Call home first to a web server that generates an random encryption key on demand. This way, the crooks have a guaranteed record of the decryption key that matches your computer, but you don’t. The generated key is what they sell back to you later. If your network security software blocks the call-home request, the ransomware is stalled and can’t run at all.
2. Generate a random key locally and use it in memory only, but call home during or immediately after the encryption process to backup the key remotely. If you block the call-home request in cases like this, the ransomware runs but the key is lost.
3. Generate a random key locally, use it, and save it locally after encrypting it again with a public key. As long as the crooks keep the corresponding private key to themselves, they alone can decrypt the decryption key that you need. (It’s OK if you need to read that twice.)

Approach (3) works because of the difference between symmetric and asymmetric encryption. Symmetric, or secret-key, cryptography uses the same key to lock and unlock data, and it is usually used for protecting large quantities of data such as disks and files. But if you want to share symmetrically-encrypted data across the internet, you need a secure way to share the secret key first. Asymmetric, or public-key, cryptography uses a different key to lock and unlock, making it an excellent tool for sharing data securely over a network. You share your public key with everyone so they can lock data to send it to you; you keep your private key private so you’re the only one who can unlock the data at the other end. That way, it can’t be snooped or modified in transit. But public-key cryptography is far too slow for encrypting files and disks, so a hybrid approach is used: encrypt the data with a random symmetric key, and encrypt the symmetric key with the public key. Now, only the holder of the private key can unlock the symmetric key, so only the holder of the private key can unlock the symmetrically-encrypted data.

Filecode, however, doesn’t use any of these methods.

The malware uses the zip program to encrypt all your files with a randomly-chosen 25-character password, and throws the key away.

The crook then tells you to pay him 0.25 bitcoins (BTC 0.25 was about $300 at the end of February 2017), hook your computer up to the internet so he can access it remotely, and contact him by email to let him know you’re ready.

He says that, within 24 hours (or within 10 minutes if you pay the premium fee of BTC 0.45 instead) he’ll connect into your Mac and recover your files:

So, if the crook can recover your data from first principles by cracking the now-forgotten password, why can’t you?

The answer is, “You can,” and here’s how we did it on our test Mac.

Secrets revealed

The encryption used by default in zip files comes from the original PKZIP software, named after the late Phil Katz, who wrote it and started PKWARE, the company that sold it.

But the PKZIP cipher (officially denoted “traditional PKWARE encryption”, but we’ll call it just zipcrypt from now on) was designed by a programmer, not by a cryptographer.

Zipcrypt simply doesn’t mix things up well enough to be secure.

Internally, the algorithm uses three 32-bit key values, key0, key1 and key2, that are repeatedly mixed together so that each key changes after every byte is encrypted; the byte you’ve just encrypted is added into the mix as well:

function update_keys(newbyte)
   key0 = crc32(key0,newbyte)          --mix the new byte into a running CRC-32
   key1 = key1 + low8bitsof(key0)      --add the bottom byte of key0 into key1
   key1 = key1 * 134775813 + 1         --apply linear congruential PRNG to key1
   key2 = crc32(key2,top8bitsof(key1)) --mix the top byte of key1 into a running CRC-32
end

Don’t worry if you aren’t a programmer or don’t understand the notation above.

What’s important is that at each byte-sized encryption step:

• key0 is updated by mixing up its current value with the plaintext character you just encrypted. The mixing algorithm is the CRC-32 checksum algorithm.
• key1 is updated by adding in one byte from the updated key0 and then mixing up the value using a simple pseudo-random number generator (PRNG). This is the same pseudo-random code used by the old Turbo Pascal and early versions of Borland Delphi.
• key2 is updated by mixing up its current value with one byte of the update key1, using CRC-32.

To encrypt a byte, you XOR it with a cipher-stream byte that is computed from the bottom 16 bits of key2, like this:

function encrypt_byte(newbyte)
   local cipherbyte
   cipherbyte = bottom16bitsof(key2)             -- take 16 bits from key2
   cipherbyte = cipherbyte OR 2                  -- set the second-bottom bit to 1
                                                 -- (this ensures temp is never zero) 
   cipherbyte = cipherbyte * (cipherbyte XOR 1)  -- mix together the 16 bits of temp
   cipherbyte = secondtobottombyteof(cipherbyte) -- take the top 8 of the bottom 16 bits
   return newbyte XOR cipherbyte                 -- XOR this cipher byte into the stream
end

With three 32-bit internal keys that produce one XOR key-byte at a time, zipcrypt is technically a stream cipher with a 96-bit key (3×32 = 96), which means there are 2⁹⁶ keys if you want to try them all in a brute-force attack.

At first glance

How secure is zipcrypt?

At first glance, you might think that this algorithm doesn’t do anywhere near as much mixing-mincing-shredding-and-liquidising as you’d expect, at least if you compare it with cryptographic algorithms that work on bigger blocks of data, such as AES or SHA-3.

There also doesn’t seem to be much of what is often referred to as avalanche or diffusion between the three internal key values, with just 8 bits of new data percolating into each key value at every step.

For example, key0 never incorpoates bits from key1 or key2, nor key1 from key2, and so on, and the new bits that come into key0 from the current plaintext byte take two more encryption cycles to have any effect on key2.

You might also be concerned that the core “mixing” algorithms that were chosen as randomisers, CRC-32 and the Turbo Pascal PRNG, were not designed for cryptographic use, but rather for speed and simplicity.

Indeed, the problem with both CRC-32 the the PRNG used by zipcrypt is that if at any point you can figure out where you are in the cycle of random numbers they’ve just produced, you can figure out what comes next and thus reconstruct the random sequence from then on, no matter how secretly the algorithm was initialised, or seeded, in the first place.

And if you think that there might therefore be cryptographic chinks in the internals of zipcrypt, you’d be right, as two well-known names in the cryptographic community, Eli Biham and Paul Kocher, found in the mid-1990s.

Their paper, A known plaintext attack on the PKZIP cipher, documents how they uncovered a way to compare a known plaintext file with its zipcrypt ciphertext equivalent, and from there to work backwards to figure out the starting values of key0, key1 and key2 that were used to encrypt it.

Any other encrypted files in the same ZIP archive, or any other ZIP files using the same password, can then be decrypted without any further effort.

Note that this means you don’t need to figure out the actual password used in the first place, which is itself churned through the zipcrypt algorithm as many times as there are characters in the password to produce the three starting values for key0, key1 and key2.

That’s just as well, because the Filecode malware chooses a 25-character password from the characters A-Za-z0-9 for a total of 62 characters and thus 62²⁵ possible passwords, or close to one billion billion billion billion billion.

You don’t even need to try out all 2⁹⁶ possible combinations of key0, key1 and key2, which is getting on for one million million million million million.

In fact, with a handy utility that also dates back to the 1990s, PKCRACK, we did the job in 42 seconds.

Cracking the keys

After the malware had finished running on our test Mac, all our files had been ZIPped with a password and renamed to have the extension .crypt:

/Users/duck/Desktop/letterlegal5.doc.crypt
/Users/duck/Desktop/lorem_document_PDF.pdf.crypt
/Users/duck/Desktop/shattered-1200.jpg.crypt
/Users/duck/Desktop/wt-tmpdkhvbs-500.png.crypt
/Users/duck/Desktop/YankeeHotelFoxtrot.mp3.crypt
/Users/duck/Documents/.localized.crypt
/Users/duck/Documents/2003-example-spreadsheet.xls.crypt
/Users/duck/Documents/2014_04_a4_format.doc.crypt
/Users/duck/Documents/Document-English.docx.crypt
/Users/duck/Documents/Large Spreadsheet Sales (Excel).xls.crypt
/Users/duck/Documents/officialformat.doc.crypt
/Users/duck/Documents/Thesis-and-Dissertation-Templete.doc.crypt
/Users/duck/Music/Webdriver_Torso.mp3.crypt
/Users/duck/Music/YankeeHotelFoxtrot.mp3.crypt
/Users/duck/Pictures/corplogo.png.crypt
/Users/duck/Pictures/shattered-1200.jpg.crypt
/Users/duck/Pictures/wt-tmpdkhvbs-500.png.crypt

We needed just one file for which we had a backup copy of the original, so we chose a logo file we could find again online: corplogo.png.

By ZIPping up the plaintext version of the file using the same compression options as the malware, we then had a corresponding set of plaintext and ciphertext ZIP files, both containing a file called corplogo.png:

duck@testmac:~/Temp$ zip -0 corplogo.png.plain.zip corplogo.png
  adding: corplogo.png (stored 0%)
duck@testmac:~/Temp$ ls -l corplogo*
-rw-r--r--  1 duck  staff  7189 28 Feb 10:00 corplogo.png        --plaintext original file 
-rw-r--r--  1 duck  staff  7435 13 Feb  2010 corplogo.png.crypt  --encrypted ransomware ZIP 
-rw-r--r--  1 duck  staff  7365 28 Feb 11:47 corplogo.plain.zip  --plain ZIP created above
duck@testmac:~/Temp$ 

The malware uses the zip -0 option for “no compression’, presumably to make the scrambling process faster, because compressing files can be very slow. That’s why we did a matching zip -0 above. The unusual timestamp on the ZIP file corplogo.png.crypt (2010-02-13) is deliberately set by the malware. We don’t know what significance this date has, except perhaps to be unusual.

Then, we set PKCRACK to work.

The options it needs are: the name of the encrypted ZIP; the unencrypted ZIP to compare it to; the name of the corresponding file in each archive; and a new name for its own decrypted version of the ZIP so we could check that the process succeed:

duck@testmac:~/Temp$ pkcrack -C corplogo.png.crypt -P corplogo.png.plain.zip 
                                  -c Users//duck/Pictures/corplogo.png  -p corplogo.png 
                                  -d corplogo.png.decrpyt
Files read. Starting stage 1 on Tue Feb 28 11:50:05 2017
Generating 1st generation of possible key2_7200 values...done.
Found 4128994 possible key2-values.
Now we're trying to reduce these...
Lowest number: 969 values at offset 4095
Lowest number: 952 values at offset 4076
[. . .]
Lowest number: 487 values at offset 399
Done. Left with 487 possible Values. bestOffset is 399.
Stage 1 completed. Starting stage 2 on Tue Feb 28 11:50:22 2017
Ta-daaaaa! key0=ac5d37ee, key1=b7c718ab, key2=3bc7973b
[. . .]
Stage 2 completed. Starting zipdecrypt on Tue Feb 28 11:50:47 2017
Decrypting Users//duck/Pictures/corplogo.png (c407e43e418b6e49cbc43e75)... OK!
Finished on Tue Feb 28 11:50:47 2017

42 seconds later, and PKCRACK was done, giving us the 96 bits of key material that we needed to unlock all our other files.

The double-slash in the filename Users//duck/Pictures/corplogo.png in the PKCRACK command line above is needed to match the way the malware creates its encrypted archives. Unix filenames can have one or more slashes to separate each directory name in a path, so that path/file.txt and path//file.txt refer to the same filesystem object. You can check the names of files inside an encrypted ZIP file using unzip -l, because only the file contents are encrypted – that’s how we spotted the extra slash after the first part of the directory path.

We UNZIPped the decrypted ZIP generated by PKCRACK, just to make sure we were on the right track:

duck@testmac:~/Temp$ unzip -j corplogo.png.decrpyt 
Archive:  corplogo.png.decrpyt
replace corplogo.png? [y]es, [n]o, [A]ll, [N]one, [r]ename: r
new name: corplogo.recovered.png
 extracting: corplogo.recovered.png  
duck@testmac:~/Temp$ shasum -a 256 corplogo.recovered.png corplogo.png
7190c9d479e6c344fcd6ebcf2455ec8d9d00d10a09386cd56308b39d70c7ccec  corplogo.recovered.png
7190c9d479e6c344fcd6ebcf2455ec8d9d00d10a09386cd56308b39d70c7ccec  corplogo.png
duck@testmac:~/Temp$

The logo file we extracted from the unscrambled ZIP file matched the original copy, so we carried on.

Next, we used PKCRACK’s special zipdecrypt tool to convert all our other files – that’s like a special version of unzip that takes in raw values for key0, key1 and key2 where unzip would require you to put in the original password:

duck@testmac:~/Temp$ for f in *.crypt; do zipdecrypt ac5d37ee b7c718ab 3bc7973b "$f" "$f.recovered"; done
Decrypting Users//duck/Desktop/letterlegal5.doc.crypt (02e59dba51ca8cd8daa8c8f3)... OK!
Decrypting Users//duck/Desktop/lorem_document_PDF.pdf.crypt (01c51007238cccd0d7ac6d86)... OK!
Decrypting Users//duck/Desktop/shattered-1200.jpg.crypt (4891b0abcdda0c17614c5804)... OK!
Decrypting Users//duck/Desktop/wt-tmpdkhvbs-500.png.crypt (ec5f2177ef15d77e5aee108f)... OK!
Decrypting Users//duck/Desktop/YankeeHotelFoxtrot.mp3.crypt (d350f0eb554eeec6d1322382)... OK!
Decrypting Users//duck/Documents/.localized.crypt (108efd41d240b1005e7281c6)... OK!
Decrypting Users//duck/Documents/2003-example-spreadsheet.xls.crypt (f0f93d9533d8f6c660c2a2cd)... OK!
Decrypting Users//duck/Documents/2014_04_a4_format.doc.crypt (3ba2cc77598e2536e2a28208)... OK!
Decrypting Users//duck/Documents/Document-English.docx.crypt (f2e63ab43578659571be7b02)... OK!
Decrypting Users//duck/Documents/Large Spreadsheet Sales (Excel).xls.crypt (c9e2ce71ce5e9d4602cdc7a5)... OK!
Decrypting Users//duck/Documents/officialformat.doc.crypt (b125ea6bca507020b8401ac5)... OK!
Decrypting Users//duck/Documents/Thesis-and-Dissertation-Templete.doc.crypt (1c65a78878f3c52dcd5622bc)... OK!
Decrypting Users//duck/Music/Webdriver_Torso.mp3.crypt (139aa20cbb6edcb9c86af6ea)... OK!
Decrypting Users//duck/Music/YankeeHotelFoxtrot.mp3.crypt (3c50baedc1735187809a2591)... OK!
Decrypting Users//duck/Pictures/corplogo.png.crypt (c407e43e418b6e49cbc43e75)... OK!
Decrypting Users//duck/Pictures/shattered-1200.jpg.crypt (3c50baedc1735187809a2591)... OK!
Decrypting Users//duck/Pictures/wt-tmpdkhvbs-500.png.crypt (dee3bd6d201fd31b1ca377a3)... OK!
duck@testmac:~/Temp$

The last step was unzip all the now-decrypted ZIP files, and that was that:

duck@testmac:~/Temp$ for f in *.recovered; do unzip -d / "$f"; done
Archive:  Users/duck/Desktop/letterlegal5.doc.crypt.recovered
 extracting: Users/duck/Desktop/letterlegal5.doc
Archive:  Users/duck/Desktop/lorem_document_PDF.pdf.crypt.recovered
 extracting: Users/duck/Desktop/lorem_document_PDF.pdf
Archive:  Users/duck/Desktop/shattered-1200.jpg.crypt.recovered
 extracting: Users/duck/Desktop/shattered-1200.jpg
Archive:  Users/duck/Desktop/wt-tmpdkhvbs-500.png.crypt.recovered
 extracting: Users/duck/Desktop/wt-tmpdkhvbs-500.png
Archive:  Users/duck/Desktop/YankeeHotelFoxtrot.mp3.crypt.recovered
 extracting: Users/duck/Desktop/YankeeHotelFoxtrot.mp3
Archive:  Users/duck/Documents/.localized.crypt.recovered
 extracting: Users/duck/Documents/.localized
Archive:  Users/duck/Documents/2003-example-spreadsheet.xls.crypt.recovered
 extracting: Users/duck/Documents/2003-example-spreadsheet.xls
Archive:  Users/duck/Documents/2014_04_a4_format.doc.crypt.recovered
 extracting: Users/duck/Documents/2014_04_a4_format.doc
Archive:  Users/duck/Documents/Document-English.docx.crypt.recovered
 extracting: Users/duck/Documents/Document-English.docx
Archive:  Users/duck/Documents/Large Spreadsheet Sales.crypt.recovered
 extracting: Users/duck/Documents/Large Spreadsheet Sales
Archive:  Users/duck/Documents/officialformat.doc.crypt.recovered
 extracting: Users/duck/Documents/officialformat.doc
Archive:  Users/duck/Documents/Thesis-and-Dissertation-Templete.doc.crypt.recovered
 extracting: Users/duck/Documents/Thesis-and-Dissertation-Templete.doc
Archive:  Users/duck/Music/Webdriver_Torso.mp3.crypt.recovered
 extracting: Users/duck/Music/Webdriver_Torso.mp3
Archive:  Users/duck/Music/YankeeHotelFoxtrot.mp3.crypt.recovered
 extracting: Users/duck/Music/YankeeHotelFoxtrot.mp3
Archive:  Users/duck/Pictures/corplogo.png.crypt.recovered
 extracting: Users/duck/Pictures/corplogo.png
Archive:  Users/duck/Pictures/shattered-1200.jpg.crypt.recovered
 extracting: Users/duck/Pictures/shattered-1200.jpg
Archive:  Users/duck/Pictures/wt-tmpdkhvbs-500.png.crypt.recovered
 extracting: Users/duck/Pictures/wt-tmpdkhvbs-500.png
duck@testmac:~/Temp$

The malware zips up the original files with their full paths, so we used unzip -d / for our unzipping command above so that the files would be created relative to the root directory, thus ending up back in the directory tree /Users/duck where they started out. Note that the leading / is left out of the names inside the archive to stop you unzipping them into absolute locations by mistake, where you might overwrite system files unexpectedly. It’s a good idea to verify the filenames in an archive before using -d /, in case there are files such as bin/bash or usr/bin/vi sneakily included in there that would replace core apps on your Mac.

$530 saved in 10 minutes

The whole process took about 10 minutes, including downloading the macOS command line compiler tools from Apple and compiling our own copy of PKCRACK, just to make sure we could do it from scratch.

It would have cost us $530 (BTC 0.45) to “hire” the Filecode criminal to do the same job, assuming he were awake, and competent…

…and trustworthy.

We know what we think of his rating on the last score.

Follow @NakedSecurity
Follow @duckblog

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/Ukz4zbNSTL4/

This week’s great Amazon Web Services (AWS) S3 outage which kiboshed up to 150,000 websites including Netflix, Spotify, Pinterest and Buzzfeed was caused by an engineer mistyping a single command, the company has admitted.

Diving into Amazon’s mea culpa in more detail, it seems the engineer was trying to temporarily take down servers used by the S3 billing sub-system when the command line mishap caused a cascading problem that downed two really critical servers.

The first was used to index metadata for the US-East-1 region that allows customers to issue GET, LIST, PUT, and DELETE requests. The other, which depended on the first working correctly, was the placement subsystem used to provision new storage. Explained Amazon:

Removing a significant portion of the capacity caused each of these systems to require a full restart. While these subsystems were being restarted, S3 was unable to service requests.

To put it mildly. Doubtless, the engineer or engineers must have broken into a cold sweat as Amazon’s Lego of services started to topple over, taking with it the Amazon Elastic Compute Cloud (EC2), the S3 console, Amazon Elastic Block Store (EBS) volumes, the AWS Lambda and even the S3 API.

If this is starting to sound a tad dry, stay with us, because there is an interesting admission buried inside Amazon’s apology that is worthy of a figurative highlighter pen.

S3 subsystems are designed to support the removal or failure of significant capacity with little or no customer impact.

All well and good but Amazon then coughs up the tidbit that the company had never before “completely re-started” the two critical servers inadvertently taken offline this week. Why? In the rush of S3’s “massive growth” apparently there just wasn’t a convenient moment.

One might speculate that if you don’t take servers out of service, the full effects of doing this might not be apparent. Or perhaps they were very apparent but nobody dared touch them. Either way, bringing them back up was more time consuming than expected, from 9:37AM PST to 1:54PM PST if you count all affected services.

Amazon said it will make changes to “refactor parts of the service into smaller cells to reduce blast radius” (translation: stop things going wrong so quickly) but why did Amazon decide to document its cock-up in such gory detail?

Providers have become adept at apologising when things go awry without offering much more. The sands are now shifting. In an age when DDoS, hacking, sabotage and nation states are front of mind in so many disruptions, it’s become reassuring to be told that old-fashioned human error lies behind something big.

Amazon, then, looks a bit less like a faceless, humming warehouse-cum-datacentre and rather more fallible and human, like the rest of us. We also now realise in no uncertain terms that it’s staggeringly important for thousands of businesses customers and the muggle millions who lie beyond them.
Follow @NakedSecurity
Follow @JohnEDunn

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/gjgiZMbfMDc/

Your daily round-up of some of the other stories in the news

Virginia legalises autonomous delivery robots

If you’re out and about on the sidewalks of the state of Virginia, don’t be surprised if you spot delivery robots buzzing about: the state has become the first in the US to allow the devices, so long as they don’t weigh more than 50lb (about 23kg) or travel at more than 10mph (about 16kph).

If these delivery robots look familiar to Naked Security readers, it’s because we’ve featured them before, as they’ve already taken to the streets in London: they’re made by Starship Technologies, which advised the state of Virginia as it prepared the legislation to allow them on to the streets.

Virginia residents will see them on the streets from July 1, but reassuringly, although there won’t be a human in direct line of sight, the bots will be carefully monitored by a remote human.

Clova to join Siri, Alexa and other AI assistants

Siri, Alexa, OK Google, Cortana … just in case you don’t have enough AI assistants in your life, Line, the Japanese messaging app, is joining the fray with Clova, which will initially be coming to smartphones and a smart speaker.

Clova, which apparently is short for “cloud virtual assistant”, will be able to converse in Japanese and Korean. As Line focuses on the Asian markets, Clova won’t be a direct competitor to the AI assistants launched by other providers, but it clearly is a bid to regain some of the ground Line has lost to other platforms recently.

Line said it plans to take Clova off the smartphone and into other devices such as smart earpieces. Takeshi Idezawa, Line chief executive, told the FT this week that “communication and transactions via smartphone displays are expected to decline. There will be a completely new ecosystem and the current messaging platform will shift to the cloud AI platform.”

Uber to apply for California licence after all

Just a couple of months after Uber moved its testing of autonomous cars to Arizona after falling out with regulators in San Francisco, the taxi company has said it will after all apply for the state permit it needs to test self-driving cars in California.

Uber moved to Arizona after refusing to apply for the $150 permit, ending its test of its self-driving Volvos after only a week. The change of mind comes hard on the heels of a blog post from a Susan J Fowler, former Uber engineer who painted a picture of a toxic workplace, alleging sexual harrassment and discrimination.

That was followed by the release of a video showing Uber CEO Travis Kalanick behaving aggressively with an Uber driver. Earlier this week, Kalanick pledged to “get leadership help”, so perhaps this move to regularise its position with California is part of a move to mend fences with its critics.

Catch up with all of today’s stories on Naked Security

Follow @NakedSecurity
Follow @katebevan

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/EAiXhiwKweM/

Major financial firms operating in New York need to comply with tougher cybersecurity rules that came into effect this week.

The regulation [PDF] by the New York State Department of Financial Services (DFS) covers issues ranging from the maintenance of written policies, testing, governance and auditing, to detection, defence and incident response measures. Banking, insurance or financial services firms licensed to operate in New York must comply. The rules came into effect on 1 March but there is a 180-day grace period before any enforcement actions will be considered.

Tim Erlin, director and risk strategist at security tools firm Tripwire, comments: “The new NY DFS regulation has the same challenges that all cybersecurity regulations face: how to provide prescriptive requirements that are technology agnostic. The DFS regulation addresses the challenge of keeping up with the changing threat landscape by tying the details to a prescribed risk assessment.”

The DFS regulation intentionally avoids requiring many specific controls, but do include the requirement for annual penetration tests and bi-annual vulnerability assessments.

Erlin argued that more frequent risk assessments would be preferable. “It’s well accepted that infrequent vulnerability assessments aren’t enough, and it would be very surprising for any risk assessment to conclude that a biannual vulnerability assessment would be sufficient to protect a business,” he said.

Law firm Pinsent Masons explains what financial firms should expect here. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/03/03/ny_financial_service_cybersecurity_rules/

US Vice President Mike Pence has been accused of hypocrisy after it was revealed he used his personal AOL account for state government business.

That Pence had a personal AOL account was public knowledge – rather embarrassingly, it was hacked last year and the intruder sent out emails to his contacts saying he had been mugged in the Philippines and needed money. Now emails obtained under a Freedom of Information Act request by the Indianapolis Star on Thursday show the AOL account was used for sensitive Indiana state government business.

The 29 pages of messages show discussions between Pence – the then-Indianapolis governor – and his staff concerning terrorist arrests, security details about the governor’s mansion, and terror attacks in Canada. Some emails were withheld by Indiana’s latest governor Eric Holcomb on the grounds that they were confidential.

“Similar to previous governors, during his time as Governor of Indiana, Mike Pence maintained a state email account and a personal email account,” a spokesman for Pence told the paper.

“As Governor, Mr Pence fully complied with Indiana law regarding email use and retention. Government emails involving his state and personal accounts are being archived by the state consistent with Indiana law, and are being managed according to Indiana’s Access to Public Records Act.”

Then again it has to be somewhat embarrassing for Pence, who, like his new boss Donald Trump, spent much of the US Presidential election campaign excoriating Hillary Clinton for misusing a private email server for work while Secretary of State under President Obama.

Admittedly, you can’t directly compare Pence’s email setup to Clinton’s system, but that doesn’t stop this tweet last year from looking rather awkward:

.@realDonaldTrump and I commend the FBI for reopening an investigation into Clinton’s personal email server because no one is above the law.

— Mike Pence (@mike_pence) October 28, 2016

Pence’s spokesman Marc Lotter said any comparison between Clinton and Pence’s use of email was “absurd,” stressing that Big Mike didn’t handle federally classified material as a governor.

Essentially, it was not illegal for Pence to use his personal email for work in Indiana, although he ought to have CC’d his official account when discussing state business – and he doesn’t appear to have done so, judging from the released messages. Clinton was not outright banned from using a private system. However, she was required to maintain an easily accessible archive of her work messages for transparency and Freedom of Information Act purposes. If she used her state.gov address for all correspondence, it could have been archived by her department’s IT, rather than a close circle of aides with fingers hovering over the delete button.

Pence said he didn’t handle any classified material, although some of his emails were not disclosed to the Star because “the state considers them confidential and too sensitive to release to the public.” That’s troubling.

Meanwhile, Clinton said she did not knowingly exchange classified info via her private inbox. However, the FBI concluded she had been “extremely careless” with protected government material, after agents found a handful of messages marked “confidential” scattered through discussion threads. Clinton was investigated but no prosecution was brought; Pence is not, as yet, being probed at all.

Finally, it was feared Clinton’s server would be hacked and ransacked for classified and other juicy information by foreign spies. There is no evidence that happened. On the other hand, Pence’s inbox was actually broken into.

In short, as far as Pence’s critics are concerned, the use of a private email account by the then-governor for sensitive state business – an account that was actually compromised – smacks of hypocrisy.

“There is an issue of double standard here,” said Gerry Lanosga, a professor at Indiana University and past president of the Indiana Coalition for Open Government. “He has been far from forthcoming about his own private email account on which it’s clear he has conducted state business. So there is a disconnect there that cannot be avoided.” ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/03/03/pence_private_email/

These five tips for protecting consumer privacy will ensure that your customers will stay customers for the long run.

Consumer privacy is gearing up to make a big splash this year as people become increasingly annoyed with the way big data thefts at companies like Yahoo! are handled and regulators in Europe take aim at data sharing practices. The heightened scrutiny means companies around the world will have to shore up their security. They must be more responsible about their customer data use and sharing or they could risk damaging consumer trust, losing business, and even getting fined.

The drumbeat of data breaches and privacy snafus has been growing for years, and along with it the level of public discontent, and even outrage. People weren’t happy after Yahoo! announced last September that 500 million accounts were affected in a breach that happened in 2014. That backlash turned into a flood after the company reported in December that an even earlier breach, from 2013, had compromised one billion accounts — the largest data theft in history. It’s impossible to quantify, but the news about Yahoo! users cancelling accounts reached a fever pitch. We saw something similar when Spotify changed its privacy policy in August 2015 to allow for access to customer contacts, photos and GPS locations and share some data with advertisers.

Today, customers are more concerned than ever about what online companies are doing with their personal data, whether it’s sharing it with a third party or improperly securing it. A global November 2016 KPMG survey found that 55% of respondents had at one point decided against buying online due to privacy concerns and fewer than 10 percent feel they have control over the way organizations handle and use their personal data. The top concerns were: unwanted marketing (59%), personally identifiable information (PII) sold to third parties (58%) and lack of secure systems (55%).

Against this backdrop, the European Commission is getting ready to strengthen consumer privacy regulations, and cover international personal data transfers, with the goal of reinforcing trust and security in the digital economy. The impact of these rulings and others including the General Data Protection Regulation (GDPR) extend beyond Europe because non-EU companies who deal with EU consumer data will have to meet these rules going forward, which will mean some serious soul searching for many online companies in the U.S. and elsewhere.

Regardless of the regulatory environment, companies should strive to maintain customer trust as a matter of course. Here are some tips for protecting consumer privacy and ensuring that customers stay customers for the long run.

• Be transparent. Set the tone with customers early and be clear about your privacy policies and practices. Explain how you plan to share their data and provide a way for customers to easily set and change their privacy preferences. Present your privacy information using plain language and make sure it is easy to find on the website and in emails to customers.
• Go beyond the regulations. A lot of companies will have privacy policies that adhere to regulations but don’t have strict data policies that satisfy customer needs. While regulations are evolving and becoming more stringent, there is plenty of room to define and implement policies that protect data across a wider range of potential threats and scenarios.
• Put users in control. Today’s regulations require fine-grain data governance, while progressive policies will help in adapting to tomorrow’s regulations. Collecting customers’ digital identities and affiliated data requires robust and granular data management technologies and practices. It will only work if users can easily view and change their preferences about what types of information they want a company to have and what to keep private. Empowering users with opt in or out choices and administrator visibility into these preferences will help ensure they are being enforced.
• Be careful with third parties. Companies are increasingly sharing data with third parties including advertisers, service providers or partners who provide adjunct services and products. Have data access policies in place that limit what can be shared according to criteria like vendor type, job function, geography and demographics as well as customer choices. For instance, if you’re sharing your database with a marketing firm that’s doing an email campaign, make sure they can’t access customer financial data and block access to the email addresses of customers who have opted out of emails. Some of the largest data breaches have been due to vulnerabilities in the partner ecosystem. Strong policies provide an extra layer of defense in the event of a breach or errors that violate privacy.
• Use security best practices. Privacy and security go hand and hand; employing the strongest possible security methods is crucial. Don’t just encrypt at the endpoints, encrypt data end-to-end, where it’s stored, while it’s in transit and when it reaches its end-use point. LinkedIn learned this the hard way last year after attackers were able to steal and fairly easily decrypt data from 100 million members. Also apply security controls directly to the data so they’re enforced when data travels beyond your firewall in our distributed digital world of apps, channels and connected devices.

Everyone suffers when companies fail consumers by mishandling their data. That’s why the EU is moving even further in that direction. Trust can be difficult to gain but easy to lose. Without it, the very underpinnings of the internet and the future of online activity are threatened. Companies need to make customer privacy a priority, or risk losing those customers.

Related Content:

• EU’s General Data Protection Regulation Is Law: Now What?
• National Security, Regulation, Identity Top Themes At Cloud Security Summit
• Why Identity Has Become A Top Concern For CSOs

 

Steve joined Ping by way of the UnboundID acquisition, where he served as CEO and co-founder leading the company’s business strategy, vision and execution. At Ping, as chief product officer, he’ll continue and broaden that strategic and visionary direction. Steve previously … View Full Bio

Article source: http://www.darkreading.com/endpoint/how-to-use-and-share-customer-data-without-damaging-trust/a/d-id/1328314?_mc=RSS_DR_EDT

A new malware sample shows threat actors have begun using DNS TXT record and queries for C2 communications, Cisco Talos says,

Security researchers at Cisco’s Talos intelligence and research group have discovered what they describe as an extremely evasive and uncommon way for threat actors to command and to communicate with a Remote Access Trojan (RAT) on an infected system.

The multi-stage method involves the use of the Domain Name System (DNS) in a manner that makes bidirectional C2 communication between an infected host and a malicious server almost invisible – even to organizations that have implemented controls for restricting outbound DNS.

Talos security researchers discovered the new threat while studying a malware sample that had been uploaded to a public sandbox designed for malware analysis. Their analysis revealed the malware was designed to infect targeted systems via the use of phishing emails containing a malicious Word document.

The Word document was designed to appear associated with an email service secured by McAfee, and urged recipients to enable macros. Executing the macro initiated a multi-stage infection process involving the use of Powershell. Like many other emerging malware products, this one too, was designed to execute in memory and without requiring malicious code to be written to the file system of the infected system.

What made the malware different, however, was its use of DNS TXT record queries and responses for creating a command and control channel.

“DNS TXT records are records that are normally used by DNS to transfer text-based information,” says Edmund Brumaghin, a Talos threat researcher. Such records are commonly used for email authentication functions such as DomainKeys Identified Mail (DKIM), Sender Policy Framework (SPF), and Domain Message Authentication Reporting Conformance (DMARC).

“Using this mechanism for C2 allows the malware to bypass many of the security controls normally deployed to protect enterprise networks,” he says.

Clients infected with the malware will still be able to reach their C2 infrastructure using the normal DNS lookup process, even in situations where an organization might have blocked outbound DNS for all but approved DNS servers.

“Many organizations inspect the contents of Web traffic, email, etc., but do not actively inspect the content of DNS requests,” Brumaghin says.

Since the infection process itself is initiated through a macro-based Powershell command, one way for an organization to mitigate this particular threat is to block the execution of macros. The DNS requests and responses associated with the C2 traffic are also different from normal DNS communication. So DNS inspection can allow for quick detection and response when a host is infected, he says.

The bigger takeaway for organizations is that adversaries are constantly looking for new ways around whatever security controls organizations might put in front of them, Brumaghin says.  

In this case, instead of using the usual protocols for establishing bi-directional command and communications traffic, the malware authors devised a completely new, multi-stage infrastructure that leveraged DNS through TXT records. “They are relying on the fact that many organizations invest in inspection of web, email, and other traffic on their networks, but may not be inspecting DNS with the same level of scrutiny.”

Cisco Talos has posted an alert with full technical details on the threat and Indicators of Compromise (IOC) that can be used to identify the attack.

Related stories:

• Wekby ‘Pisloader’ Abuses DNS
• 8 Valuable Security Certifications For 2017
• Paul Vixie On DNS Security Botnet Takedowns
• DNSSEC: Why Do We Need It?

 

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year … View Full Bio

Article source: http://www.darkreading.com/attacks-breaches/attackers-employ-sneaky-new-method-to-control-trojans/d/d-id/1328320?_mc=RSS_DR_EDT