Yesterday, the social media archival service Timehop announced that they had suffered a breach. The service allows users to look back through their social media feeds to see what was happening last year for instance. In order to facilitate this, Timehop stores API keys for users' social media accounts. Timehop did a great job disabling any API keys they thought may have been accessed. Still, this breach highlights the risks of compromises in increasingly connected applications. In this video, we discuss some recommendations for individuals and organizations to inventory and understand API key usage for connected applications.
Ramblings about security, rants about insecurity, occasional notes about reverse engineering, and of course, musings about malware. What more could you ask for?
Tuesday, July 10, 2018
It's 10pm, do you know where your API keys are?
Yesterday, the social media archival service Timehop announced that they had suffered a breach. The service allows users to look back through their social media feeds to see what was happening last year for instance. In order to facilitate this, Timehop stores API keys for users' social media accounts. Timehop did a great job disabling any API keys they thought may have been accessed. Still, this breach highlights the risks of compromises in increasingly connected applications. In this video, we discuss some recommendations for individuals and organizations to inventory and understand API key usage for connected applications.
Saturday, April 28, 2018
DrupalGeddon 2.1 and the state of vulnerability management
If you’re running Drupal 7.x, 8.4.x, or 8.5.x, a new patch was released Wednesday. The patch was rated Critical with a score of 20/25. The Drupal team notified users two days before the patch was released so they could be ready to patch. The patch went live in the middle of the US workday, meaning that organizations wishing to patch had to take an outage window during business hours (not normally advisable). Several organizations we work with wanted to take more time to patch and scheduled a patch window for this weekend (something we strongly advised against).
Unfortunately (and unsurprisingly), attackers began exploiting this vulnerability mere hours after the patches were released. Since this is a remote code execution vulnerability, attackers that exploit it take control as the user that runs the web server software (thankfully this is rarely root). However (depending on configuration), attackers may be able to:
Read the rest of the story on the Rendition Infosec corporate blog.
Unfortunately (and unsurprisingly), attackers began exploiting this vulnerability mere hours after the patches were released. Since this is a remote code execution vulnerability, attackers that exploit it take control as the user that runs the web server software (thankfully this is rarely root). However (depending on configuration), attackers may be able to:
- Upload a web shell
- Dump data from a backend database
- Create landing pages for spam on your domain
- Exploit users who come to your site
- Steal credentials from users who come to your website
Read the rest of the story on the Rendition Infosec corporate blog.
Friday, March 30, 2018
New Windows 7 and Server 2008R2 out of band patch
Microsoft usually only issues patches on the second Tuesday of every month (so-called “Patch Tuesday”). However, when there is a vulnerability that is being exploited in the wild (or is likely to be) Microsoft may issue an out of band patch. That’s exactly what happened yesterday. The vulnerability being patched was introduced when Microsoft patched Meltdown and Spectre in January. In that patch, Windows separates page tables between user space and kernel space to mitigate processor vulnerabilities (kernel page table isolation). But this apparently creates a new problem in Windows 7 and Server 2008R2.
The new vulnerability allows any user on the machine to read and write to the memory of any process, including the kernel. Ironically, this is worse than the original Meltdown vulnerability which only allowed attackers to read (but not write) arbitrary memory. In other words, the patch creates a problem worse than the original vulnerability the patch was written to solve.
Read the full story on the Rendition Infosec corporate blog.
The new vulnerability allows any user on the machine to read and write to the memory of any process, including the kernel. Ironically, this is worse than the original Meltdown vulnerability which only allowed attackers to read (but not write) arbitrary memory. In other words, the patch creates a problem worse than the original vulnerability the patch was written to solve.
Read the full story on the Rendition Infosec corporate blog.
Tuesday, March 27, 2018
Atlanta government was compromised in April 2017 - well before last week's ransomware attack
Last Thursday, the City Of Atlanta suffered outages from a ransomware attack. During the press conference (recorded here), city officials indicated that they were invested in cyber security. They noted that they were working with state and federal law enforcement to resolve the incident and had even been in contact with the Secret Service. Officials noted that this type of attack (and outage) were happening to many organizations. Officials attempted to convey that despite adopting cyber security best practices, the City of Atlanta was victimized. This prompts the question “Was the City of Atlanta following cyber security best practices?”
Though little is known about the internals of the city’s cyber security posture, we quickly learned that the city had exposed remote desktop protocol (RDP) to the Internet with no multi-factor authentication*. This is extremely important because if attackers get a valid username and password combination, they can directly access your information systems if no multi-factor authentication is in place.
*Full disclosure: We’re a little biased on the need for multi-factor authentication, Rendition Infosec installs and monitors multi-factor authentication solutions, click here to learn more.
Cybersecurity Hygiene
Leaving RDP open to the Internet is bad, but leaving SMB (windows file sharing, or Server Message Block) open to the Internet is much worse. Most readers probably remember the WannaCry ransomware campaign that shut down services at the UK’s National Health Service and elsewhere in May 2017. These attacks were powered by the leaked NSA (allegedly) exploit EternalBlue. In June, the same leaked exploit was used with the NotPetya attacks to target Ukrainian businesses (though impacts were felt worldwide). The EternalBlue exploit targets the SMB service on unpatched computers.
Read the full story on the Rendition Infosec corporate blog.
Though little is known about the internals of the city’s cyber security posture, we quickly learned that the city had exposed remote desktop protocol (RDP) to the Internet with no multi-factor authentication*. This is extremely important because if attackers get a valid username and password combination, they can directly access your information systems if no multi-factor authentication is in place.
*Full disclosure: We’re a little biased on the need for multi-factor authentication, Rendition Infosec installs and monitors multi-factor authentication solutions, click here to learn more.
Cybersecurity Hygiene
Leaving RDP open to the Internet is bad, but leaving SMB (windows file sharing, or Server Message Block) open to the Internet is much worse. Most readers probably remember the WannaCry ransomware campaign that shut down services at the UK’s National Health Service and elsewhere in May 2017. These attacks were powered by the leaked NSA (allegedly) exploit EternalBlue. In June, the same leaked exploit was used with the NotPetya attacks to target Ukrainian businesses (though impacts were felt worldwide). The EternalBlue exploit targets the SMB service on unpatched computers.
Read the full story on the Rendition Infosec corporate blog.
Tuesday, March 6, 2018
Countering Russian cyber influence operations
Last Friday in SANS NewsBites, I saw an article talking about how NSA has not taken any action against the reported Russian cyber influence operations in US elections. Many laypeople have commented to me that the US can’t continue to operate in an environment other countries can try to influence our elections. But my follow up question to them is always “how would you fix this?” The answers often start out strong, but when we dig into them a little, we find out there are significant problems with implementation.
*Full disclosure: I’m on the editorial board for SANS NewsBites. You should subscribe and use it for expert opinions on cybersecurity news.
Influence operations in cyberspace are a form of asymmetric warfare. As we have learned from Facebook’s identification of advertising buys by Russian organizations, the cost to launch an influence operation is low. Unfortunately, the cost to counter an influence operation is very high. There are very limited options to counter a cyber influence operation and they all have serious problems. We intentionally won’t address the legal issues with each – let’s assume that the legislature will clear any legal hurdles that need to be addressed.
Options for dealing with cyber influence operations
*Full disclosure: I’m on the editorial board for SANS NewsBites. You should subscribe and use it for expert opinions on cybersecurity news.
Influence operations in cyberspace are a form of asymmetric warfare. As we have learned from Facebook’s identification of advertising buys by Russian organizations, the cost to launch an influence operation is low. Unfortunately, the cost to counter an influence operation is very high. There are very limited options to counter a cyber influence operation and they all have serious problems. We intentionally won’t address the legal issues with each – let’s assume that the legislature will clear any legal hurdles that need to be addressed.
Options for dealing with cyber influence operations
- Counter with your own influence operations to negate undue influence from foreign actors
- Hack those performing the cyber influence operations and prevent them from performing the operations
- Sanctions or other political pressure against those conducting the cyber influence operations
- Conduct cyber influence operations against the aggressor hoping for a “cyber cease fire”
- Force the platforms used for influence to limit their susceptibility to such operations
- Criminally charge those involved in influence operations
Read the full post at the Rendition Infosec corporate blog.
Sunday, February 25, 2018
Vulnerability disclosure – did we get it right with Meltdown and Spectre?
Today Rendition Infosec is releasing a blog post that we started writing more than a month ago. Why now? The dust has settled, that’s why. Prior to the dust settling on Meltdown and Spectre, we think this very important conversation would have been lost in the noise. In light of these vulnerabilities, we think it is important to talk about how their disclosure was handled. What did we get right, what did we get wrong, and how should we in the security community posture for the disclosure of next round of CPU vulnerabilities (there will be more).
As most know, Intel found out about the CPU vulnerabilities as early as June of 2017. The mainstream public did not find out about these until January 2018, and then only because AMD engineers made careless comments in open forums that allowed independent researchers to reverse engineer the vulnerabilities. Normally, Google releases vulnerabilities to the public in 90 days, with exceptions given only in rare circumstances. In this case, they waited because of the seriousness of the vulnerabilities and the amount of work needed to patch them.
Read the full post on the Rendition Infosec corporate blog.
As most know, Intel found out about the CPU vulnerabilities as early as June of 2017. The mainstream public did not find out about these until January 2018, and then only because AMD engineers made careless comments in open forums that allowed independent researchers to reverse engineer the vulnerabilities. Normally, Google releases vulnerabilities to the public in 90 days, with exceptions given only in rare circumstances. In this case, they waited because of the seriousness of the vulnerabilities and the amount of work needed to patch them.
Read the full post on the Rendition Infosec corporate blog.
Tuesday, January 23, 2018
Top three considerations when limiting local administrator rights
Ideally we would always remove administrator rights from all users. But in the real world, we unfortunately must deal with years of technical debt and poor architecture decisions that make the complete elimination of administrator rights difficult (or financially non-viable) for many organizations. So when faced with the task of prioritizing the removal of admin rights from users, where should you start?
There are many things to consider when removing administrator rights and these won’t apply to everyone (for instance some organizations are dealing with specific legacy software that requires admin rights). But when working with clients Rendition Infosec uses these considerations as our top three.
Read the rest of the post (along with remediation thoughts) on the Rendition Infosec corporate blog.
There are many things to consider when removing administrator rights and these won’t apply to everyone (for instance some organizations are dealing with specific legacy software that requires admin rights). But when working with clients Rendition Infosec uses these considerations as our top three.
1. Users with access to sensitive information
2. Users that use the machine to surf the Internet or open email attachments
3. Machines that have direct Internet access
Read the rest of the post (along with remediation thoughts) on the Rendition Infosec corporate blog.
Subscribe to:
Posts (Atom)