Replace or mitigate now if you’re affected (if you happen to run containers, you in all probability are.)
Thanks to David Jones at Safety Dive for bringing this to my consideration.
Palo Alto’s Unit 42 found a vulnerability within the AWS Log4Shell scorching patch. This patch obtained utilized to virtually each kind of compute useful resource on AWS, so you might need to replace instantly if you’re utilizing an affected system.
Notice that this vulnerability doesn’t require you to be working Java or Log4Shell, so its affect could possibly be probably larger than the Log4Shell vulnerability itself to AWS Prospects working containerized functions.
The patch is designed to mechanically patch susceptible functions. The issue is that the patch itself just isn’t containerized, basically. It runs in a course of that has entry to the complete host.
You may get into the weeds on this Palo Alto submit:
Palo Alto affords the next mitigations of their article (quote):* On standalone hosts, you'll be able to improve by working yum replace log4j-cve-2021–44228-hotpatch (RPM) or apt set up — only-upgrade log4j-cve-2021–44228-hotpatch (Debian).* On Kubernetes clusters that put in the new patch to each node by way of the hotpatch Daemonset, it's essential to manually join to each node and replace the put in scorching patch by way of yum or apt. Notice that solely deleting the new patch Daemonset doesn’t take away the new patch service out of your nodes.* Hotdog customers must improve to the newest model.Alternatively, if you happen to’re assured that your surroundings is patched in opposition to Log4Shell, you'll be able to disable the new patch service on a bunch by working sudo contact /and so forth/log4j-cve-2021–44228-hotpatch.kill. To disable Hotdog, run apiclient set oci-hooks.log4j-hotpatch-enabled=false.
Hopefully you may have an automatic deployment that lets you shortly redeploy all VMs and containers with the newest model. That ought to assist resolve a number of the points with out the necessity for particular patches, however test the particulars above to confirm. That features your EKS hosts and containers working on them. You may suppose that’s tough to automate, however that’s precisely what we confirmed college students easy methods to do in considered one of my AWS class labs. We automated deployment of EKS and the containers working on it. It’s doable, and I’ve executed it.
I’ve simply completed a presentation on Developer Governance for IANS analysis and might be presenting that at their Dallas and Los Angelos boards this yr. In case you can’t make these test for an IANS occasion close to you had been another person might be presenting and talking to these slides. I cowl subjects like automated deployments. Moreover, you’ll be able to schedule a name with me at IANS Analysis when you’ve got questions on easy methods to create automated, immutable deployments and safe deployment pipelines.
Along with with the ability to shortly replace containers, hopefully you might be working in a zero-trust surroundings with correct networking controls and monitoring to assist uncover any assaults which will outcome from this vulnerability.
Lastly, if you happen to discover all this patching to be difficult, think about cloud-managed companies that deal with some (not all) of the patching for you mechanically. In case you are utilizing AWS Lambda, for instance, the patching of the hosts would happen mechanically beneath the hood. You continue to must hold the code you run in your Lambda features updated. I used to be simply speaking to a shopper at IANS Analysis about that. Typically the dimensions of your crew drives you in the direction of specific AWS companies.
One different consideration right here is that Palo Alto found this vulnerability, not Amazon. Palo Alto has a vested curiosity to find vulnerabilities which they’ll incorporate into their cloud services and products that report safety issues in cloud environments. Their product now stories this downside they found which may help prospects shortly mitigate the problem.
What AWS doesn’t have is a bug bounty program that pays different researchers with no such motivations to uncover and report bugs, like the opposite high cloud suppliers do. Amazon does. AWS doesn’t. Test the scope.
Safety points found within the AWS IP Area (https://ip-ranges.amazonaws.com/ip-ranges.json) should not in scope for Amazon Vulnerability Analysis Program. As an infrastructure supplier, AWS prospects function property on this area. Discovering and testing in opposition to AWS and AWS buyer property is strictly out of scope for Amazon Vulnerability Analysis Program and in opposition to the AWS AUP (https://aws.amazon.com/aup/).
AWS simply hopes that researchers will spend their free time discovering and reporting bugs right here.
Microsoft has a bug bounty program, although my expertise with it just lately wasn’t nice. They recommended I discuss to assist as a substitute of responding to the problem and what was making it, if it was not in reality a safety downside (which in line with others it was). You know the way I really feel about contacting Microsoft assist if you happen to’ve been following alongside. I hope they’ll repair these points however at the very least they’ve a bug bounty:
Google has a bug bounty program. I’ve not reported something right here however I do know individuals who have been paid vital sums via this program:
If an organization has a strong bug bounty program that pays effectively, which means extra persons are working to seek out vulnerabilities on the platform and can take the time to report and completely clarify them to obtain fee for his or her effort and time. Fortunately, Palo Alto had some exterior motivation on this case.
I hope that AWS will rethink its stance on bug bounties in mild of this difficulty. Some folks report vulnerabilities on AWS for the celebrity and glory of speaking about them at DefCon. What number of different vulnerabilities weren’t reported or adopted up on appropriately as a result of AWS does’t have a bug bounty program? There’s no solution to know for positive, however I want they’d one.
As you might need learn in my final submit, I’m an AWS Hero and I’ve cherished utilizing AWS for a very long time. AWS has a number of the greatest safety engineers and on this planet and I do know a few of them, however as this vulnerability exhibits — no person’s good!
Teri Radichel — Comply with me @teriradichel
© 2nd Sight Lab 2022
____________________________________________
Wish to study extra about Cybersecurity and Cloud Safety? Take a look at: Cybersecurity for Executives within the Age of Cloud on Amazon
Want Cloud Safety Coaching? 2nd Sight Lab Cloud Safety Coaching
Is your cloud safe? Rent 2nd Sight Lab for a penetration take a look at or safety evaluation.
Have a Cybersecurity or Cloud Safety Query? Ask Teri Radichel by scheduling a name with IANS Analysis.
Cybersecurity & Cloud Safety Sources by Teri Radichel: Cybersecurity and Cloud safety lessons, articles, white papers, shows, and podcasts
