Lessons Learned in Network and Memory-Based Moving

Linkos
Network Maersk Network (and others) Lesson 1: Attackers Can Use APIs Too2017 NotPetya Attack Malware leveraged Active Directory and DHCP protocols to conduct reconnaissance
Credential theft and execution conducted via Windows system administration tools (e.g Powershell)
EternalBlue exploit helpful against unpatched machines, but potentially unnecessary
Not unique: 2017 Equifax and 2015 Anthem attack used similar techniques once inside network Initial compromise of M.E.Doc Servers
by Russian Sandworm actors Inject malware via trusted software update CVE-2017-0144 Pivot Credential Theft Pivot Internet M.E.Doc Workstations Unpatched Machines Patched Machines<br>

Lesson 1: Attackers Can Use APIs TooLessons and Opportunities MTDs rely on the attacker needing capabilities unavailable through normal APIs
Reconnaissance, remote execution, download/upload, etc.
However, modern enterprise APIs are rich enough for most attacker needs
Necessary for scalable system administration Conventional targets for movement are no longer sufficient (e.g. memory layout)
Yet attackers must still act outside normal bounds
Credential theft, privilege escalation
MTD may be useful in detecting and preventing such out-of-bounds behavior Lessons Learned Future Opportunities<br>

Lesson 2: Hide Information That Only The Attacker Needs Attacker needs memory offsets to craft exploit. Benign processes don’t care about offsets
No need to sync state across protection domains or keep metadata
No API to leak randomized info Coarse Memory Randomization IP Address Randomization Process 1 Memory Process 2 Memory Process 3 Memory Text
Segment Data
Segment Text
Segment Data
Segment Text
Segment Data
Segment T0: IP0
T1: IP1
T2: IP2 T0: IP3
T1: IP4
T2: IP5 T0: IP6
T1: IP7
T2: IP8 Attacker needs IP addresses to contact victim. Benign processes need IP addresses for network operations
Need to sync IP rotation schedule and other state (e.g. routing rules) across network
Need to provide API (e.g. DNS) to lookup current IP address<br>

Lesson 2: Hide Information That Only The Attacker NeedsLessons and Opportunities Hiding information needed by benign processes:
Imposes additional overhead
May allow the attacker to bypass the MTD
May introduce consistency challenges
Hiding information only needed by an attacker generally avoids these issues
The space is a spectrum. Some defenses target information needed by a limited set of benign processes
May not require API or synchronization techniques Systematic identification of information critical to attackers
Need to leverage realistic threat models
Need to identify how/if this info is used by benign processes
Possibility for ‘tunable’ MTDs that trade overhead & sync challenges with coverage/efficacy Lessons Learned Future Opportunities<br>

Lesson 3: Threat Model and System Type Matter Security community lacks standard metrics of efficacy. To evaluate defenses, researchers created ad-hoc metrics
These implicitly restricted attacker capabilities and were shown inadequate by new attack techniques Many MTDs cause a halt/crash in response to an attack attempt (e.g. memory violation)
In cyber-physical environments this may cause lasting physical harm
Especially problematic if FP rate in non-zero Entropy-based
metrics Memory disclosure
attacks Gadget
availability RelROP
attacks 2005 - 2012 2012 2012 - 2017 2019 Process 1 Memory Text
Segment Data
Segment $hellC0D3 Trap<br>

Lesson 3: Threat Model and System Type MatterLessons and Opportunities Ad-hoc metrics may underestimate the ingenuity of attackers and overestimate the security provided by a MTD
Dangerous to claim a defense makes an attack ‘too hard’
Implicit assumption that attacks on integrity are ‘worse’ than loss of availability can make defense deployment reduce assurance of system Develop evaluation criteria that are informed by realistic attacker behavior
Avoid assuming attackers a limited to specific techniques
Target MTD development for non-conventional platforms
Real-time predictability constraints
High-availability requirements Lessons Learned Future Opportunities<br>

Windows Lesson 4: Used Improperly, MTD May Help Attackers Randomizing data used in forensics or debugging imposes a burden on administrators
Need to log randomized state and be able to recovery true values
Attackers can take advantage of this burden to evade detection for longer Target App Mac Linux Target App Target App Hop Hop T0 T1 T2 MTDs hopping between variants of SW may expose the union of all vulnerabilities
Increases attack surface if adversary only needs a single successful exploit Platform Diversity IP Address Randomization T0: IP0
T1: IP1
T2: IP2 T0: IP3
T1: IP4
T2: IP5 T0: IP6
T1: IP7
T2: IP8<br>

