Noriswadi Ismail of Breakwater Solutions and the Humanising 2030 campaign joins us to talk about privacy as it pertains to international business, cybersecurity and why it’s important not just to learn the certification variants but also the cultural variants that shape them. And via the Humanising 2030 campaign, Noriswadi and colleagues hope to bring a more ethical and diverse approach to programming and guiding AI in the coming decade.
– Get your FREE cybersecurity training resources: https://www.infosecinstitute.com/free
– View Cyber Work Podcast transcripts and additional episodes: https://www.infosecinstitute.com/podcast
0:00 - Privacy and international business
2:53 - Noriswadi's first interest in tech
6:38 - A path toward patent law
11:32 - Managing director at Breakwater
16:05 - State of international security and risk plans
18:52 - Certifications internationally
22:58 - Experience versus certification
25:40 - Humanising 2030
29:24 - AI bias and geopolitical impact
32:30 - Diversity and including in cybersecurity
38:23 - Other goals of Humanising 2030
41:22 - What is Breakwater Solutions?
44:44 - Outro
About Infosec
Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
Privacy and international business | Guest Noriswadi Ismail
Horizon3.ai Drives Global Partner-First Approach with Expansion of Partner Program
Businesswire: 09/27/22
Horizon3.ai announced it has expanded its partner program to include new rewards, incentives, training, and tools to help partners drive more recurring revenue. The mission of the Horizon3.ai Partner Program is to drive growth opportunities for partners and position them as trusted advisors for their clients.
The post Horizon3.ai Drives Global Partner-First Approach with Expansion of Partner Program appeared first on Horizon3.ai.
Attack surface managers and the state of attack surfaces | Guest Dave Monnier
Dave Monnier of Team Cymru talks about the state of attack surfaces, the strengths and shortcomings of attack surface managers and why something we refer to as a “soft” skill might be the hardest skill of all! Plus, we touch on shadow IT.
– Get your FREE cybersecurity training resources: https://www.infosecinstitute.com/free
– View Cyber Work Podcast transcripts and additional episodes: https://www.infosecinstitute.com/podcast
0:00 - Attack surfaces
2:55 - Dave Monnier's first interest in cybersecurity
7:30 - Instinctual cybersecurity learning
9:20 - Monnier's work as a chief evangelist
14:00 - Cybersecurity soft skills
16:30 - What are attack surface managers?
28:25 - ASM 1.0 to ASM 2.0
32:22 - State of attack surfaces
34:58 - Asset infrastructure in your business
40:00 - Key skills cybersecurity novices need
43:07 - Learning in cybersecurity
45:42 - Learn more about Team Cymru
47:19 - Outro
About Infosec
Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
The importance of API security and PII | Guest Giora Engel
Today on Cyber Work, Giora Engel of NeoSec talks about securing APIs. Find out why APIs are the new network, why their very nature makes them vulnerable to abuse and how to position yourself as an authority in the ever-growing field of API security. All that and a little entrepreneur talk.
– Get your FREE cybersecurity training resources: https://www.infosecinstitute.com/free
– View Cyber Work Podcast transcripts and additional episodes: https://www.infosecinstitute.com/podcast
0:00 - API security and PII
2:40 - Giora Engel’s cybersecurity beginning
4:20 - Israeli Defense Force and CEO of NeoSec
5:22 - Starting a cybersecurity company
9:20 - What is API security?
13:15 - Misconfiguration errors in API
17:21 - API and privacy regulation
20:02 - How to work in API security
22:06 - Security plan for PII
24:44 - Skills and experience needed to work in API security
27:10 - API hiring practices
28:58 - Fragility of API
31:07 - What is NeoSec?
32:35 - Learn more about NeoSec and Engel
32:55 - Outro
About Infosec
Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
How an Akamai misconfiguration earned us USD 46.000
A few months ago me and my friend Jacopo Tediosi made an interesting discovery about an Akamai misconfiguration that allowed us to earn more than 46,000 dollars. Our research highlighted how manipulating a particular HTTP header made it possible to change the way how proxies communicated with each other and how this allowed us to perform different request smuggling attacks or, in particular cases, allowed us to poison the cache with arbitrary content chosen by us. In this post we will go directly into detail without explaining how these vulnerabilities work in general, hoping that the reader knows what we are talking about. If not, there are so many resources online and even labs to practice with them.
Now the question is: how were we able to reveal the misconfiguration? and how was it actually handled by major bug bounty platforms and private companies? Even today you can encounter this header in the response in several Server under the Akamai network.
Probably many of you have already understood or had already tried to force the use of Content-Length instead of Transfer-Encoding. But let’s go one step at a time. Once we noticed this particular thing, any attempt to abuse the Connection header with Content-Length as a value to perform a Request Smuggling attack didn’t work.
One curious thing we noticed was some unusual responses being provided by Akamai, such as [no URL].
Or, with www.example.com:
if we use the same host, the server actually provided different responses, but as many will know it is difficult to determine if it was actually Request Smuggling, HTTP Pipelining, or a normal server behavior by setting the Connection header in keep-alive.
Trying to redirect the requests with my co-worker we actually found that it worked. But currently, we only had one potential Denial of Service which is often rejected for lack of impact. Once this was done, we did some tests from a different network to verify that it was an open desync.
Only later we discovered that by inserting other host within the Akamai network we were completely able to redirect each other and finally we had a complete request smuggling. This sounds good, but we had a problem. We don’t have a host within Akamai network. How can you prove that through the attack you can arbitrarily redirect users if you don’t have any logs to show? As we continued to try, and luckily for us, we were able to abuse this bug to arbitrarily cache content from other hosts. We also found that, in addition to the GET method, we could use the OPTIONS method to perform the desired attack, moreover, there were more chances that Akamai would not notice that the request was actually malicious.
To poison the cache, it was necessary to send a first GET or OPTIONS request to a nonexistent path (also to avoid damage to the platform), preferably with static resource extensions (more likely to be taken from the cache), with the second request to arbitrary hosts. After a couple of requests, the content of the second host’s file was correctly cached due to its revalidation, like this:
From then on it was possible to visit the URL /it/it/medusa.txt which returned the robots.txt of the second host.
Obviously, the content we decided to cache was not malicious but we could cache many types of files such as html or js.
Finally, we had a nice impact for the report.
POC:
OPTIONS /random.txt HTTP/1.1
Host: ORIGINAL-HOST
Connection: Content-Length
Content-Length: 42
GET /robots.txt HTTP/1.1
Host: ARBITRARY-AKAMAI-HOST
x: 1by sending the request twice it was possible to cache the contents of robots.txt of the second host. As soon as the discovery was made, we started responsible disclosure, reporting the vulnerability to Akamai. We have not received immediate confirmation from them. While we waited, we realized that not all Akamai hosts were vulnerable or some did not allow arbitrary content caching (they probably had no cache or particular cache key settings that did not allow the attack). We thought maybe it was some general misconfiguration and decided to report it in bug bounty platforms as well.
Vulnerability management by bug bounty platforms: Our sincere admiration for the triagers of the Hackerone platform. After a very short time, they were able to replicate and understand the vulnerability by assigning the right severity.
Unfortunately, in Bugcrowd many of the triagers were unable to replicate the vulnerability despite providing a oneliner with curls, video POC, screenshots, and more. Some just didn’t put the two blank lines in GET requests, others had wrong burp targets and we have also received duplicated (?). like:
We were very disappointed with the Bugcrowd triagers.
Microsoft: Microsoft replied very late, saying it was unable to replicate the vulnerability (Akamai had already introduced the security fix).
Apple: Apple responded late, and was unable to replicate the vulnerability due to Akamai’s fix. They were very kind and we received thanks by email, but no bounty was paid (we didn’t want any).
Intigriti: We only filed a bug, the triager was very nice and friendly, but he gave us a duplicated.
THE FIX: Akamai took very little time to get the security fix after our report, now any attempt to use the Connection header in an inappropriate way is automatically blocked. Akamai has given us permission to make a public disclosure.
Plung n Panda – APT Group
Patched ≠ Remediated: Healthcare Faces an Aggressive Threat Landscape
The Challenge: Healthcare Faces an Aggressive Threat Landscape.
One of our clients, a leading U.S. hospital and healthcare system, consistently earns high marks for clinical excellence and is among the top 10 percent in the nation for patient safety. Recognizing the growing cybersecurity threats to healthcare organizations and importance of importance of maintaining compliance with regulatory standards like HIPAA, PCI, and other privacy rules, the organization’s IT staff worked hard to ensure a strong security posture.
Our client’s IT team had adopted many security best practices and tools, including state-of-the-art firewalls, vulnerability scanning, endpoint detection and response (EDR), automated patch management, network segmentation, and a managed security service provider (MSSP). In addition, the team began implementing a zero-trust architecture and has tools to monitor the many specialized medical devices on its hospital networks.
Even with these comprehensive security practices in place, the team wanted to do more. Hackers have increasingly targeted the healthcare industry. In 2020, over 600 data breaches of 500 or more patient records were reported. Ransomware attacks continue to be extensively used against healthcare organizations, and these attacks are becoming more costly.
The Solution: NodeZero™ Automated Red Teaming
Liberman Networks, a managed security and IT services company, recognized that even with their many controls implemented, our client could still be vulnerable to an attack.
Liberman Networks called on Horizon3.ai to help validate our client’s defenses and provide proof of what was truly effective and which deficiencies remained.
Our client used Horizon3.ai’s NodeZero – a fully autonomous SaaS offering that views the network from the attacker’s perspective – to conduct a comprehensive penetration test across its enterprise. In a matter of minutes and with virtually no configuration, NodeZero began its reconnaissance, mapping the organization’s infrastructure and over 8,400 hosts, probing for misconfigurations, open ports, and other vulnerabilities an attacker could exploit, whether alone or by chaining multiple weaknesses.
The Findings: Unauthenticated Access to Domain Controller’s
NodeZero ran for eight days with no adverse impact to the network.
NodeZero identified 31 vulnerabilities with 278 unique attack paths, proofs for each, and remediation guidance.
The most significant and surprising finding was immediately communicated to our client by Liberman Networks – even before NodeZero completed its testing. Ten Microsoft Active Directory domain controllers included ZeroLogon – a “critical” and potentially catastrophic privilege escalation vulnerability allowing unauthenticated accesses to devices first disclosed a year prior to the NodeZero test. Worse, an exploit was publicly available, making the vulnerability an easy target. Had attackers targeted the vulnerable hosts they could have quickly created their own credentials and gained unfettered access to every system in the organization. The result could include stealing patient information and financial data or installing ransomware on our client’s endpoints and databases.
“We patched this back in February. All of our reporting shows it as patched.” — Director of Infrastructure
Lesson 1: Reporting Tools Can Lie.
At first, our client believed NodeZero was in error. They were diligent in their patching and their records showed a successful update for the ZeroLogon vulnerability months earlier. Our client also had evidence; reporting from Qualys and Microsoft Deployment Image Servicing and Management (DISM) showed all systems were patched, and they trusted their tools.
In this case trusting the tools was a mistake. Liberman Networks and Horizon3.ai’s customer success team investigated further and confirmed that the updates had been unsuccessful. When our client reapplied patches to the 10 servers, a subsequent test by Liberman Networks and Horizon3.ai showed that 4 of the 10 devices remained vulnerable – despite showing as patched – again – in Microsoft.
A security solution blocked security updates for 18 months.
After further analysis, our client found the problem; a misconfiguration in their EDR solution had blocked patches on the domain controllers for the past 18 months! The failures were not propagated back to the patch management system, resulting in their vulnerability management and monitoring tools to incorrectly report a successful patch install. After manually pushing patches to each domain controller NodeZero was quickly re-run, proving that the problem had truly
been remediated.
“This is a good experience for me to teach the team the importance of credential use and reuse. We never would have found this vulnerability without NodeZero.” — Director of Infrastructure
Lesson 2: Patching ≠ Remediation
The lesson our client learned was simple; patching is not the same as remediating. Our client followed standard best practices in the defenses. They tracked security updates to their systems, promptly patched for critical issues using industry-leading tools and verified the patches using Microsoft DISM. As they saw, the tools can be wrong, leaving organizations vulnerable to attacks.
With assistance from Horizon3.ai and Liberman Networks, our client’s IT staff improved their security profile and their internal in monitoring, detection, and response skills. The IT team’s increased knowledge and confidence is generating greater trust in IT by the business. By using an offensive strategy to test its defenses, the healthcare system is evolving its cybersecurity posture to match the threat landscape that it faces.
Lesson 3: Follow Patch Tuesday with Pentest Wednesday.
According to the NIST Cyber Security Framework, organizations should validate through systematic audit and assessment that they have truly fixed vulnerabilities after deploying patches. In reality, most IT teams lack the resources to do penetration testing after every patch.
After their experience with misreported patching – with proof from Liberman Networks and NodeZero – our client added a step to “Patch Tuesday”: “Pentest Wednesday” with NodeZero to validate all patches are correctly implemented and risks are mitigated.
The post Patched ≠ Remediated: Healthcare Faces an Aggressive Threat Landscape appeared first on Horizon3.ai.
Workshop: Linux Kernel Exploitation 101 – Part 2
Slide: https://hacktivesecurity-my.sharepoint.com/:b:/p/alessandro/EX9sSrCCRIlLqvkHoRl7_jQBB6xKgV_qLL9UA5fIwf2Cbw?e=cCQpix
Materiale utilizzato nel video (per poter replicare i lab): https://hacktivesecurity-my.sharepoint.com/:u:/p/alessandro/EX08cV3wTzZJsEeEQwZvw80BbybF2CpUmJdsXXGlY0hnwA?e=JaGru3
Il materiale è stato testato con Ubuntu 20.04 con architettura x86_64. Non dovrebbero esserci problemi con altre release.
Per iscriverti al workshop del 25 settembre, segui le pagine social di Cyber Saiyan (organizzazione di Romhack)
- Linkedin: https://www.linkedin.com/company/cyber-saiyan/
- Twitter: https://twitter.com/cybersaiyanIT
- Link all’evento: https://romhack.camp/camp-schedule/
Inoltre, per rimanere aggiornato su progetti futuri, seguici su Linkedin e Twitter:
- Linkedin: https://www.linkedin.com/company/hacktive-security/
- Twitter: https://twitter.com/hacktivesec
- Website: https://www.hacktivesecurity.com/
Capitoli:
0:00 Introduzione
0:25 Introduzione a gdb
1:18 Compilare il kernel con simboli
3:00 Navigazione codice sorgente
3:41 Navigazione codice sorgente: Elixir
7:04 Navigazione codice sorgente: search_binary_handler
12:33 Kernel Debugging
12:56 Qemu kernel debugging
13:42 Kernel Debugging: gdb
15:25 Kernel Debugging: search_binary_handler
19:56 Infarinatura su assembly intel
33:46 struct task_struct
34:40 arch/
37:51 task_struct
40:20 init_task
41:04 Kernel Debugging: init_task
47:41 Common Vulnerabilities
48:55 Memory Corruption & Weird Machine
51:25 Common Mitigations (Introduzione)
54:03 Heap Overflow
56:06 Lab: Heap Overflow
1:07:42 Use-After-Free
1:09:33 Lab: Use-After-Free
1:16:28 KASLR
1:17:34 SMAP & SMEP
1:19:44 SMEP
1:21:25 SMAP
1:22:54 SMAP & SMEP: x86 vs ARM
1:23:50 Exploitation Strategies
1:27:14 Victim Object
1:29:15 Victim Object: Pre-requisiti
1:29:48 Victim Object: Esempio
1:31:11 Lab: Victim Object
1:36:40 Lab: Victim Object – offset init_task
1:42:13 Conclusione
Workshop: Linux Kernel Exploitation 101 – Part 1
Slide: https://hacktivesecurity-my.sharepoint.com/:b:/p/alessandro/EX9sSrCCRIlLqvkHoRl7_jQBB6xKgV_qLL9UA5fIwf2Cbw?e=cCQpix
Materiale utilizzato nel video (per poter replicare i lab): https://hacktivesecurity-my.sharepoint.com/:u:/p/alessandro/EX08cV3wTzZJsEeEQwZvw80BbybF2CpUmJdsXXGlY0hnwA?e=JaGru3
Il materiale è stato testato con Ubuntu 20.04 con architettura x86_64. Non dovrebbero esserci problemi con altre release.
Per iscriverti al workshop del 25 settembre, segui le pagine social di Cyber Saiyan (organizzazione di Romhack)
- Linkedin: https://www.linkedin.com/company/cyber-saiyan/
- Twitter: https://twitter.com/cybersaiyanIT
- Link all’evento: https://romhack.camp/camp-schedule/
Inoltre, per rimanere aggiornato su progetti futuri, seguici su Linkedin e Twitter:
- Linkedin: https://www.linkedin.com/company/hacktive-security/
- Twitter: https://twitter.com/hacktivesec
- Website: https://www.hacktivesecurity.com/
Capitoli:
00:00 Introduzione video
00:41 Introduzione workshop
1:14 Cos’è il kernel
4:04 User-Mode vs Kernel-Mode e Protection Ring
6:53 Syscall: User-Mode =} Kernel-Mode
8:18 Lab: Syscall
19:45 Kernel =} Hardware
21:13 Hardware =} Kernel
22:02 Kernel Memory
22:13 Stack vs Heap
23:48 Heap Memory Management: SLAB SLOB SLUB
24:33 SLUB
27:12 Partial slabs
29:34 SLUB API
31:08 Page Tables: User vs Kernel pointers
34:26 copy_from_user & copy_to_user
35:34 CONFIG_HARDENED_USERCOPY
36:14 Lab: Introduzione Setup
38:02 Lab: Stack vs Heap
38:15 Lab: KRWX
39:33 Lab: Character device
40:44 Lab: file_operations
41:58 Lab: module_init & module_exit
42:28 Lab: Stack vs Heap
43:43 Lab: Heap & /proc
45:40 Lab: slabinfo & /sys/kernel/slab
49:21 Lab: KRWX & SLUB
1:02:02 Conclusione
Corporate data breaches and security awareness training | Guest Mathieu Gorge
Mathieu Gorge of VigiTrust talks about the Marriott Hotel data breach that happened back in June, including the facts of the event and why once-per-year security awareness training isn’t enough when many employees only work seven months of the year. He also offers some privacy tips that will keep your hotel system privacy compliant under a whole host of different compliance frameworks.
– Get your FREE cybersecurity training resources: https://www.infosecinstitute.com/free
– View Cyber Work Podcast transcripts and additional episodes: https://www.infosecinstitute.com/podcast
0:00 - Security awareness and data breaches
2:50 - Elephant in the boardroom book
5:42 - Gorge's latest projects and book
9:38 - Hacking of the Marriott Hotel
19:22 - Marriott's privacy and data collection policies
23:20 - Ensuring data privacy worldwide
30:13 - How hotel franchises handle security
34:32 - Skills needed for securing the hotel industry
38:12 - What is DigiTrust?
41:20 - Outro
About Infosec
Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
Are Your Kubernetes Clusters Configured Properly?
TL;DR: Given recent news about misconfigured Kubernetes clusters, it’s a great time to review best practices for ensuring the security configurations for your own Kubernetes network. Read on to learn more.
Researchers recently discovered some 900,000 Kubernetes clusters that were potentially exposed to malicious scans and data theft during a threat-hunting exercise. The vast majority of those clusters responded with 401 Unauthorized or 403 Forbidden errors, and while that’s better than being completely exposed, it doesn’t mean that they’re necessarily configured properly. Any time a number like that hits the headlines, cybersecurity professionals can feel that familiar twist in their stomach: please don’t let that number include me.
Let’s take a look through the eyes of an attacker at a Kubernetes environment. First, it’s important to understand that Kubernetes utilizes HTTP and HTTPS APIs for communication between its various components. The APIs are well documented and transparent, meaning the APIs we’ll be using are the same ones the Kubernetes components use. There are no hidden APIs that get used behind the scenes which makes enumeration fairly and interacting with Kubernetes straight forward.
Our generalized attack flow will be: identify IPs hosting possible Kubernetes components, enumerate against default Kubernetes ports, determine the version of Kubernetes running, check the cluster for vulnerabilities or misconfigurations and finally exploit the vulnerabilities.
As mentioned in the above article, identifying Kubernetes clusters can be done with online scanners like Shodan.io. A few default Shodan queries include:
- title:”Kubernetes Dashboard”
- product:kubernetes
- Kubernetes
For a more targeted attack, an IP address, GET requests and knowledge of the Kubernetes API is all you need. The responses from GET requests can indicate whether or not Kubernetes is running on a given port. For the rest of this article, we’ll be using a cluster set up in our development lab and deliberately misconfigured. We’ll use ‘curl’ to send a GET request to the default Kubernetes API server port (6443) and check the response. Initially we get a ‘403 Forbidden’ error. The message “forbidden: User \”system:anonymous\” cannot get path” is a hint that the request was blocked by Kubernetes Role-based Access Controls (RBAC) as ‘system:anonymous’ is a built-in Kubernetes user and is used when an authenticated user or service account isn’t used to make the request.
A GET request to the default Kubernetes API server port (6443) to check the response.
Let’s make the same request but this time ask ‘curl’ to display the response headers as well using the ‘-i‘ flag.
An additional request, asking ‘curl’ to display the response headers as well as the ‘-I’ flag.
While we still get the same 403 Forbidden response back, there are two headers that stand out in the response: ‘x-kubernetes-pf-flowschema-uid’ and ‘x-kubernetes-pf-prioritylevel-uid’. These headers are included in responses from default Kubernetes deployments. An additional method to identify a cluster is to inspect the Subject Alternative Name (SAN) in the SSL certificate being used. If the certificate is a self-signed certificate generated by Kubernetes during its deployment, you’ll see something similar to the following: “DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local”.
Now that we, the attackers, have identified a Kubernetes cluster, we’ll again use ‘curl’ to see if we can determine the version of Kubernetes that is deployed. There are two API resources we’ll check. The first is the API server running on port 6443 and the other is the kubelet with runs by default on port 10250 (HTTPS). First we’ll check the API server to see if it leaks the version information.
Checking the API server to see if it leaks the version information.
Looking at the output, we see the major, minor, and gitVersion listed. This tells us that we’re running Kubernetes 1.24.3. Now let’s try the kubelet component to see if we can get it to respond. If it responds, there’ll be a flood of information. We can narrow down the output to the version information by using ‘grep’.
Narrowing down the output to the version information using ’grep’.
Here again we see the git_version in the output with the value of “v1.24.3”. Why is the version information important to an attacker? Well, the Kubernetes APIs are ever evolving and improving as new features are added and old APIs are deprecated. This means that the Kubernetes components are sensitive to version skew. Attackers can use the Kubernetes command-line tool, kubectl, to interact with a vulnerable cluster. They’ll want to make sure that the version of kubectl they are using matches with the major and minor version of the cluster they are attacking as this will eliminate any issues they may encounter due to changed APIs.
Getting a response from the kubelet indicates that it is misconfigured. The kubelet is a Kubernetes component that runs on each node as the primary “node agent.” It communicates with the API server and is responsible for ensuring the containers on that node are running and healthy. A kubelet with open access means an attacker may have the ability to read information about the pods on a node or read the logs of the containers. Worse yet, the attackers may be able to run arbitrary commands inside of the existing containers or to start containers of their own.
Using ‘curl’ we can get a list of pods on the node. We’ll use ‘jq’ to clean up the output and extract only the pod names.
Using ‘jq’ to clean up the output and extract only pod names.
Taking this a step further, let’s see if we can run a command inside one of the containers. We’ll keep it simple and see if we can run an ‘ls -al’. In addition to the pod name, we’ll need the namespace and container name we want to run the command in. We can of course get all that information from the kubelet and in fact we’ll use the same command we just used with just a small tweak to the ‘jq’ output.
Testing to see if a command can be run inside one of the containers.
Now with all the information we need, we can attempt to run a command in the calico-node-8krgh pod. This time instead of a GET request, we’ll use ‘curl’ to send a POST to the /run API with the namespace, pod, and container as parameters and the command we want to run as the body of the request.
Using ‘curl’ to send a POST to the /run API with the namespace, pod, and container as parameters and the command we want to run as the body of the request.
At this point, the attackers have free rein within this pod and container to do what they like. The next step would be a container escape and full compromise of the host running the cluster.
Improving Your Kubernetes Environment’s Security Configurations
We’ve just demonstrated how a couple of simple misconfigurations can quickly lead to a significant compromise of your infrastructure. But that’s just one example attack path against one or two misconfigured items. With as complex as Kubernetes can get, it can be easy to misconfigure a component. So instead of resolving the specific misconfigurations one-by-one from above, here’s some overarching guidance that will help improve your overall security posture.
First, understand and correctly apply Role-Based access controls (RBAC) to your cluster. RBAC provides a system to restrict access and prevent subjects from making requests to resources that they don’t have access to. It consists of three primary items; the resource, the verb and the subject. The resource is the Kubernetes API resource type like a node or a pod. The verb is what operation can be performed on the resource like create or list. The subject is a user, group, or service account that is making the request. Properly applied RBAC in the scenario above would have prevented any of the anonymous requests.
Second, limit your exposed surface. The Kubernetes dashboard is a good user tool that can aid in the administration of your cluster. However, it is likely not a good idea to expose the dashboard to the internet even with the correct permissions and authentication in place. If the only people that need access to the dashboard are the infrastructure team and they only access it from your intranet, then make sure it hasn’t been accidentally exposed to the internet. There are several ways to expose a service to external users. The variety of methods and complexity of Kubernetes networking can make it non-trivial to do correctly. Don’t assume that because service is exposed on an ephemeral high port that it’s configured correctly and not accessible from external sources.
Finally, regularly verify the security of your cluster. Kubernetes is a complex system. The more pods you deploy, the more services you expose, the more complex it gets. Your security posture today isn’t the same as it will be tomorrow. Verify your security whenever you make a change to your configuration or deployment. This can be the hardest recommendation to follow as infrastructure is constantly changing and thoroughly checking your cluster security COULD be a long and painstaking process, but it doesn’t have to be. This is where NodeZero shines!
Verify your cluster security with NodeZero
NodeZero runs an autonomous penetration test when you want or need to. You’ll get results quickly, and rather than a laundry list of risks, your vulnerabilities will be listed by criticality, so you can move quickly on the biggest risks right away. NodeZero will also show you how it was able to discover the vulnerabilities and it will provide proof of the exposure so you don’t have to wonder where or how you are exposed.
We’ve significantly expanded our coverage of Kubernetes vulnerabilities and misconfigurations. NodeZero will enumerate your endpoints and determine if a Kubernetes cluster is being hosted. If it determines that there is a cluster present, it will proceed to test the cluster for exposed nodes, services and ports. As soon as NodeZero finishes, you’ll get a prioritized list of weaknesses discovered.
Prioritized weaknesses discovered in a cluster.
NodeZero won’t just tell you that your cluster is vulnerable though. It’ll show you, both how it discovered the weakness and proof of the weakness either in the form of a screenshot or output from a command abusing the weakness.
Path to Unauthenticated Kubernetes API Server Access.
Proof of Unauthenticated Kubernetes API Server Access.
The fact that so many Kubernetes clusters exist today, misconfigured and exposed, highlights the need for more frequent penetration testing with faster turnaround time. NodeZero finds misconfigurations and vulnerabilities so fixes can happen quickly, and those fixes can be verified just as fast.
Run the test. Get the results. Make the fixes you need to make – and then, re-run the test to verify that your Kubernetes clusters are not at risk. Don’t wait for your annual pentest to find out you’ve still got clusters running default settings, or that your dashboard is unprotected.
And best of all, with NodeZero, the next time you see breaking cybersecurity news that keeps you up at night, you can run a test right then and there to make sure you’re not on the list of potential victims.
Schedule a demo today to find out if you’re vulnerable.
Horizon3.ai’s Travis Fahlgren, Senior Engineer, and Trampas Howe, Offensive Security Expert, contributed to this report.
The post Are Your Kubernetes Clusters Configured Properly? appeared first on Horizon3.ai.
-
Horizon3.ai
- Healthcare Staffing Organization Puts Cybersecurity Best Practices in Place with NodeZero
Healthcare Staffing Organization Puts Cybersecurity Best Practices in Place with NodeZero
The director of security engineering at a national healthcare staffing organization grew up wanting to be a hacker, and he found that NodeZero’s ability to provide the attacker’s perspective to help better protect his organization was a perfect fit for keeping his organization safe.
“Security has always been on my mind. Protecting company assets have always been on my mind. We’d reached a point where our organization is big enough, people are working remotely, and I wanted to split off some of my roles and be ultimately dedicated to security,” he says.
One of the challenges he has faced over the years has been convincing the c-suite to focus on security. They always had compliance in mind and policies in place, but the organization struggles with aging software without a development cycle or vendors who didn’t support software when it aged out or broke down.
As a publicly traded company, they ran their annual penetration tests on their roughly 900-1,200 hosts and performed well – they had a strong firewall in place protecting them from outside threats.
“But we have ancient software inside, and one of the great things about NodeZero is that it’s internally focused. In my mind, that’s where the threats will come from,” he says.
The first time he ran NodeZero, it was able to obtain domain admin access in 17 minutes via an overlooked machine that shared a password with other machines. It also surfaced risks and vulnerabilities that those aging machines and systems internally may have otherwise made difficult to find.
“We have folks, who have come and gone, who may have built servers I’m not aware of, that we don’t know about until NodeZero finds them, finds the misconfigurations, and helps us remediate them,” he says.
Immediate, Actionable Results
Before NodeZero, the organization would run one external pentest and one scan to check on their remediation actions.
The pentest would, regardless of vendor, use the same tools.
“You get a PDF telling your execs how you suck, and 99 percent of the stuff that says you suck are things that are such low priority you don’t care about them,” he says. “I love that with NodeZero, those are identified as low-priority, such as expired SSL certs, very minor things.”
Because other options all felt cookie cutter, with no difference in quality, leadership simply wanted the cheapest, easiest option to check that box. Cost was always a struggle – with security being seen as an annoying expense – until a key leader re-joined the company having survived a ransomware attack with his previous organization who now had security at top of mind.
“He asked, what are you missing? I told him endpoint protection, and we had the contract signed the next day,” he says.
When it came time for addressing pentesting, there was some pushback between the dev and infrastructure teams, but once they ran a demo of NodeZero, the teams fell in line.
I showed the demo to our network guy, who’s as big a cynic as I am and he was blown away, saying ‘this is what we need,’” he says.
This was all happening right around the time the Log4Shell vulnerability was the talk of the cybersecurity world.
“Log4j was everywhere,” he says, but running NodeZero offered actionable mitigation right away, whereas other tools they were using at the time had a lag time of weeks.
From Once a Year to Once a Month
The organization now runs NodeZero once a month, and then retests mid-month. With NodeZero they’re able to show progress better than ever before.
“Audit and compliance guys would look at the number of vulnerabilities in a 90-day period and say the numbers have gone up, you haven’t fixed anything,” he says. “But we’re able to show them that these are new weaknesses, and that new vulnerabilities come up all the time. We’re not being measured against those 90 days, and we can compare in the middle of the month to see what’s been fixed.”
In fact, with NodeZero running, the only issues his team has not fixed are due to manpower, not because of testing.
“Honestly, anything that hasn’t been addressed is a resource issue on our side,” he explained.
And, NodeZero has helped improve their results from other tools and resources. They were able to improve notification of attacks from their MSSP from four hours to fifteen minutes and validated their endpoint protection by verifying that the pentests are immediately detected and alerts issued – all enabling them to get more out of existing expenditures.
NodeZero has improved their overall accuracy, such as identifying a false positive that came up time and time again with Adobe Flash that was no longer being used but could not be removed from some older machines.
Doing Things Other Vendors Don’t
“I don’t think you have any other competitors,” he says. “I’d a have to go out and get a red team to do what NodeZero does, and it would cost twice as much for one scan.”
He also appreciates that NodeZero doesn’t just stop when it finds a vulnerability – it keeps digging. “It chains attacks, which other pentesters don’t do,” he says. “Hackers don’t say hey, I got access to this, I’ll stop here. That’s not how they operate.”
As a once-aspiring hacker himself, their director of security engineering knows that anyone who says they are 100% secure is either dishonest or naïve.
“You are going to get breached. It’s going to happen,” he says. “But the more you understand, the better you can lock things down and limit the blast radius.”
If you’d like to see how NodeZero works with your organization, have our experts walk you through a demo.
The post Healthcare Staffing Organization Puts Cybersecurity Best Practices in Place with NodeZero appeared first on Horizon3.ai.
An International Look at Cybercrime
Authoritarian regimes have learned in recent years that cybercrime can be a profitable economic enterprise – so much so that they continue to invest substantial resources in large- and small-scale cybercrime. This lucrative work goes on to fund their governments and their lavish lifestyles, among other things.
These nefarious nation state actors – North Korea, Iran, Russia, and China – all steal large sums of money by targeting Western infrastructure, private and public organizations, and sometimes even outspoken entities that speak openly against each of them. Furthermore, these nation state actors have long seen the West as an existential threat on the global stage for a multitude of reasons, especially in the realms of economy, infrastructure, intelligence and military affairs.
Economically, the battle between communism and capitalistic agendas rages on, with stiff competition between Eastern and Western technology, energy, manufacturing, and more For example, China uses its global Belt and Road initiative (BRI) under the guise of helping struggling economies to gain influence and essentially creating debt traps for unsuspecting countries. Meanwhile, maritime power has reemerged as a vehicle for control and asserting dominance over disputed territories (referring to China’s ambitions for Taiwan and controlling the parts of the Pacific, so far, an icy stalemate). Conflicts are also being fought on land, as seen with Russia’s invasion of Ukraine and Iran’s continued tensions with Israel and the U.S. regarding their nuclear agenda.
The Link Between Cybersecurity and Geopolitics
With this gradual increase in global cyber competition, it is no wonder that nation states continue to invest in cyber infrastructure and predominantly fight in the cyber world. Many are correct to believe that cybersecurity and geopolitics are directly linked. If anything, businesses have learned this lesson the hard way. Just because they are private sector and a multinational organization does not mean they are invincible to an enemy nation’s ransomware and cyberattacks. Or better yet, a private business operating abroad becomes a target for spyware (China BRI and cyber giant Huawei) out of the suspicion they are harboring their home country’s government secrets and hold “the keys to the castle.”
Overall, despite a nation state’s obvious agenda for zeroing in on military and government targets, such adversaries have become bolder and less dismissive of attacking private businesses, regardless of that company’s allegiance to serving consumers internationally. For example: As of late, many have pointed fingers at Russia to blame for recent attacks on American companies as big as Microsoft, Apple, Cisco (etc.) as well as being the true culprits of the SolarWinds fiasco in 2020.
As Dangerous as the Wild West
Due to such actions, the cyber world is now as dangerous as the Wild West. The question is, how are businesses and everyday citizens supposed to live while being caught in the chaotic influx of criminalistic and outlaw-ish rivalry?
The answer is: They do not. Cybersecurity has become a constant in daily life, and enemy nation states are part of the reason why. Every day, another business is on the news because it has been hacked by foreign threat actors who, with sophisticated and unsophisticated techniques, manage to destroy the finances, ambitions, and public reputation of a once-respected economic contributor.
Looking back to 10 years ago, it would be hard to believe then believe that extraordinary measures (such as firewalls, multi-factor authentication, intrusion detection and prevention systems, etc.) would now need to be implemented to defend against malicious advanced persistent threats (APTs). However, business today means realizing that nobody is safe. It does not matter anymore what industry an organization belongs to or what product they peddle.
Unfortunately, businesses across the globe are not safe from APTS, regardless of industry, sector or affiliation. APTS tactics techniques and procedures (TTPs) continue to advance, and so should business TTPs when protecting against threats.
Therefore, every private institution needs to align their policies to thinking “security first.” While most businesses have IT departments, many still lack a well-trained and sophisticated cybersecurity team within their organization. Such changes for a more secure network and security structure need to be made, as well as recruiting for the people who can do the job effectively (not just a one-person team). If companies fail to get started before it is too late, most of the world will find themselves at the mercy of cyber outlaws and APTS.
This post was authored by the Cyber Threat Analyst Team: Al Martinek, Corey Sinclair and Taylor Ellis.
The post An International Look at Cybercrime appeared first on Horizon3.ai.
-
- Beyond Password Issues: How NodeZero Found Access to an Organization’s Azure Cloud Environment
Beyond Password Issues: How NodeZero Found Access to an Organization’s Azure Cloud Environment
NodeZero is a generational leap beyond a traditional pentest – organizations often see that for themselves from the moment they give our autonomous pentesting platform a shot. NodeZero surfaces risks and weaknesses that would never have come up during a general vulnerability scan as it chains together attack tactics and techniques to illuminate your most critical impacts an attacker could generate.
Take for example a recent NodeZero operation run by an organization in the wholesale distribution sector. What at first appeared to be minor “password issues” led to a high-risk attack path enabling NodeZero to access the domain admin accounts, and even break into the organization’s Azure cloud environment.
From here, NodeZero could pivot and impact day-to-day operations, such as compromising their business email, but more to follow on that below.
To start, NodeZero performed a host discovery and found weaknesses through the LLMNR (Link-Local Multicast Name Resolution) protocol, poisoning a host and capturing an unverified credential. (LLMNR is a service used by Windows to resolve hostnames to IP addresses when a DNS request fails in a network.)
The first thing NodeZero did at that point was to try to crack the hash, which it did in under five minutes.
NodeZero obfuscates usernames and passwords prior to destroying those records after every pentest, in order to verify that NodeZero was successfully able to obtain them. In this case, “when we see a capital P at the beginning and an exclamation point at the end, that doesn’t bode well,” says Monti Knode, Director of Customer Success with Horizon3.ai. This usually, as you likely already know, means it’s a default or extremely common password.
Making matters worse, this was a privileged account.
Now that NodeZero had the name and password, it attempted to log in to the domain – and in this case, it was able to do so as a Domain Administrator immediately leading to a domain compromise on this domain controller with full read/write access permissions.
An attack graph demonstrating how NodeZero obtained access to the customer’s Azure Cloud.
Domain compromise not once but twice
A business email compromise enabled NodeZero to take a regular user’s credentials – found while trying to log into the domain – and leverage that to find other credentials. It then could find a domain user, impersonate them, and gain additional control over a second domain admin.
With this second credential, NodeZero elevated a regular user with no rights to domain admin by taking advantage of the noPAC vulnerability. A little background: In mid-December 2021, noPac, a public exploit that combined two Microsoft Active Directory design flaws, was released; it allowed escalation of privileges of a regular domain user to domain admin, which then enabled malicious actors to launch multiple attacks, including domain takeovers or ransomware attacks.
“That’s why this vulnerability is at the top of the weakness list,” says Knode. “If we were to recommend one thing to fix in this case, it would be that noPac vulnerability.”
NodeZero offers a Fix Action linking to the knowledge base information needed so the organization could move on a fix action to get those domain controllers patched and protected.
NodeZero offers context for the vulnerability, related credentials and impacts, and the knowledge needed to fix and maintain so the organization has the education and tools to keep it updated in the future.
The impact component is vitally important, as by offering context scoring, the customer can see why a weakness that leads to critical impacts in a network gets prioritized to the top of the list of recommended fixes.
The customer can even rerun a “1-click Verify” pentest on just those hosts where there is a known weakness. “Something like this should be a fairly easy one to do, and we highly recommend it – follow our Fix Actions for those noPac vulnerabilities, select the 1-click Verify option to follow up, and then rerun this more surgical operation as soon as you get the chance,” says Knode.
Business email compromise
NodeZero was also able to execute a business email compromise chaining an attack from the previously successful LLMNR poisoning technique. In this case, NodeZero found that this user was a tenant on the company’s Azure account and from the domain user, was able to pivot for further access. Multi-factor authentication (MFA) was not activated, so NodeZero was able to gain access into their Azure cloud environment and then get into Outlook.
With this valid domain account, NodeZero accessed 25 business emails, and as proof, NodeZero showed the customer the subject lines of the emails it was able to access.
“NodeZero took advantage of the Active Directory login because MFA was disabled on Azure,” says Knode.
With MFA turned off, NodeZero stuffed the newly captured credential and the issue bumped up to a 9.9 on the criticality scale. Implementing Multi Factor Authentication is recommended throughout network zones and data access points, and it was highly recommended that MFA was turned “on” for cloud access, limiting an attacker’s ability to take advantage of their Azure service.
Some of these paths can get complicated, but there are fix-actions the customer can go forward with.
“They have password and credential policy problems, but there were some really high priority fixes they could remediate and see immediate risk reduction,” says Knode. “You don’t have to fix everything. You can fix what matters most, and then verify the fix by running a pentest and aligning it to the scope to see immediately if the fix worked.”
What are you using, and does it work?
One question that comes up time and time again in IT is: are the solutions I’ve already paid for effective?
The NodeZero customer success team asks an organization if they received any alerts about this vulnerability. Was it detected, logged, alerted to, and was it stopped?
In these instances, this did not happen.
When NodeZero was able to dump these credentials, an EDR should absolutely have issued an alert and their antivirus solution should have stopped it.
“We recommend looking into this,” says Knode. “We’re transparent with every action NodeZero takes, so you can go through and see. Export the report and take a look.”
We recommended this organization go back, check logs to see if the incident was detected and logged, and if it wasn’t, ask how someone was able to dump your credentials and why it wasn’t logged, alerted, or stopped.
“Nobody should be able to do this without setting off a trigger and an alert,” says Knode.
From there Horizon3.ai went through the ops, helped plan a strategy, and looked at next steps. Customers can also take the information NodeZero provides in its reporting features to take the steps on their own.
“We’re not trying to ‘pwn’ organizations, we’re not trying to poke them in the face and make them look bad – we want to make sure their security stack is putting out every ounce of protection they want from it,” says Knode.
Want to see NodeZero in action for yourself? Schedule a demo today.
The post Beyond Password Issues: How NodeZero Found Access to an Organization’s Azure Cloud Environment appeared first on Horizon3.ai.
NodeZero: Filling a Unique Niche in Cybersecurity
When an IT and cybersecurity team from a U.S.-based management consulting organization were searching for ways to improve their penetration testing, NodeZero and Horizon3.ai were able to answer the call.
“We’d done some penetration testing in the past, and it was quite expensive,” says the organization’s infrastructure manager. “We were looking to do this on a more regular cadence and looking at different solutions we could implement.”
After running into a team member from Horizon3.ai, they shared a rundown of what they were looking for and felt that NodeZero might be just what the situation called for.
“I liked the ease of implementation and use of the product,” he says. “And the ability to just do constant scanning and fixes without having to pay for every instance was the biggest appeal.”
The organization’s director of IT noted that there were solutions he’d encountered that could do external pentesting, but what they really needed at this stage was powerful internal pentesting capabilities.
“Looking at vulnerabilities and criticality was key for us,” he says. “And the biggest thing for me was having a full-package pentest, with all the functionality you needed to really look for and tackle vulnerabilities accordingly.”
The struggle to keep up
The organization’s biggest struggle at the time was simply being able to keep up with a small team – they didn’t have a dedicated team member to keep up with alerts and investigations.
“We wanted to be able to identify vulnerabilities ahead of time and keep ahead of the game,” says their infrastructure manager. “In the past, when we were doing scans, we were able to identify issues – fortunately none required significant time to fix – but being able to identify those things and act on them before they can be exploited is huge for us with a small team.”
“In looking at and enforcing our security strategy, we’re trying to implement controls – and with NodeZero, we’re able to implement the right controls and software we need to better our environment,” says their director of IT.
This also helps with various compliance requirements, a key component to the security team’s mission, as well as uncover any major vulnerabilities in the environment.
More frequent testing
The team wanted to be able to go in and do internal ops more often, something NodeZero makes uniquely possible.
“Being able to perform on-demand scans is really great – we can scan, make adjustments, and then run another scan to verify we’ve been successful,” says their infrastructure manager.
“We’re taking security to a higher level within the organization to obtain certifications in compliance, and this is going to help with that a lot,” says their director of IT.
Cost effectiveness and efficiency
One of the strongest draws to NodeZero was the ability to run those repeated pentest operations anytime and anywhere they needed them – without incurring additional costs.
“It’s just much more cost effective and easier to deal with the licensing,” says their infrastructure manager.
And to be able to run those operations for internal pentesting set it apart from other options on the market, says their director of IT.
“It’s one thing attacking an organization from the outside, but when attacking from the inside, you need to understand it and have the capabilities to do it,” he says. “I feel NodeZero has the capacity to do that.”
Getting up and running with NodeZero was quick and easy rather than adding cycles to a team that was already running lean.
“Setting up a scan is relatively quick and painless to do,” says their infrastructure manager.
“And even the reports are very intuitive – what the report surfaces and what we need to do to mitigate that,” says their director of IT.
It’s also enabled a frequency of testing they wanted, rather than being limited by the time and cost of standard penetration tests. Before NodeZero, the organization conducted pentests once or twice a year. They already plan to increase this to quarterly, or more – maximizing their return on investment.
NodeZero enables customers to turn a small team into their own seasoned and veteran team.
“It takes a lot of the work our team would have to go through to conduct these investigations, finds vulnerabilities and tells us what needs to happen, and even ranks those vulnerabilities and tells us why something should be considered more urgent than others,” says their infrastructure manager. “It helps prioritize work for optimal impact and address those issues that are going to be critical
to our environment soonest.”
“NodeZero, I think, fills a huge missing niche. Not just the skill set or background of company but the actual product, enabling you to do internal and external vulnerability testing to mitigate the issues most people are facing,” says their director of IT.
If you’d like to see how NodeZero works with your organization, have our experts walk you through a demo.
The post NodeZero: Filling a Unique Niche in Cybersecurity appeared first on Horizon3.ai.
Who wins: Characteristics of a promising startup
SC Media: 08/22/22
Despite a tumultuous market, cybersecurity companies continue to draw millions in venture dollars. So how can startups and investors alike best leverage the relationship? As part of the SC Awards Winners Circle video series, SC Media dug into this dynamic with Dave DeWalt, founder and managing director of NightDragon, recipient of our Best Growth-Stage Investor Of The Year award; Ofer Schreiber, senior partner and head of the Israeli office at YL Ventures, recipient of Early-Stage Investor Of The Year award; and Monti Knode, director of customer success at Horizon3.ai, recipient of the Most Promising Early-Stage Startup award.
The post Who wins: Characteristics of a promising startup appeared first on Horizon3.ai.
Most Promising Early-Stage Start Up | Horizon3.ai
SC Media: 08/22/22
Horizon3.ai has developed, NodeZero, an autonomous penetration testing platform that continuously assesses an enterprise’s attack surface, identifying ways an attacker could chain together harvested credentials, misconfigurations, dangerous product defaults, and exploitable vulnerabilities to compromise systems and data.
The post Most Promising Early-Stage Start Up | Horizon3.ai appeared first on Horizon3.ai.
Horizon3.ai Wins Most Promising Early-Stage Startup in 2022 SC Awards
Businesswire: 08/22/22
Horizon3.ai announced that it has been recognized as an Excellence Award winner in the Most Promising Early-Stage Startup category for the 2022 SC Awards. Now in its 25th year, the industry awards program is cybersecurity’s most prestigious and competitive program, recognizing the solutions, organizations, and people driving innovation and success in information security.
The post Horizon3.ai Wins Most Promising Early-Stage Startup in 2022 SC Awards appeared first on Horizon3.ai.
Download: Healthcare IT – Far Beyond HIPAA Compliance
The post Download: Healthcare IT – Far Beyond HIPAA Compliance appeared first on Horizon3.ai.
