Recently, Truecrypt webpage (www.truecrypt.org) was shown to be compromised. It comes along with a version 7.2 of Truecrypt that looks suspicious. Do NOT download any Truecrypt software from that website from the website from now and DO NOT switch to Bitlocker before a confirmation of what is going on has been thoroughly investigated.
If you are using version 7.1a and older of Truecrypt, you are most likely to be fine for now.
I will see what I can do to provide people following my blog or those who are interested with a replacement.
If you have further doubts of Truecrypt, please migrate to LUKS (https://code.google.com/p/cryptsetup).
Remember, DO NOT TRANSFER FILES UNENCRYPTED ! Even a Truecrypt container (version 7.1a and older) used to move secrets is much better than nothing.
Showing posts with label compromised secure systems. Show all posts
Showing posts with label compromised secure systems. Show all posts
Wednesday, May 28, 2014
Thursday, April 17, 2014
Kill switch your smartphone
Read:
Once you have given someone the access to remotely send commands to your own system, you have effectively lost control over your system. That is the basis of computer security: which is to secure your system and prevent yourself from losing control.
For the economical, social and political side of matters, who truely owns the smart device ? Is the person who bought and signed the contract for the smart device the true owner of the device ? Are there political motivations for inserting political and governmental backdoors via the remote kill switch ? Are the service providers and software providers trying to gather more user data some mechanism in the remote kill switch for their own benefits ? There are much more to consider than the outright "benefit" of simply remote wiping your smart devices if it lands in the wrong hands.
Who would know if some malicious employees or someone within the the company or organization whom you have given remote wipe command access to might not intentionally or accidentally wipe your smart device or use the security loophole(s) of the remote kill switch to remote control your smart device ?
An alternative to using a blackbox style remote kill switch which you have no access or control over the source codes and mechanisms is to look for open source alternatives which you can review the source codes to ensure that there are no backdoors in the remote kill switch and the mechanisms in place to transfer the command to remotely kill a device is sent our via secure and conscious means. The problem with such an open source implementation is not everyone knows about computer security and how to evaluate codes to ensure that the codes and kill switch mechanics are safe. People are likely to simply purchase or subscribe to a kill switch without proper inspection and trust it which can be detrimental to one's own privacy and security.
In essence, deliberately introducing a loophole (remote kill switches are considered a deliberate loophole in CS field) into a system degrades it's overall security regardless of the intention or purpose.
Here are a few tips to secure your smart devices:
Kill switches are originally intended for use as a remote method of wiping data off a smart device remotely. But history has shown that if you have a kill switch installed, if discovered by hostile parties can be used against you. If an attacker manages to find a way to send the correct command to activate the kill switch, it might disrupt or even endanger whomever owns this kill switch (imagine if you were to plant a remote kill switch into smart devices and these smart devices have some sort of link to life support systems for health patients, that would be really dangerous).
Remote wiping implementations are not so straightforward in it's designs and implementations. One have to consider the fields of economics, politics, social behaviours and most importantly, the technical side of computer security.
Relating to the technical side of computer security, some remote wipe providers may offer some form of strong symmetric key or PKI infrastructure to encrypt the communication between your smart phone and the remote command tool to send the kill signal, but what is going to protect these encryption keys or passwords from falling into the wrong hands ?
Remote wiping implementations are not so straightforward in it's designs and implementations. One have to consider the fields of economics, politics, social behaviours and most importantly, the technical side of computer security.
Relating to the technical side of computer security, some remote wipe providers may offer some form of strong symmetric key or PKI infrastructure to encrypt the communication between your smart phone and the remote command tool to send the kill signal, but what is going to protect these encryption keys or passwords from falling into the wrong hands ?
Once you have given someone the access to remotely send commands to your own system, you have effectively lost control over your system. That is the basis of computer security: which is to secure your system and prevent yourself from losing control.
For the economical, social and political side of matters, who truely owns the smart device ? Is the person who bought and signed the contract for the smart device the true owner of the device ? Are there political motivations for inserting political and governmental backdoors via the remote kill switch ? Are the service providers and software providers trying to gather more user data some mechanism in the remote kill switch for their own benefits ? There are much more to consider than the outright "benefit" of simply remote wiping your smart devices if it lands in the wrong hands.
Who would know if some malicious employees or someone within the the company or organization whom you have given remote wipe command access to might not intentionally or accidentally wipe your smart device or use the security loophole(s) of the remote kill switch to remote control your smart device ?
An alternative to using a blackbox style remote kill switch which you have no access or control over the source codes and mechanisms is to look for open source alternatives which you can review the source codes to ensure that there are no backdoors in the remote kill switch and the mechanisms in place to transfer the command to remotely kill a device is sent our via secure and conscious means. The problem with such an open source implementation is not everyone knows about computer security and how to evaluate codes to ensure that the codes and kill switch mechanics are safe. People are likely to simply purchase or subscribe to a kill switch without proper inspection and trust it which can be detrimental to one's own privacy and security.
In essence, deliberately introducing a loophole (remote kill switches are considered a deliberate loophole in CS field) into a system degrades it's overall security regardless of the intention or purpose.
Here are a few tips to secure your smart devices:
- Never leave them on the table or chair or leave them unattended even for a few minutes if these devices contain personal data (phone contacts, email, address book, PIN managers, bank transaction applications ... etc).
- Filesystem / Volume encryption.
- Always use a Password Manager with a Master Password and never write them down on paper or Notepad.
- Never share passwords.
Afterall, the best device security is yourself being cautious and aware of the surrounding. Depending on some loophole technology to remote kill your device is the worse idea.
Sunday, August 7, 2011
Doomed for Insecurity
I was attempting to explain the importance of computer security and the use of password managers instead of writing down passwords. I made a password manager called PasswordStore with the aim of simplifying usually complex password managers to become easy to use.
PasswordStore is actually really simple and mostly self sufficient and the setup procedures are near to none except stating your username and password you prefer on the first use.
No matter how I try to convince others the use of NOT WRITING DOWN PASSWORDS ON PAPER AND LEAVE IT IN PLAIN SIGHT, there are always people who would always want to write down their passwords and NOT PROPERLY PROTECT THEIR PASSWORD PAPER.
Besides the password cases, there are always people who are ignorant to security despite warnings. A few of the examples are listed below:
PasswordStore is actually really simple and mostly self sufficient and the setup procedures are near to none except stating your username and password you prefer on the first use.
No matter how I try to convince others the use of NOT WRITING DOWN PASSWORDS ON PAPER AND LEAVE IT IN PLAIN SIGHT, there are always people who would always want to write down their passwords and NOT PROPERLY PROTECT THEIR PASSWORD PAPER.
Besides the password cases, there are always people who are ignorant to security despite warnings. A few of the examples are listed below:
- Leaving computers not locked (lock screen) when going to somewhere else.
- Sharing / lending passwords for sensitive accounts (e.g. emails, web portals ...etc).
- Installing suspicious looking programs despite warnings.
- Willing to leak personal information on social sites.
- Belittle the consequences of their accounts being compromised.
Above are the few scenarios I met of people who are hard-headed in their ways towards computer security. I believe most people bare the same attitude to a good extend. If such attitudes are applied into a larger context (organisations and companies), it would invite attention from hackers. The "ordinary" people who would love to persist in such attitudes of continuing their ignorance to security would also invite troubles from hackers and law enforcement agencies (when the hacker implanted a backdoor into their computers and have "zombied" their computers to attack or help attack someone else).
Such whom are ignorant and continue to be ignorant to security truely deserves the doom and trouble they have asked for by their ignorant attitudes.
Monday, August 1, 2011
Apple Pwnz by 19 Yr Old
Read:
Apple really needs to consider it's "security" via obscurity and who knows what they have installed that only seems secure.
Saturday, July 30, 2011
Zipper Hack
Read:
Well, this is how insecure zippers are. They were not made for security in the first place.
Monday, July 4, 2011
VSFTPD Backdoored
Read:
- http://www.h-online.com/open/news/item/Vsftpd-backdoor-discovered-in-source-code-1272310.html
- http://scarybeastsecurity.blogspot.com/2011/07/alert-vsftpd-download-backdoored.html
This is a very bad security mismanagement on the source code part. How did a backdoor slip into the master branch of the source codes ? No clues were given for now.
The main lesson for the day, always check the GPG signature file. ALWAYS !!!
Friday, July 1, 2011
SecurID and new pseudo security
Read:
Anyone can invent any new methodology or technology to provide protection and security. For SecurID's case, it's the compromised servers that is the root of the issue instead of the SecurID authentication itself. You can create some new authentication or whatever protection mechanism but it relies on a server. All it needs is the server to be compromised yet again to see the same issues re-surfacing.
What RSA and SecurID inventor should do is to really look into securing the backend first as the main issue have always been insecure servers holding really important information in a highly insecure and careless way.
Ensure proper administration, C2 auditing enabled and reviewing of logs , encryption of information on all servers, assignment of rights and roles, seperated domains so that if a small domain of secured data gets compromised, it won't spread the impact across and finally re-evaluate your servers and staff efficiency frequently and conduct frequent penetration testing.
Data encrypted on databases on the backend should usually be done whereby an encryption secret key is responsible for a small small group of data it needs to be secured. So in an event of an attack, a compromised key would not compromise other keys (if the keys are secure de-linked and made unpredictable from one another).
The master key for encryption should be made up of more than 2 person's encryption secret key (bosses holds the secret keys). Imagine it's like a nuclear launch silo where you need many keys to be turned together to launch a nuclear missile. This would give more security. The master keys should be seperated from each other whereby if one key is compromised, it doesn't affect the others and can be regenerated
Last but not least, make sure the roles and administrative privileges are properly administered whereby power is not consolidated in one person's hand.
Tuesday, June 28, 2011
LulzSec Goodness
Read:
I agree that LulzSec's attacks shouldn't be taken into view in a one sided manner. It has the good points of exposing many of the "supposedly security and unbreakable" notions we have. It's a good and much appreciated wake-up call LulzSec have done. Only fools would simply deny it and be afraid of the truth.
Thursday, June 23, 2011
Dropbox Fatal Error
Read:
- http://lifehacker.com/5813861/dropbox-accidentally-unlocked-all-accounts-for-4-hours
- http://blog.dropbox.com/?p=821
The above would cause the following:
- Reduced Confidence
- In Dropbox security management
- In Dropbox service as a whole / Integrity of Service
- Possible Lawsuits Against Dropbox
- Less users
- Opportunity for rivals
Honestly, I have never trusted Dropbox security as a whole. There has been a lot of complains out there and no matter how much Dropbox tries, security on the Cloud is still in it's early stages and there are room for improvements. A lot of room for improvements and also a lot of room for errors. If I want to get something to someone or store something online, I WOULD ALWAYS ENCRYPT MY DATA FIRST and not wait for Dropbox or some service.
What's the use of double layered encryption / protection ? In this context, if the provider is not trusted, you can save yourself a ton of trouble with the encryption / protection you have done on your own. If the provider of service is really that good, then you are extra safe.
Do not think that no one would get at your data. Recent hacks into email servers and consequently leaks of huge chunks of compromised email servers shows us one thing, even within a private environment, there needs to be some sort of safety measure to take into consideration the possibility of compromised servers and machines and consequently leaks. If the data are well protected... truely well protected with really good security done on it, then, the risks of leaking data are far lower.
So how do you protect yourself, use a file encryption program to encrypt the files you want to put onto Dropbox. If you want your files to be portable across different platforms using Dropbox (including mobile platforms), you may want to employ the help of creating an encrypted compressed archive (e.g. AES encrypted ZIP via WinRAR or 7zip) and install some zip program on your mobile platforms which can handle the encrypted compressed archives.
Saturday, June 11, 2011
RSA Shot In The Head
Read:
Seems like RSA's SecurID and systems are compromised and not trusted anymore. A better, more resistant system, needs to be in placed to handle such situations. It took RSA a long time to acknowledge their mistakes.
Subscribe to:
Comments (Atom)
