Joomla is a popular content management system that accounts for almost 3% of all websites on the internet, and it has been downloaded over 84 million times. A static analysis organization called Rips Technologies recently found it to be vulnerable to an LDAP injection vulnerability. This vulnerability was in the Joomla code for over eight years, and the company recently released a patch to remediate the blind LDAP injection.
This type of attack takes place using the login pages of sites that use LDAP for authentication, and it can infiltrate data or applications by abusing entries inserted into the software in an attempt to extract, view or change the data.
An LDAP injection attack, especially a blind one, like what is used in this method, aims to abuse the authentication process of passing credentials to controllers, as an LDAP server stores the username and password of the users in a database. With this particular vulnerability, there's a complete lack of sanitation, enabling an attacker's script to rotate attempts through the login field and slowly extract the credentials of a user -- this is the blind part of the injection, and it is usually aimed at an administrator account to get complete access to the Joomla control panel.
With this vulnerability, an attacker can submit an LDAP injection of query syntax into the login form in an attempt to slowly gain access to the LDAP database one bit request at a time. When the scripted attack runs, it's able to quickly submit multiple login attempts, and it can eventually work through all the possible characters in the credentials until it completes the password. Since this is scripted and aimed at the system's login form, it's able to make quick work of Joomla systems that use LDAP for authentication.
It's probably safe to say that not many Joomla servers use LDAP for authentication, but it's most likely being used somewhere. LDAP is used quite frequently for authentication.
The first thing you should do is review if your site is vulnerable. Anyone running Joomla versions 1.5 through 3.7.5 is vulnerable if they're using LDAP authentication on their unpatched site. However, there was a patch released that specifically addresses this issue, and it can be installed to mitigate this vulnerability.
Using these plug-ins for authentication naturally brings up the topic of using multifactor authentication. Your authentication architecture should no longer rely on systems using single-factor authentication for applications, especially public-facing applications. This process will limit the risk of vulnerabilities or data leaks that can expose data credentials to attackers.
My article at: http://searchsecurity.techtarget.com/answer/LDAP-injection-How-can-it-be-exploited-in-an-attack
Sunday, January 28, 2018
BlueBorne vulnerabilities: Are your Bluetooth devices safe?
Last month, a series of Bluetooth vulnerabilities was discovered by research firm Armis Inc. that enables remote connection to a device without the affected users noticing.
The vulnerabilities were reported on Android, Linux, Windows and iOS devices. These vendors were all contacted to create patches for the BlueBorne vulnerabilities and worked with Armis via a responsible disclosure of the exploit. The concern now is the vast amount of Bluetooth devices that might not update efficiently. This concern, combined with working with Android devices to have the update go out to all its manufacturers, will be the biggest hurdle when remediating the BlueBorne vulnerabilities.
The BlueBorne vulnerabilities enable attackers to perform remote code execution and man-in-the-middle attacks. This attack is dangerous because of the broad range of Bluetooth devices out in the wild and the ease with which an attacker can remotely connect to them and intercept traffic. With this exploit, an attacker doesn't have to be paired with the victim's device; the victim's device can be paired with something else, and it doesn't have to be set on the discoverable mode. Essentially, if you have an unpatched system running on any Bluetooth devices, then your vulnerability is high.
However, the affected vendors have done a good job releasing patches for the BlueBorne vulnerabilities. Microsoft patched the bug in a July release and Apple's iOS isn't affected in iOS 10. The issue is with Android, which is historically slow to patch vulnerabilities, and will have to work with itsvendors to have the patch pushed down.
Likewise, the larger issue will be with all of the smart devices and internet of things devices that are installed on networks, meaning your TVs, keyboards, lightbulbs and headphones could all be vulnerable. There's probably a smaller risk of data being exposed on these devices, but they can still intercept information and be used as a way to propagate the issue further.
Another concern with these vulnerabilities is the possibility of a worm being created, released in a crowded area and potentially spreading itself through devices in close proximity to each other. Particular exploits might not work on all phones in this case, but it could still be possible given the right code and circumstance. For example, if the worm was released in a stadium or large crowd, then it could theoretically spread if the systems haven't been properly patched.
Being able to perform code injection to take over a system or create man-in-the-middle attacks, which can be used to steal information, is extremely worrisome. These attacks are happening inside the firewall and don't need to join your network in order to be executed. This is essentially like a backdoor that enables attackers to compromise systems from a distance and within your network.
It is extremely important that you patch all systems if you have the capability to do so, or that you disable Bluetooth devices when they're not needed.
The vulnerabilities were reported on Android, Linux, Windows and iOS devices. These vendors were all contacted to create patches for the BlueBorne vulnerabilities and worked with Armis via a responsible disclosure of the exploit. The concern now is the vast amount of Bluetooth devices that might not update efficiently. This concern, combined with working with Android devices to have the update go out to all its manufacturers, will be the biggest hurdle when remediating the BlueBorne vulnerabilities.
The BlueBorne vulnerabilities enable attackers to perform remote code execution and man-in-the-middle attacks. This attack is dangerous because of the broad range of Bluetooth devices out in the wild and the ease with which an attacker can remotely connect to them and intercept traffic. With this exploit, an attacker doesn't have to be paired with the victim's device; the victim's device can be paired with something else, and it doesn't have to be set on the discoverable mode. Essentially, if you have an unpatched system running on any Bluetooth devices, then your vulnerability is high.
However, the affected vendors have done a good job releasing patches for the BlueBorne vulnerabilities. Microsoft patched the bug in a July release and Apple's iOS isn't affected in iOS 10. The issue is with Android, which is historically slow to patch vulnerabilities, and will have to work with itsvendors to have the patch pushed down.
Likewise, the larger issue will be with all of the smart devices and internet of things devices that are installed on networks, meaning your TVs, keyboards, lightbulbs and headphones could all be vulnerable. There's probably a smaller risk of data being exposed on these devices, but they can still intercept information and be used as a way to propagate the issue further.
Another concern with these vulnerabilities is the possibility of a worm being created, released in a crowded area and potentially spreading itself through devices in close proximity to each other. Particular exploits might not work on all phones in this case, but it could still be possible given the right code and circumstance. For example, if the worm was released in a stadium or large crowd, then it could theoretically spread if the systems haven't been properly patched.
Being able to perform code injection to take over a system or create man-in-the-middle attacks, which can be used to steal information, is extremely worrisome. These attacks are happening inside the firewall and don't need to join your network in order to be executed. This is essentially like a backdoor that enables attackers to compromise systems from a distance and within your network.
It is extremely important that you patch all systems if you have the capability to do so, or that you disable Bluetooth devices when they're not needed.
How can Windows digital signature check be defeated?
Recently, it was determined by a SpecterOps researcher, Matt Graeber, that there is a way to bypass a Windows digital signature check by editing two specific registry keys. This is an important discovery because Windows uses digital signature protection to validate the authenticity of binary files as a security measure.
Digital signature protection is used by Windows and others to determine if a file was tampered with during the time in which it was sent to the receiving party. Being able to validate the integrity of a received file and that it's actually from the party that signed it is important since digital signatures work on trust -- when a system can work around this feature, it opens up doors to malicious activity.
It's also important to state that digital signatures don't secure the file, but give it a level of trust based off of the private key it was signed with; therefore, if that specific key was stolen or used maliciously, then the system would approve the digital signature check.
Many Windows security features and security products rely on the trust and guarantees that a digital signature check brings with it. In the case of the CCleaner malware last month, it spread due to having been signed by a legitimate certificate, which led to the code being trusted by the OS. In his research report, Graeber wrote, "Subverting the trust architecture of Windows, in many cases, is also likely to subvert the efficacy of security products."
The attack is focused on two registry keys that enable you to impersonate files with any other valid signature when adjusted. However, this isn't done via injection of code into the system, but with the registry key modification, meaning the attacker can do this remotely if they have access to the registry. This also means that they must be admins on the system, which isn't incredibly hard to escalate if they aren't don't have permission.
Locking down the administrator rights to limit changes to these keys and implementing monitoring to determine if they were changed would be a way of reviewing if the registry keys were modified, even though this would require the logs of all the systems. It's also possible that a group policy could be made to limit access to these files in greater detail, but these are all reactive methods to this problem.
The issue once again comes down to trust, as this is one area that's put in place to protect you from impersonation. It also happens to be the most likely thing to be used for malicious purposes, especially malware, that would bypass the internal mechanisms to slip past application whitelisting, such as Microsoft's Windows Defender Device Guard.
There needs to be more procedures around digital signature protection to protect against malicious files entering your endpoint.
There needs to be more procedures around digital signature protection to protect against malicious files entering your endpoint, such as reputation services, sandboxes and next-generation malware protection that doesn't rely on signatures.
Is a digital signature check needed? Yes, but it's a layer in the protection against malware, and abusing the trust of these signatures enables them to be bypassed. In the end, we simply need to add more layers to our defense.
My article at: http://searchsecurity.techtarget.com/answer/How-can-Windows-digital-signature-check-be-defeated
Digital signature protection is used by Windows and others to determine if a file was tampered with during the time in which it was sent to the receiving party. Being able to validate the integrity of a received file and that it's actually from the party that signed it is important since digital signatures work on trust -- when a system can work around this feature, it opens up doors to malicious activity.
It's also important to state that digital signatures don't secure the file, but give it a level of trust based off of the private key it was signed with; therefore, if that specific key was stolen or used maliciously, then the system would approve the digital signature check.
Many Windows security features and security products rely on the trust and guarantees that a digital signature check brings with it. In the case of the CCleaner malware last month, it spread due to having been signed by a legitimate certificate, which led to the code being trusted by the OS. In his research report, Graeber wrote, "Subverting the trust architecture of Windows, in many cases, is also likely to subvert the efficacy of security products."
The attack is focused on two registry keys that enable you to impersonate files with any other valid signature when adjusted. However, this isn't done via injection of code into the system, but with the registry key modification, meaning the attacker can do this remotely if they have access to the registry. This also means that they must be admins on the system, which isn't incredibly hard to escalate if they aren't don't have permission.
Locking down the administrator rights to limit changes to these keys and implementing monitoring to determine if they were changed would be a way of reviewing if the registry keys were modified, even though this would require the logs of all the systems. It's also possible that a group policy could be made to limit access to these files in greater detail, but these are all reactive methods to this problem.
The issue once again comes down to trust, as this is one area that's put in place to protect you from impersonation. It also happens to be the most likely thing to be used for malicious purposes, especially malware, that would bypass the internal mechanisms to slip past application whitelisting, such as Microsoft's Windows Defender Device Guard.
There needs to be more procedures around digital signature protection to protect against malicious files entering your endpoint.
There needs to be more procedures around digital signature protection to protect against malicious files entering your endpoint, such as reputation services, sandboxes and next-generation malware protection that doesn't rely on signatures.
Is a digital signature check needed? Yes, but it's a layer in the protection against malware, and abusing the trust of these signatures enables them to be bypassed. In the end, we simply need to add more layers to our defense.
My article at: http://searchsecurity.techtarget.com/answer/How-can-Windows-digital-signature-check-be-defeated
Active Cyber Defense Certainty Act: Should we 'hack back'?
Recently, a bill was proposed by Georgia Congressman Tom Graves named the Active Cyber Defense Certainty Act, which has now gone on to be called the hack back bill by individuals in the cyber community. This bill is being touted as a cyberdefense act that will enable those who have been hacked to defend themselves in an offensive manner. It's essentially attempting to try and fill the holes the antiquated Computer Fraud and Abuse Act has left wide open.
I'm a big fan of evolving our laws to bring them into a modern state when it comes to cybersecurity, but I feel this law will cause more harm than good. Allowing others to hack back without the proper oversight -- which I feel is extremely lacking in the proposed bill -- will create cyber vigilantes more than anything else. I also feel that this law can be abused by criminals, and it doesn't leave us in any better state than we're in now.
First, the jurisdiction of the Active Cyber Defense Certainty Act only applies to the U.S. If someone notices an attack coming from a country outside the U.S., or if stolen data is being stored outside the boundaries of our borders, then they won't be able to hack back.
This already severely limits the effectiveness of this bill, as it can easily be bypassed by attackers who can avoid consequences by launching an attack with a foreign IP. It can also enable pranksters or attackers to start problems for Americans by purposefully launching attacks from within compromised systems in the U.S. to other IPs inside the country. This would give the victims the legal right to hack back against the mischievous IPs, while the spoofed organizations remained unaware of what happened, and started the process of attacking them back.
In theory, this would create a hacking loop within the U.S. and would end up causing disarray, giving an advantage to the hackers. Not only can systems be hacked by a malicious entity, but they can be legally hacked by Americans following the initial attack; hackers would essentially be starting a dispute between two innocent organizations.
On that note, if attackers launch attacks from the U.S. against other systems within the U.S., it's possible for them to attack the systems that regulate our safety. And what if they attack the systems of our healthcare providers, critical infrastructure or economy? Do we really want someone who might not be trained well enough to defend against attacks poking at these systems? This isn't safe, and it borders on being negligent on the part of those who were compromised.
The mention of 'qualified defenders with a high degree of confidence of attribution,' really leaves the door open to what someone can do within the Active Cyber Defense Certainty Act.
The mention of "qualified defenders with a high degree of confidence of attribution," really leaves the door open to what someone can do within the Active Cyber Defense Certainty Act. First, what makes someone a "qualified defender," and how are they determining a "high confidence of attribution"? Is there a license or certification that someone must have in order to request the ability to hack back? Even if they did receive something similar, they still won't know the architecture or systems they're looking to compromise in order to defend themselves. What tools are they able to use and what level of diligence must be shown for attribution? This is a recipe for disaster, and it's also very possible that emotions could get in the way when determining what to delete or how far to go.
The Active Cyber Defense Certainty Act also mentions contacting the FBI in order to review the requests coming into the system before companies are given the right to hack back. This could lead to an overwhelming number of requests for an already stretched cyber department within the FBI.
If anything, I feel that the bill should leave these requests to the Department of Homeland Security instead of the FBI, as an entirely new team would need to be created just to handle these requests. This team should be the one acting as the liaison to the victim organizations.
For example, if we knew someone stole a physical piece of property, and we knew where they were storing it, we'd most likely call the local authorities and let them know what occurred. In the case of cybercrime, they're giving us the ability to alert the authorities, and then go after our stolen goods ourselves. This is a mistake that could lead to disaster.
Lastly, there are technical issues that might make this a lot more difficult than people think. What if a system is being attacked by the public Port Address Translation/Network Address Translation address of an organization? Are they going to start looking for ways into that network even though they can't access anything public-facing?
Also, what will happen if cloud systems are being used as the source of an attack? How do you track systems that might be moving or destroyed before someone notices? In that case, you could end up attacking the wrong organization. I personally don't trust someone attacking back and making changes to a system that they don't manage, since it leaves the door open for errors and issues later on that we're not even considering now.
Data theft today is a massive concern, but the privacy implications and overzealous vigilantism of this bill could make a bad situation much worse. The Active Cyber Defense Certainty Act should be removed from consideration, and the focus should be put on how Americans can work toward creating a better threat intelligence and cybersecurity organization that can act as a governing body when attacks like these occur. Leaving such matters in the hands of those affected will never produce positive results.
I'm a big fan of evolving our laws to bring them into a modern state when it comes to cybersecurity, but I feel this law will cause more harm than good. Allowing others to hack back without the proper oversight -- which I feel is extremely lacking in the proposed bill -- will create cyber vigilantes more than anything else. I also feel that this law can be abused by criminals, and it doesn't leave us in any better state than we're in now.
First, the jurisdiction of the Active Cyber Defense Certainty Act only applies to the U.S. If someone notices an attack coming from a country outside the U.S., or if stolen data is being stored outside the boundaries of our borders, then they won't be able to hack back.
This already severely limits the effectiveness of this bill, as it can easily be bypassed by attackers who can avoid consequences by launching an attack with a foreign IP. It can also enable pranksters or attackers to start problems for Americans by purposefully launching attacks from within compromised systems in the U.S. to other IPs inside the country. This would give the victims the legal right to hack back against the mischievous IPs, while the spoofed organizations remained unaware of what happened, and started the process of attacking them back.
In theory, this would create a hacking loop within the U.S. and would end up causing disarray, giving an advantage to the hackers. Not only can systems be hacked by a malicious entity, but they can be legally hacked by Americans following the initial attack; hackers would essentially be starting a dispute between two innocent organizations.
On that note, if attackers launch attacks from the U.S. against other systems within the U.S., it's possible for them to attack the systems that regulate our safety. And what if they attack the systems of our healthcare providers, critical infrastructure or economy? Do we really want someone who might not be trained well enough to defend against attacks poking at these systems? This isn't safe, and it borders on being negligent on the part of those who were compromised.
The mention of 'qualified defenders with a high degree of confidence of attribution,' really leaves the door open to what someone can do within the Active Cyber Defense Certainty Act.
The mention of "qualified defenders with a high degree of confidence of attribution," really leaves the door open to what someone can do within the Active Cyber Defense Certainty Act. First, what makes someone a "qualified defender," and how are they determining a "high confidence of attribution"? Is there a license or certification that someone must have in order to request the ability to hack back? Even if they did receive something similar, they still won't know the architecture or systems they're looking to compromise in order to defend themselves. What tools are they able to use and what level of diligence must be shown for attribution? This is a recipe for disaster, and it's also very possible that emotions could get in the way when determining what to delete or how far to go.
The Active Cyber Defense Certainty Act also mentions contacting the FBI in order to review the requests coming into the system before companies are given the right to hack back. This could lead to an overwhelming number of requests for an already stretched cyber department within the FBI.
If anything, I feel that the bill should leave these requests to the Department of Homeland Security instead of the FBI, as an entirely new team would need to be created just to handle these requests. This team should be the one acting as the liaison to the victim organizations.
For example, if we knew someone stole a physical piece of property, and we knew where they were storing it, we'd most likely call the local authorities and let them know what occurred. In the case of cybercrime, they're giving us the ability to alert the authorities, and then go after our stolen goods ourselves. This is a mistake that could lead to disaster.
Lastly, there are technical issues that might make this a lot more difficult than people think. What if a system is being attacked by the public Port Address Translation/Network Address Translation address of an organization? Are they going to start looking for ways into that network even though they can't access anything public-facing?
Also, what will happen if cloud systems are being used as the source of an attack? How do you track systems that might be moving or destroyed before someone notices? In that case, you could end up attacking the wrong organization. I personally don't trust someone attacking back and making changes to a system that they don't manage, since it leaves the door open for errors and issues later on that we're not even considering now.
Data theft today is a massive concern, but the privacy implications and overzealous vigilantism of this bill could make a bad situation much worse. The Active Cyber Defense Certainty Act should be removed from consideration, and the focus should be put on how Americans can work toward creating a better threat intelligence and cybersecurity organization that can act as a governing body when attacks like these occur. Leaving such matters in the hands of those affected will never produce positive results.
iOS updates: Why are some Apple products behind on updates?
A new study from mobile security vendor Zimperium Inc. showed that nearly a quarter of the iOS devices it scanned weren't running the latest version of the operating systems. If Apple controls iOS updates, and enterprise mobility management vendors can't block them, then why are so many devices running older versions? Are there other ways to block iOS updates?
Zimperium's study showed that more than 23% of the iOS devices it scanned weren't running the latest and greatest version of Apple's operating system. Even though Apple has a more streamlined method of updating its mobiles devices than its main competitor, Android, this is only because it controls both the hardware and the software -- Apple doesn't rely on disparate manufacturers to apply patches.
That being said, it came as a surprise to many that so many iOS devices weren't up to the bleeding-edge iOS; however, there are a few reasons why we're seeing almost a quarter of iOS devices being delinquent.
For starters, some people just don't want the new update when it becomes available. Even though iOS updates can be nagging, it's possible to delay them or have your device remind you to install it later. It would be interesting to know how many devices are only one update behind the latest update to see if people are holding off temporarily or indefinitely.
Another reason that devices might not be up to the latest version is that legacy devices may not support the newest update -- the newer releases of iOS aren't compatible with every device. This might be a small percentage of devices, but it's still part of the 23%.
Likewise, certain devices have been jailbroken, and thus could have issues receiving updates. These are possible issues that can add up to the 23% found by Zimperium, but there are some configuration and operational changes that might also cause a delayed update.
By default, automatic iOS updates are enabled, and that's a great way for Apple to continue pushing over 75% of its devices to run the latest software update. While you can have the automatic updates disabled on an iOS device and delete the update after it's been downloaded, there is probably only a small percentage of devices operating like this.
Also, there's most likely a small percentage of people that don't have their devices connected to Wi-Fi, which is often how the update is downloaded, if not via iTunes on a computer.
Lastly, if a device can't access apple.com, then it cannot receive the update. In the past, I've seen web filters block iPads from accessing apple.com to limit what could be downloaded from iTunes. With this filtering in place, you're also stopping the download of the latest iOS update.
When all of these small issues add up, you can understand the percentage of devices that aren't running the latest update. However, I'm still curious to see what the average patching cycle for devices is after an update is released, as it's possible that Zimperium's scan was in the middle of a release, which could have inflated the numbers a bit.
Either way, there will always be issues with patching systems, but as consumer devices go, Apple is doing a pretty good job of having its iOS devices updated in the field.
My article at: http://searchsecurity.techtarget.com/answer/iOS-updates-Why-are-some-Apple-products-behind-on-updates
Zimperium's study showed that more than 23% of the iOS devices it scanned weren't running the latest and greatest version of Apple's operating system. Even though Apple has a more streamlined method of updating its mobiles devices than its main competitor, Android, this is only because it controls both the hardware and the software -- Apple doesn't rely on disparate manufacturers to apply patches.
That being said, it came as a surprise to many that so many iOS devices weren't up to the bleeding-edge iOS; however, there are a few reasons why we're seeing almost a quarter of iOS devices being delinquent.
For starters, some people just don't want the new update when it becomes available. Even though iOS updates can be nagging, it's possible to delay them or have your device remind you to install it later. It would be interesting to know how many devices are only one update behind the latest update to see if people are holding off temporarily or indefinitely.
Another reason that devices might not be up to the latest version is that legacy devices may not support the newest update -- the newer releases of iOS aren't compatible with every device. This might be a small percentage of devices, but it's still part of the 23%.
Likewise, certain devices have been jailbroken, and thus could have issues receiving updates. These are possible issues that can add up to the 23% found by Zimperium, but there are some configuration and operational changes that might also cause a delayed update.
By default, automatic iOS updates are enabled, and that's a great way for Apple to continue pushing over 75% of its devices to run the latest software update. While you can have the automatic updates disabled on an iOS device and delete the update after it's been downloaded, there is probably only a small percentage of devices operating like this.
Also, there's most likely a small percentage of people that don't have their devices connected to Wi-Fi, which is often how the update is downloaded, if not via iTunes on a computer.
Lastly, if a device can't access apple.com, then it cannot receive the update. In the past, I've seen web filters block iPads from accessing apple.com to limit what could be downloaded from iTunes. With this filtering in place, you're also stopping the download of the latest iOS update.
When all of these small issues add up, you can understand the percentage of devices that aren't running the latest update. However, I'm still curious to see what the average patching cycle for devices is after an update is released, as it's possible that Zimperium's scan was in the middle of a release, which could have inflated the numbers a bit.
Either way, there will always be issues with patching systems, but as consumer devices go, Apple is doing a pretty good job of having its iOS devices updated in the field.
My article at: http://searchsecurity.techtarget.com/answer/iOS-updates-Why-are-some-Apple-products-behind-on-updates
PGP keys: Can accidental exposures be mitigated?
Recently, security researcher Juho Nurminen attempted to contact Adobe via their Product Security Incident Response Team (PSIRT) regarding a security bug he wanted to report. Instead, he stumbled across something much more vulnerable.
It turns out that Adobe not only published their public key on their website, which is used to send encrypted emails, but the corresponding private PGP keys, as well. After being contacted privately by Nurminen, Adobe moved quickly to revoke the key and had it changed.
The risks of having the entire key pair published on the site could have led to phishing, decryption of traffic, impersonation, and spoofed or signed messages from Adobe's PSIRT. This was extremely embarrassing for Adobe; however, their ability to act quickly was their saving grace.
One thing that they did right was putting a passphrase on the certificate because, without it, the Adobe private key is useless to those with malicious intent. This is one step that every organization should take to protect against the accidental release of a certificate or having an attacker gain access to keys and attempt to use them maliciously. Be warned though -- having a passphrase on a certificate for security is only as good as the passphrase it's being secured with, and a weak passphrase increases the probability of it being brute-forced.
Having procedures in place to quickly revoke PGP keys when needed should be part of your organization's incident response plan. This might not be a common occurrence for many people; however, being able to manage certificates in an expedited fashion could not only save your organization, but could also stop those with malicious intent from attempting to impersonate you.
Having procedures in place to quickly revoke PGP keys when needed should be part of your organization's incident response plan.
Acting quickly is extremely important. Luckily, the Adobe private key had limited use -- the certificate was only being used for email communication for the PSIRT, so it wasn't as publically used as some of their other certificates.
As for how the certificate was published in the first place, that's a different issue -- I'd be very curious to know why this certificate was sent in the first place, and who sent it. There should be some type of privileged access in place for these certificates internally, which I'm assuming is a different department from those managing the CMS.
I understand things can accidentally be miscommunicated or published, but there seems to have been a few breakdowns in the communication process for the Adobe private key to have been published to the internet. I'm hoping Adobe was able to learn from the experience, make adjustments and tighten their security.
My article at: http://searchsecurity.techtarget.com/answer/PGP-keys-Can-accidental-exposures-be-mitigated
It turns out that Adobe not only published their public key on their website, which is used to send encrypted emails, but the corresponding private PGP keys, as well. After being contacted privately by Nurminen, Adobe moved quickly to revoke the key and had it changed.
The risks of having the entire key pair published on the site could have led to phishing, decryption of traffic, impersonation, and spoofed or signed messages from Adobe's PSIRT. This was extremely embarrassing for Adobe; however, their ability to act quickly was their saving grace.
One thing that they did right was putting a passphrase on the certificate because, without it, the Adobe private key is useless to those with malicious intent. This is one step that every organization should take to protect against the accidental release of a certificate or having an attacker gain access to keys and attempt to use them maliciously. Be warned though -- having a passphrase on a certificate for security is only as good as the passphrase it's being secured with, and a weak passphrase increases the probability of it being brute-forced.
Having procedures in place to quickly revoke PGP keys when needed should be part of your organization's incident response plan. This might not be a common occurrence for many people; however, being able to manage certificates in an expedited fashion could not only save your organization, but could also stop those with malicious intent from attempting to impersonate you.
Having procedures in place to quickly revoke PGP keys when needed should be part of your organization's incident response plan.
Acting quickly is extremely important. Luckily, the Adobe private key had limited use -- the certificate was only being used for email communication for the PSIRT, so it wasn't as publically used as some of their other certificates.
As for how the certificate was published in the first place, that's a different issue -- I'd be very curious to know why this certificate was sent in the first place, and who sent it. There should be some type of privileged access in place for these certificates internally, which I'm assuming is a different department from those managing the CMS.
I understand things can accidentally be miscommunicated or published, but there seems to have been a few breakdowns in the communication process for the Adobe private key to have been published to the internet. I'm hoping Adobe was able to learn from the experience, make adjustments and tighten their security.
My article at: http://searchsecurity.techtarget.com/answer/PGP-keys-Can-accidental-exposures-be-mitigated
VMware AppDefense: How will it address endpoint security?
VMware recently added a new service called AppDefense to their cybersecurity portfolio that aims to lower false positives and utilize least privilege in order to secure endpoints living on the host. VMware also has NSX to create microsegmentation on the network layer, which can integrate into AppDefense. However, with AppDefense, the security of the systems is taken down a layer to the endpoints.
The first major benefit of having VMware AppDefense is that it understands what the endpoints were provisioned to do and their intended behavior. The AppDefense service is in the hypervisor and has a detailed understanding of what's normal within the endpoints. If something changes, such as malware reaching a system, then it's able to detect that the endpoint is doing something outside of what it was designed to do.
This feature helps to reduce false positives within your network and enables overworked security teams to focus on the alerts that truly matter. By creating alerts to monitor the system's behavior and to make sure they are operating properly, the alert time for analysts is reduced. Since VMware AppDefense recognizes that detecting and responding to incidents is key, these alerts help security teams focus on what is important.
Utilizing least privilege is a security staple, and using it whenever possible is always recommended. With AppDefense, you're able to build off of what VMware NSX started and drop least privilege down from the network layer to the endpoint. This further increases the ability to lock down your systems to only what's needed and limit your threat exposure.
When alerts within AppDefense are found, it's possible to kick off a response from NSX to take action and to block communications, take snapshots for forensics, or even shut down the endpoint. This detailed control of what can occur after an alert has been found with AppDefense enables endpoints to be isolated and for remediation to occur quickly and efficiently. The automation of AppDefense and the integration of NSX enables in-depth security and an added layer of visibility into workloads that might have been overlooked in the past.
With the creation of NSX and AppDefense services, VMware has been making big strides in security by focusing on the fundamentals. By giving analysts the visibility into their networks and endpoints using least privilege, an understanding of a behavior change enables a quicker incident response time. I'm excited to see how VMware continues to evolve on its own.
My article at: http://searchsecurity.techtarget.com/answer/VMware-AppDefense-How-will-it-address-endpoint-security
Subscribe to:
Posts (Atom)