Information Security News
Australian infosec pros rank own businesses as sitting ducks
Australian infosec pros rank own businesses as sitting ducks. Summary: A survey asking Australian security professionals to rank their security has found that most of them failed themselves on their ability to respond to and protect their own businesses.
Oracle plans to release an update for the widely exploited Java browser plugin. The update fixes 39 critical vulnerabilities and introduces changes designed to make it harder to carry out drive-by attacks on end-user computers.
The update scheduled for Tuesday comes as the security of Java is reaching near-crisis levels. Throughout the past year, a series of attacks hosted on popular websites has been used to surreptitiously install malware on unwitting users' machines. The security flaws have been used to infect employees of Facebook and Apple in targeted attacks intended to penetrate those companies. The vulnerabilities have also been exploited to hijack computers of home and business users. More than once, attackers have exploited one previously undocumented bug within days or weeks of patching a previous "zero-day," as such vulnerabilities are known, creating a string of attacks on the latest version of the widely used plugin.
In all, Java 7 Update 21 will fix at least 42 security bugs, Oracle said in a pre-release announcement. The post went on to say that "39 of those vulnerabilities may be remotely exploitable without authentication, i.e., may be exploited over a network without the need for a username and password." The advisory didn't specify or describe the holes that will be patched. Security Exploration, a Poland-based security company that has discovered dozens of "security issues" in Java, has a running list of them here.
bambenek \at\ gmail /dot/ com
I was recently working at a client, implementing wireless. As in many Enterprise Wireless projects, we needed an Enterprise Certificate Authority (CA). Imagine my surprise, that when we went to create an Enterprise Root CA, that one already existed. And when we went to take a closer look at that Root CA, when we found that the server was retired - dead and gone, I got that sinking feeling and realized we might be on a trip down the project-over-run rabbit hole.
While you can certainly inventory all the certificates issued and active on a Certificate Authority, if the CA is gone there isn't a good way to do that. So while you can easily delete a Root CA from Active Directory, once you delete it, that CA is no longer in the list of Trusted Roots. All the Certificates issued by it will be invalid, and in this case nobody really was sure what that CA was put in to do. So what we needed was an idea of what the impact of deleting that CA might be.
Then I remembered the story I wrote a while back on Microsoft certutil ( https://isc.sans.edu/diary/11962 ). With a bit of playing, I was able to use certutil and psexec ( from Mark R's excellent Sysinternals Utilities) to inventory the "Local Computer" certificate store of every machine in the domain.
Luckily, in this case we only needed to worry about machines in the Active Directory Domain, so this survey got the job done for us.
What we needed to run was a short script like this, on each machine in the domain:
REM ============== getiss.cmd ==============
echo ========================== >> \\utilserver\sharename\certs.txt
hostname >> \\utilserver\sharename\certs.txt
certutil -store my | find "Issuer" >> \\utilserver\sharename\certs.txt
The first 2 lines (the echo and hostname commands) just break up the output, and identify the machine being evaluated in each test. The last line is where all the action is - we're dumping the local certificate store, only looking at the Local Machine store. In this case all we're only interested in is which server issued the certificate, so we're looking for the word "Issuer" in the output. Since we're looking anyway, I'm not going to parse this out further, I'll happily look at *all* the issuers in the domain to see if we've got any other issuer-based certificate problems in our domain.
Now I'll call this little script for every computer in the domain:
psexec \\* -u domainname\adminuser -p adminuserspassword -cf getiss.cmd
Our output looks like:
Issuer: CN=CA01-CA, DC=domain, DC=com
Issuer: CN=SERVERNAME7, L=1720207907, OU=SharePoint, O=Microsoft
Root Certificate: Subject matches Issuer
... and so on.
So what did we find? The old CA hadn't issued any certificates that were currently in play on anything in the domain. We also found a number of self-signed certificates (where the Issuer matched the hostname). So, with this in hand, we can delete that old CA from the Domain and know in our hearts that we're not going to mess up any of the critical services in the organization (Sharepoint or Exchange for instance). Details on doing this, now that the impact has been assessed, can be found at these and many other links on microsoft.com ( http://support.microsoft.com/kb/555151 , http://support.microsoft.com/kb/889250 , http://blogs.technet.com/b/pki/archive/2011/10/07/how-to-decommission-a-windows-enterprise-certification-authority-and-how-to-remove-all-related-objects.aspx )
Scripting saves the day again, in about 10 minutes no less !
If you've had a similar experience, or if you've got a simpler or more elegant scripting approach for this type of problem, by all means use our comment form and share.
Bradford Networks Addresses BYOD Security Threats at InfoSec World 2013
MarketWatch (press release)
ORLANDO, FL, Apr 15, 2013 (Marketwired via COMTEX) -- InfoSec World Expo and Conference, Booth #104 -- Bradford Networks(TM), the best choice to secure network access for BYOD, today announced its participation in the InfoSec World Expo and ...