Lesson 4: Used Improperly, MTD May Help AttackersLessons and Opportunities MTDs relying on hopping between software configurations must consider threat model or risk increasing system attack surface
More software leads to more vulnerabilities
MTDs that permute state used for situational awareness may aid attackers by delaying the response of defenders Focus on MTDs than reduce or have minimal impact on runtime attack surface
Identify low-cost options for undoing permutations to state used for situational awareness, debugging, etc.
Minimize additional metadata (volume)
Develop secure high-rate approach to de-randomize Lessons Learned Future Opportunities<br>

Lesson 5: Timescale of Movement Must Match Threat Model Many MTDs (e.g. randomizers) are vulnerable to information leakage
Movement (re-randomization) can minimize the risk of useful leakage
As long as the attacker cannot leak and weaponize an attack prior to movement
Movement strategy matters
Time-based movement can be both insecure and high-overhead
Dangerous to implicitly assume an attacker is ‘too slow’
Event-driven movement can be effective Text
Segment Data
Segment Text
Segment Data
Segment Text
Segment Data
Segment Memory Re-Randomization T0 T1 T2 Trigger Trigger Possible Triggers
Time Periodic – Randomize every n ms
Load time – Instrument loader to randomize layout
Event-driven – Randomize in response to detected event<br>

Lesson 5: Timescale of Movement Must Match Threat ModelLessons and Opportunities MTD movement should be tuned based on a realistic threat model
Time-periodic movement is hard to prove the efficacy of
Event-triggered movement should be based on critical attacker actions
MTDs which provide dynamism without an evidence-based movement rate:
Increase user burden
Are difficult to evaluate the efficacy of Identify critical steps in attack chain and target these for MTD movement
Example: TASR [9] targets I/O pairs for info leakage resilience
Systematically evaluate threat models and identify timing requirements
Example: Minimum round-trip-times based on physical propagation delays Lessons Learned Future Opportunities<br>

Lesson 6: MTDs Must Preserve System-Wide Consistency Dynamic Flow Isolation [7] Firewall rules enforce policy on packet header fields
Must be consistent with both current policy and current network identifiers
Inconsistent in gap between change to either, and update receipt at switch Tracks events quantified on by current policy (e.g. user logon/logoff)
Race condition between sensed event to allow connectivity and user data entering network Tracks bindings between network identifiers (e.g. IP, MAC, Hostname)
Used to target firewall rules at correct entity
Bindings change over time based on external authorities (DHCP, DNS, etc.)
Need to keep identifiers and firewall rules consistent with current values<br>

Lesson 6: MTDs Must Preserve System-Wide ConsistencyLessons and Opportunities Maintaining consistency across MTD movement may be a larger challenge than movement itself
Consistency bugs are hard
Difficult to track down/replicate
Often fatal to processes and network flows
Potential attack vectors for denial-of-service Leverage emerging technologies not just to enable movement, but to preserve consistency
Example: Lightweight containerization Lessons Learned Future Opportunities<br>

Summary MTDs are a valuable defensive capability, but must be designed and deployed with care
It is critical to leverage a realistic threat model in deciding what to move, how to move it, and how often to do so
Improper MTD design can increase attack surface, impose burdens on defenders, and decrease system reliability
Dynamism is most effective and lowest-cost when applied to information that is not needed by benign applications. Otherwise additional challenges arise
Consistency maintenance
APIs to bypass movement are needed by benign applications, but can be used by attackers<br>

Questions? Dr. Samuel Jero
samuel.jero@ll.mit.edu Dr. Richard Skowyra
richard.skowyra@ll.mit.edu<br>

References Skowyra, Richard, et al. "Systematic analysis of defenses against return-oriented programming." International Workshop on Recent Advances in Intrusion Detection. Springer, Berlin, Heidelberg, 2013.
Bauer, Kevin, et al. "Multi-variant execution to protect unpatched software." 2015 Resilience Week (RWS). IEEE, 2015.
Skowyra, Richard, et al. "Have no phear: Networks without identifiers." Proceedings of the 2016 ACM Workshop on Moving Target Defense. 2016.
Rudd, Robert, et al. "Address Oblivious Code Reuse: On the Effectiveness of Leakage Resilient Diversity." NDSS. 2017.
Skowyra, Richard, et al. "Quasar: Quantitative attack space analysis and reasoning." Proceedings of the 33rd Annual Computer Security Applications Conference. 2017.
Ward, Bryan C., et al. Survey of Cyber Moving Targets Second Edition. No. TR-1228. MIT Lincoln Laboratory Lexington United States, 2018.
Gomez, Steven R., et al. "Controller-Oblivious Dynamic Access Control in Software-Defined Networks." 2019 49th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). IEEE, 2019.
Ward, Bryan C., et al. "The Leakage-Resilience Dilemma." European Symposium on Research in Computer Security. Springer, Cham, 2019.
Bigelow, David, et al. "Timely rerandomization for mitigating memory disclosures." Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security. 2015.<br>