Skip to content

Latest commit

 

History

History
77 lines (59 loc) · 5.76 KB

File metadata and controls

77 lines (59 loc) · 5.76 KB

Attack Tree Analysis for facebook/folly

Objective: [*** Attacker Goal: RCE or DoS via Folly ***]

Attack Tree Visualization

                                      [*** Attacker Goal: RCE or DoS via Folly ***]
                                                    |
                                     -------------------------------------
                                     |                                   |
                      [Exploit Folly Vulnerabilities]       [Abuse Folly Features/Misconfigurations]
                                     |                                   |
                ---------------------------------------       ---------------------------------------
                |                                                                     |
[Vulnerability in  FBThrift (if integrated)]                                [Misconfigured ThreadManager]
                |                                                                     |
        -----------------                                                     -----------------
        |
[***Known CVEs***]                                                     [***OOM due to Improper Pool Sizing***]
        |
---(HIGH RISK)---
  • Description: The ultimate objective of the attacker is to achieve either Remote Code Execution (RCE) on the target application or to cause a Denial of Service (DoS), rendering the application unavailable. RCE is the most severe outcome, allowing the attacker to execute arbitrary code, while DoS disrupts service.
  • Likelihood: N/A (This is the goal, not an attack step)
  • Impact: Very High
  • Effort: N/A
  • Skill Level: N/A
  • Detection Difficulty: N/A
  • Description: This branch represents the attacker's attempt to leverage vulnerabilities within the Folly library itself to achieve their goal. This could involve exploiting known or unknown (0-day) vulnerabilities.
  • Description: This node focuses on vulnerabilities specifically within FBThrift, Facebook's implementation of the Thrift RPC framework. Folly often provides underlying infrastructure for FBThrift, so vulnerabilities in FBThrift can be exploited through Folly. This is only relevant if the application uses FBThrift.

Attack Tree Path: Known CVEs

  • Description: This is the most critical and high-risk attack vector. It involves exploiting publicly known and documented vulnerabilities (Common Vulnerabilities and Exposures) in Folly or FBThrift. Exploits for these vulnerabilities may be readily available, making them attractive targets.
  • Likelihood: Medium (Depends on patching frequency and the existence of publicly available exploits)
  • Impact: High to Very High (RCE, Data Breach, DoS)
  • Effort: Low to Medium (Exploits may be publicly available or easily adaptable)
  • Skill Level: Intermediate (Script kiddies can often use publicly available exploits)
  • Detection Difficulty: Medium (IDS/IPS, WAF may detect known exploit signatures, but bypasses are possible)
  • Mitigation:
    • Immediate and consistent patching: The most crucial defense is to apply security patches for Folly and FBThrift as soon as they are released.
    • Vulnerability scanning: Regularly scan the application and its dependencies for known vulnerabilities.
    • Web Application Firewall (WAF): A WAF can help detect and block some exploit attempts.
    • Intrusion Detection/Prevention System (IDS/IPS): An IDS/IPS can monitor network traffic for malicious activity.
  • Description: This branch represents attacks that don't necessarily exploit bugs in Folly, but rather misuse its features or rely on misconfigurations to cause harm.

Attack Tree Path: Misconfigured ThreadManager

  • Description: This node focuses on attacks targeting the ThreadManager component of Folly, which is used for managing thread pools.
  • Description: This critical node represents a Denial of Service (DoS) attack caused by configuring Folly's ThreadManager with an excessively large thread pool. This leads to Out-of-Memory (OOM) errors, crashing the application.
  • Likelihood: Medium (Common misconfiguration, especially in environments with limited resources)
  • Impact: High (Application crash, complete DoS)
  • Effort: Very Low (Requires only changing configuration settings)
  • Skill Level: Novice (Basic understanding of thread pools is sufficient)
  • Detection Difficulty: Easy (Application crashes with OOM errors, easily visible in logs and monitoring)
  • Mitigation:
    • Careful thread pool sizing: Determine the appropriate thread pool size based on the application's workload and available resources. Avoid creating unnecessarily large pools.
    • Resource limits: Use operating system mechanisms (e.g., ulimit on Linux, resource limits in containers) to restrict the maximum memory the application can use.
    • Monitoring: Monitor memory usage and thread pool activity to detect potential OOM conditions early.
    • Load testing: Conduct load testing to determine the application's resource requirements under stress.