There is a new adobe flash player vulnerability found by Trend Micro. Here is what you need to know:
- Adobe told they would publish the fix next week. However they did faster job and published the fix yesterday.
- The attacks seem to be targeted attacks against to government entities. However once exploit becomes available to larger audience then I would expect they would start attacking regular users too.
- Mac, Linux, Windows are all affected by this vulnerability.
- You can download the latest adobe flash player here: https://helpx.adobe.com/security/products/flash-player/apsb15-27.html
If your company cannot update its flash player for some reason I would encourage them to block e-mails with following subject lines:
“Suicide car bomb targets NATO troop convoy Kabul”
“Syrian troops make gains as Putin defends air strikes”
“Israel launches airstrikes on targets in Gaza”
“Russia warns of response to reported US nuke buildup in Turkey, Europe”
“US military reports 75 US-trained rebels return Syria”
There is no doubt that the most popular post I have written so far is How FF store your passwords? Is it secure? I believe the reason is there was not enough documentation 3 years ago about Firefox’s security mechanisms. At that time I couldn’t find something simple that can read/edit sqlite databases. Now I am going to write about SQLite Database browser; a freeware, public domain, open source visual tool used to create, design and edit database files compatible with SQLite.
You can go here and download it. After you download it, go to your firefox profile directory. How can you find it? Just open a new page and type about:support You will see the path of the directory next to the Profile Folder.
There are very good information stored in the profile folder such as bookmarks, passwords, search engine data etc…
You can now open SQLite Database Browser and click the directory icon in upper left and browse the file you want to open in the profile directory. Now you can have some fun with the ff databases and get more information about how ff store information.
Google has been warning Web surfers about sites that appear to be hosting malware in search results for years. Now, the company is adding a warning in search results when the site appears to be compromised but may not be actually downloading malware to visitors’ computers.
Starting today, Google search users should start seeing a new hyperlink warning that says “This site may be compromised,” adjacent to some results if Google’s system has detected something on the site that would indicate that it has been hacked or otherwise compromised. Clicking on the warning link leads to a Help Center article with more information.
“If a site has been hacked, it typically means that a third party has taken control of the site without the owner’s permission,” the article says. “Hackers may change the content of a page, add new links on a page, or add new pages to the site. The intent can include phishing (tricking users into sharing personal and credit card information) or spamming (violating search engine quality guidelines to rank pages more highly than they should rank).” Web surfers can also just click on the result to go directly to the site.
Google first started putting warnings next to results in late 2006, but focused on sites that were hosting or actively serving malware. Those warnings say “This site may harm your computer,” and clicking on the result itself takes you to another page that provides more information.
The new warning is designed to focus on Web sites that may not be actively infecting computers, but that may be compromised and conducting other types of attacks, such as spam or phishing.
Along with warning Web searchers, Google tries to notify Web masters when they detect that their site may be compromised via messages in the Google Webmaster tools console, Google said.
“Of course, we also understand that Webmasters may be concerned that these notices are impacting their traffic from search,” Google says in a post on the Webmaster Central blog today. “Rest assured, once the problem has been fixed, the warning label will be automatically removed from our search results, usually in a matter of days. You can also request a review of your site to accelerate removal of the notice.”
Originally posted at InSecurity Complex
Security Policy and Compliance
- Ignore regulatory compliance requirements.
- Assume the users will read the security policy because you’ve asked them to.
- Use security templates without customizing them.
- Jump into a full-blown adoption of frameworks such as ISO 27001/27002 before you’re ready.
- Create security policies you cannot enforce.
- Enforce policies that are not properly approved.
- Blindly follow compliance requirements without creating overall security architecture.
- Create a security policy just to mark a checkbox.
- Pay someone to write your security policy without any knowledge of your business or processes.
- Translate policies in a multi-language environment without consistent meaning across the languages.
- Make sure none of the employees finds the policies.
- Assume that if the policies worked for you last year, they’ll be valid for the next year.
- Assume that being compliant means you’re secure.
- Assume that policies don’t apply to executives.
- Hide from the auditors.
- Deploy a security product out of the box without tuning it.
- Tune the IDS to be too noisy, or too quiet.
- Buy security products without considering the maintenance and implementation costs.
- Rely on anti-virus and firewall products without having additional controls.
- Run regular vulnerability scans, but don’t follow through on the results.
- Let your anti-virus, IDS, and other security tools run on “auto-pilot.”
- Employ multiple security technologies without understanding how each of them contributes.
- Focus on widgets, while omitting to consider the importance of maintaining accountability.
- Buy expensive product when a simple and cheap fix may address 80% of the problem.
- Attempt to apply the same security rigor to all IT assets, regardless of their risk profiles.
- Make someone responsible for managing risk, but don’t give the person any power to make decisions.
- Ignore the big picture while focusing on quantitative risk analysis.
- Assume you don’t have to worry about security, because your company is too small or insignificant.
- Assume you’re secure because you haven’t been compromised recently.
- Be paranoid without considering the value of the asset or its exposure factor.
- Classify all data assets as “top secret.”
- Don’t review system, application, and security logs.
- Expect end-users to forgo convenience in place of security.
- Lock down the infrastructure so tightly, that getting work done becomes very difficult.
- Say “no” whenever asked to approve a request.
- Impose security requirements without providing the necessary tools and training.
- Focus on preventative mechanisms while ignoring detective controls.
- Have no DMZ for Internet-accessible servers.
- Assume your patch management process is working, without checking on it.
- Delete logs because they get too big to read.
- Expect SSL to address all security problems with your web application.
- Ban the use of external USB drives while not restricting outbound access to the Internet.
- Act superior to your counterparts on the network, system admin, and development teams.
- Stop learning about technologies and attacks.
- Adopt hot new IT or security technologies before they have had a chance to mature.
- Hire somebody just because he or she has a lot of certifications.
- Don’t apprise your manager of the security problems your efforts have avoided.
- Don’t cross-train the IT and security staff.
- Require your users to change passwords too frequently.
- Expect your users to remember passwords without writing them down.
- Impose overly-onerous password selection requirements.
- Use the same password on systems that differ in risk exposure or data criticality.
- Impose password requirements without considering the ease with which a password could be reset.
Thanks for Lenny Zelster for its awesome cheat sheet. For original document please see http://zeltser.com/security-management/suck-at-security-cheat-sheet.html. If you have any suggestions other than the ones at above, let me know! email@example.com
I recently checked the browser statistic for realinfosec.com and wanted to share result with you:
Not: This statistic is for last 500 visitors but I see almost same result for all visitors.
In general arorund %75 of people use IE. However if you look at the statistics you see almost half of the visitors are using FF. More interestingly you see they use the latest version of FF in this case 3.6 so they are security dudes in action too:)
Chrome won the second place. Sorry IE but you are not good for security dudes… I think chrome will be at the top in next year if they add some additional feature on it by keeping its speed.
Finally we have IE users. They are around %10. The good thing is that they use the latest version of it (8.0)
To sum up, security dudes who visit this site are really taking security seriously. I love that! Using secure browser like FF and keep it updated show that fact.
I covered how/where Firefox store saved passwords on the previous blog post. Today, I will mention how to hack them.
As discussed previously, Firefox uses TripleDES as its encryption algorithm. If master password is not set, we can crack the password with any 64 base decoder since there won’t be encryption.
If master password is used, user needs to attack key3.db with a password cracker such as FirePassword to recover master password.
Master password is not stored on the key3.db. Firefox stores encrypted data associated with known string.
Say the known string is realinfosec. If user enter correct master password, he can decrypt the encrypted data as realinfosec. BOOM!
Known string and decrypted one matched! Firefox now knows that user entered correct master password, so it will decrypt all the saved passwords.
The way Firemaster works is same.
- First, Firemaster generates password by using bruteforce, hybrid and dictionary attacks.
- After that, it computes hash of master password.
- Firepassword uses this hash to decrypt encrypted data.
- If the decrypted data matches with the string (i.e realinfosec), it means FireMaster gets the password!
After having master password, you can decrypt saved passwords via FirePassword.
Currently, Firepassword can only decrypt saved passwords on Sigons.txt files not the ones on the signons.sqlite
Nagareshwar Talekar, creator of these two nice tools, informed me that he will try to update FirePassword, then it may crack saved passwords stored on the signons.sqlite.
1-) If you forget your master password, you can get it back via FireMaster.
2-) Strength of encryption is depend on the strength of the Master Password you choose
3-)Nothing is impossible, you can recover your Firefox password. However, this means that hackers can crack them as well… Don’t forget; they only need to have key3.db and sigons files (txt and sqlite) to do that. You need to be sure that physical security and network security for your machine are OK.
I wanted to know more about how Firefox hold saved password when I was backing up my machine (http://realinfosec.blogspot.com/2009/08/backup-files-on-vista.html)
There are some online tools for this purpose. The most well known one is Xmarks ( previously foxmarks). I don’t want to use it since I was not sure how secure their server.
They provide using your ftp server as an option. However, as you know ftp itself is not a secure protocol. So I started to dig about the way Firefox use to store password.
After some research, here is what I found: Firefox stores passwords in two different files:
key3.db: This file stores your key database for your passwords. To transfer saved passwords, you must copy this file along with the following file.
signons.sqlite: This file stores saved passwords. ( Google’s Android OS for cellphones and other small devices includes SQLite.)
Both of these two files are located on the Firefox profile directory.
Linux –> ~/.mozilla/firefox/<profile folder>
Windows Vista/XP/2000 –> %APPDATA%\Mozilla\Firefox\Profiles\xxxxxxxx.default\
Windows 98/Me –> C:\WINDOWS\Application Data\Mozilla\Firefox\Profiles\xxxxxxxx.default\
Mac –> ~/Library/Mozilla/Firefox/Profiles/<profile folder>
~/Library/Application Support/Firefox/Profiles/<profile folder>
If you upgrade your Firefox from a previous versions you will see some thing like signons3.txt. In this case firefox stores password in a text file (yes, you read it right!).
This was one of the weakest part of firefox passwords. Before SQLite, firefox kept password in a text file. The file name was signons.txt before Firefox 1..5. signons.txt did not only store passwords but also stored a list of sites which password are never saved.
After FF team found a bug ( I strongly suggest to read about this interesting myspace bug! ) they started to use signons2.txt. With Firefox 3.0, this file is replaced by signons3.txt. And now we have signons.sqlite. That was the evolution of password file.
Now let’s look at how Firefox encrypt saved passwords.
There are basically two cases:
1-) Master password is not set: Are you kidding? I hope you will set it right away after read next sentence. If master password is not set, Firefox stores passwords in Base 64 encoding! –
2-) Master password is set: In this case, all saved passwords are encrypted by using the master password and stored on signons.txt and signons.sqlite
You may want to know what encryption algoritm Firefox uses. It is TripleDES (CBC mode). If you want to use more secure encryption method you can use Federal Information Processing Standard (FIPS) 140:
Tools-> Options-> Advanced-> Encryption-> Security Devices-> Software Security Devices->NSS Internal PKCS #11 Module -> Enable FIPS
Then, disable all the non-FIPS TLS cipher suites in about:config
For more info check here.
How to Choose a Strong Master Password
Master key for the encryption algorithm are made from salt which is stored on key3.db and Master Password. This key is used to decrypt saved passwords.
This means, security of saved password is directly related to strength of master password. To choose a strong master password, consider followings:
1-) It should be easy to remember for YOU and hard to guess for OTHERS.
2-) Mozilla (and most other companies such as Microsoft) suggest using at least 8 character with upper case, lower case, number and a special symbol like #, $ % etc,
However, do you think this will fulfill the first part of the first requirement? In other words this alpha numeric + special character password will be easy remember?
If you think you have really good memory then you can set your master password in this way. However, you should remember that master password is not easily recoverable. ( I will write another blog post how to recover, hack, your master password) You can reset it but this will remove all of the saved password from database.
3-) You can have a sentence or phrase which you can remember easily:
In this way you won’t have hard time to remember the password and it won’t be cracked easily (Almost impossible)
1- ) If you want ff save your password, then use master password to protect them.
2- )If you want to transfer your saved password on firefox, then copy singonsN.txt, signons.sqlite and key3.db to your Firefox profile directory.
Another blog post will be made to explain how to hack/recover Firefox password.
Update: I made a blog post about SQLite Database Browser. You can use SQLite db browser to learn more about fields in firefox databases.