A secure version of user.js to harden Firefox installations

December 21, 2014 – 11:36 AM

Warning: Backup your existing user.js file (if it exists) and use with caution.  Some website functionality may break.

Some of the settings in this user.js file might seem redundant, as some of them are already set to the same values by default. However, the user.js file has this nice property, that even if you go change any of these settings through about:config, they’re reset to the user.js defined values after you restart Firefox. So user.js makes sure they’re back at the secure default values always when you start your browser. That way, it also makes experimenting with different settings easier.

Some of the custom settings:

  • Permanently enables the Private Browsing Mode
  • Disables features such as domain guessing, search suggestions, geolocation, telemetry, crash reporting, prefetching, etc.
  • Forces DNT (Do Not Track) headers
  • Disables the referer header
  • Prevents revealing of internal IP addresses
  • Hardens the cipher suites and protocols
  • Forces OCSP

It comes with a shell script to modify your CA list but this will not work in Windows obviously.  Windows users should be able to use the user.js without the CA modifications, or you can modify them manually.

To use, just copy the user.js file to the root of your Firefox profile (e.g. ~/.mozilla/firefox/XXXXXXXX.your_profile_name in Linux) and restart Firefox.

Download:
https://github.com/pyllyukko/user.js

How to tell if a shortened link is secure in 2015

December 21, 2014 – 10:36 AM

If you hang out a lot on social media sites such as Twitter or Facebook, you have encountered countless links that were shortened.

What is meant by that is that proxy links tend to get posted on these sites that do nothing but redirect you to the real site when you click on them.

While that may make sense on Twitter with its artificial 140 character limit, it is a dangerous habit that has no real advantage other than reducing the number of characters displayed on the screen.

The danger lies in the fact that you don’t know where a link leads you. A link like http://bit.ly/1pHtsqW reveals nothing about its destination and with that comes the danger that you get tricked into loading dangerous sites on the Intern.

Maybe you get redirected to a phishing website, a drive by download page, or a site that tries to attack you or your computer in other ways.

Source:
http://www.ghacks.net/2014/12/21/how-to-tell-if-a-shortened-link-is-secure-in-2015/

Staples confirms security breach resulting in over 1 million stolen credit and debit cards

December 19, 2014 – 9:57 PM

Nearly a year ago, Target suffered one of the largest security breaches that resulted in over 70 million credit and debit cards being compromised. At the time, Target wasn’t alone, with other retailers suffering the same fate during the crucial holiday season. Nearly a year later, Staples has also become the victim of a data breach, occurring over the past six months, resulting in over 1 million credit and debit cards being potentially compromised.

Staples has released a statement on the matter, releasing a list to the public that shows which stores were affected and on what dates the attacks occurred. Additionally, Staples is also offering free identity protection services for those affected. The service will monitor your credit, provide identity theft insurance, and a free credit report. The offer can only be redeemed by those who used a credit or debit card during the dates listed and at the specified stores.

While merchant breaches seem to have become more common in the past few years, companies are scrambling to find secure alternatives to simply swiping credit and debit cards. Although Apple has attempted to change the landscape with Apple Pay, some merchants have been resistant, creating their own standard for an alternative payment system. Both have yet to make an impact and be accepted by the a majority of the public.

Source:
http://www.neowin.net/news/staples-confirms-security-breach-resulting-in-over-1-million-stolen-credit-and-debit-cards

 

Ars was briefly hacked yesterday; here’s what we know

December 18, 2014 – 5:24 PM

At 20:00 CT on December 14, an Internet intruder gained access to one of the Ars Web servers and spent the next hour attempting to get from the Web server to a more central machine. At 20:52, the attempt was successful thanks to information gleaned from a poorly located backup file. The next day, at 14:13, the hacker returned to the central server and replaced the main Ars webpage with a defacement page that streamed a song from the band Dual Core. That song, “All the Things,” features the chorus:

Drink all the booze,
hack all the things!

The hacker didn’t have long to drink all the booze and hack all the things, fortunately; by 14:29, our technical team had removed the defaced page and restored normal Ars operations. We spent the afternoon changing all internal passwords and certificates and hardening server security even further.

Log files show the hacker’s movements through our servers and suggest that he or she had the opportunity to copy the user database. This database contains no payment information on Ars subscribers, but it does contain user e-mail addresses and passwords. Those passwords, however, are stored in hashed form (using 2,048 iterations of the MD5 algorithm and salted with a random series of characters).

Out of an excess of caution, we strongly encourage all Ars readers—especially any who have reused their Ars passwords on other, more sensitive sites—to change their passwords today.

We are continuing with a full autopsy of the hack and will provide updates if anything new comes to light. Thanks to everyone who offered their support!

Source:
http://arstechnica.com/staff/2014/12/ars-was-briefly-hacked-yesterday-heres-what-we-know/

Your Browser is (not) Locked

December 17, 2014 – 7:35 PM

Most ransomware has a binary file that needs to be executed before it can infect your PC. Ransomware usually relies on social engineering or exploits to infect unsuspecting users. However, some malware authors are bypassing this requirement with a new trick – browser lockers.

Unlike traditional ransomware threats that lock the entire desktop, browser lockers only lock the web browser of an infected PC. Most other malware needs a user (or other malware) to manually run it. Browser lockers don’t need to be manually run, they don’t have a binary file and they are mostly written in JavaScript. The script runs in the web browser and its main purpose is to disable any form of action that can close the browser – such as clicking the close button and pressing certain shortcut keys (for example, Alt + F4). All attempts to close the browser will result in a warning message box, an example is shown in Figure 4.

Microsoft detects browser locker malware as Ransom:JS/Brolo and Ransom:JS/Krypterade.

Source:
http://blogs.technet.com/b/mmpc/archive/2014/12/17/your-browser-is-not-locked.aspx