Archive for the ‘https’ Category
Microsoft’s flawed code signing infrastructure puts your machine at risk, find out how.
A batch of great audience submitted questions, and we share a few IT war stories!
All that and more, on this week’s TechSNAP!
Direct Download Links:
Subscribe via RSS and iTunes:
- The attackers used automated scripts to attempt to determine if phone numbers were linked to AT&T online accounts
- Attempts were made against approximately 1 million of AT&Ts 100 million customers
- The attackers appeared to already have a database of usernames and passwords, and were attempting to use brute force to link those credentials to phone numbers, in order to gain access to the accounts
- AT&T appears to lack any type of Intrusion Detection System, or automated defences that block an IP address after many failed login attempts. The millions of attempts were likely not launched from a single IP address, but it still should have been blocked well before 1 million accounts had attempts against them
- AT&T does not believe attackers were able to gain access to any accounts, but they are still investigating
- The so called Cinderella law blocks users under the age of 16 from accessing online games after midnight
- The articles are unclear about exactly how this is accomplished, but it appears it is enforced by the online gaming sites themselves, and teens using accounts created with their parents identities are not blocked
- In South Korea, most websites require you to enter your national ID card number. Comments on sites cannot be left anonymously (previously covered on TechSNAP 23 )
- Is this a sign of the level of censorship we can look forward to in the future?
- SSL Certificates signed by a few authorities (which have since had their trust revoked) have had their private keys factored
- Once you poses the private key for an SSL certificate, you can use it to pretend to be that site, and use any other capabilities that the certificate has
- It was originally thought that the private keys were merely stolen by malware, but it seems that factoring RSA 512 has become somewhat trivial, taking only a matter of days or weeks with a reasonable cluster of modern machines. With malware authors having access to large botnets, or cloud computing platforms like Amazon EC2, these certificates can no longer be considered safe
- A number of other vulnerable certificates were identified, many coming from DigiNotar, the certificate authority that was compromised by attackers and has since has its trust revoked and gone out of business.
- Most all SSL certificate authorities require at least a 2048bit RSA key for new certificates
- A normal HTTPS SSL certificate only has the ability to sign outbound messages, encipher symmetric keys, and to verify its identity as a TLS Client or Server.
- The problem with the certificates issued by the Digisign Server ID CA, is that they lacked the basic key usage definitions and constraints. This allowed the certificates to be used for any purpose, including signing software. The certificates also lacked a properly defined CRL (Certificate Revocation List), so they could not be revoked.
- The factored certificates were used to code-sign malware to remove or lessen the warnings given by windows when the code is executed
- The compromised certificates have been used as far back as March 2010, and Microsoft did not act until recently, revoking the trust in the CA. Microsoft will still accept 512bit certificates without proper use definition or constraints.
Q: Do you guys trust Internet aggregator services?
A: It depends on the level of security they employ. Most of these sites are not very forthcoming with details on how they secure your data, or even how they work. A better solution would be something like OAuth to allow you to grant only certain permissions to each specific site, and allow you to easily revoke a sites access to your accounts.
Q: SSH on Port 2222?
A: Using a different port does reduce the number of attacks from automated bots, but it will not stop anyone targeting you specifically. The solution is always to use a protection system such as DenyHosts, SSHGuard or Fail2Ban. Also, if it makes sense in your setup, disable password authentication entirely, and only use SSH keys. Note: you should still use DenyHosts to prevent an aggressive botnet from bogging down your SSH server so legitimate users cannot log in. This used to happen to one of my servers that had 250 ip addresses, the bots would attack each ip at the same time, creating 1000 ssh connections at once.
Administering a Windows Server with your eyes closed
When ScaleEngine first started, we were in a much smaller local data center. One of the disadvantages to this data center was that they did not provide KVM Carts, in order to work on a server, you had to remove it from the rack, and take it over to a little desk in the corner with a monitor and keyboard, but no network connection. At our new data center, we have KVM carts we can take over to our rack to work on servers without disconnecting them. If we need to disassemble the server, they provide a nice large quiet work area with ample power, ethernet drops and free coffee.
I had just built two new Windows 2008 R2 servers for one of our clients, and had installed them in the rack. Got them up and running, and they were serving their websites fine. However, I was not able to connect via Remote Desktop. How had I forgotten to enable remote desktop…
I really did not feel like waiting for the server to shutdown (windows servers take an extremely long time to shut down, partly because they overwrite the entire swap file for security reasons), then removing the server from the rack again, waiting for it to boot up, change the settings, shutdown etc.
So, I grabbed our spare USB keyboard and connected it to the server in the rack. Balancing the keyboard on my left hand, while typing with only my right, with no monitor. I waited 30 seconds for windows to detect the keyboard, and then entered control+alt+delete to open the login prompt. I heard the drive start ticking as it loaded the desktop, so I gave it a few minutes. Once I was logged in, windows+r to open the run prompt, and started cmd.exe. Then I issued the following commands which I had arduously looked up on my old cell phones very limited browser.
netsh firewall set service remoteadmin enable
netsh firewall set service remotedesktop enable
netsh firewall add portopening TCP 3389 RDesktop enable any
I issued each command twice, in case I might have made a typo, even though I was typing as carefully as I could, and slowly as I was doing it with one hand on an unsteady keyboard. Then to test it, I used pocketPutty on my cell phone, to SSH into one of my servers, and use netcat to see if port 3389 was open. It was. So I repeated the same procedure on the second windows server and again verified it via my cell phone before packing up and leaving the data center.
And that, is how I administered a pair of windows servers, with my eyes closed.
- DHS and the FBI find no evidence that water pump destruction was caused by SCADA hack, no evidence of intrusion into the network
- Activist Post: Alleged Cyber Attack on U.S. Water Plant is Propaganda to Curb Internet Freedom
- Feds Now Say Hacker Didn’t Destroy Water Pump
- Hacker says he broke into Texas water plant, others
- The list of companies opposing the SOPA bill has grown to include AOL, eBay, Facebook, Google, LinkedIn, Mozilla, Twitter, Yahoo and Zynga
- Facebook Tracking Cookies
- 25 worst passwords of 2011