of SSH Implementations Paul Fiterau, Toon Lenaerts, Erik Poll, - - PowerPoint PPT Presentation

▶
of ssh implementations
SMART_READER_LITE
LIVE PREVIEW

of SSH Implementations Paul Fiterau, Toon Lenaerts, Erik Poll, - - PowerPoint PPT Presentation

Jan 13, 2023 483 likes •1.22k views

Model Learning and Model Checking of SSH Implementations Paul Fiterau, Toon Lenaerts, Erik Poll, Joeri de Ruiter, Frits Vaandrager, Patrick Verleg Introduction protocols: SSH, TLS, SMTP, FTP, TCP, UDP many implementations per

slide-1
SLIDE 1

Model Learning and Model Checking

  • f SSH Implementations

Paul Fiterau, Toon Lenaerts, Erik Poll, Joeri de Ruiter, Frits Vaandrager, Patrick Verleg

slide-2
SLIDE 2
  • protocols: SSH, TLS, SMTP, FTP, TCP, UDP…
  • many implementations per protocol

➢implementations MUST/SHOULD/MAY adhere to the specifications…

Introduction

slide-3
SLIDE 3
  • protocols: SSH, TLS, SMTP, FTP, TCP, UDP…
  • many implementations per protocol

➢implementations MUST/SHOULD/MAY adhere to the specifications…

Introduction

conformance testing

slide-4
SLIDE 4

Motivation

Model Learning

automatically infers models for concrete implementations checking conformance of models may be difficult

slide-5
SLIDE 5

Motivation

Model Learning

automatically infers models for concrete implementations checking conformance of models may be difficult

slide-6
SLIDE 6

Motivation

Model Checking

automatically checks conformance of models to specifications requires models and formalized specifications

Model Learning

automatically infers models for concrete implementations checking conformance of models may be difficult

slide-7
SLIDE 7

Model Learning + Model Checking

automatically infers models for concrete implementations automatically checks conformance of models to specifications requires formalized specifications

Model Checking

automatically checks conformance of models to specifications requires models and formalized specifications

Model Learning

automatically infers models for concrete implementations checking conformance of models may be difficult

Motivation

slide-8
SLIDE 8

Model Learning + Model Checking

automatically infers models for concrete implementations automatically checks conformance of models to specifications requires formalized specifications

Application of ML+MC on SSH (a real world protocol):

1. use Model Learning to infer models of 3 SSH server implementations 2. formalize specifications from the SSH RFC standards 3. use Model Checking to verify models against these specification

What was done

slide-9
SLIDE 9

Model Learning + Model Checking

automatically infers models for concrete implementations automatically checks conformance of models to specifications requires formalized specifications

Schematic Overview

What was done

Model Learning

  • Spec. formalization

SUL RFC Model Checking

prop1_LTL prop2_LTL SUL: prop1_LTL prop2_LTL SUL:

slide-10
SLIDE 10

Model Learning + Model Checking

automatically infers models for concrete implementations automatically checks conformance of models to specifications requires formalized specifications

What was done

enough for a publication?

slide-11
SLIDE 11

Model Learning + Model Checking

automatically infers models for concrete implementations automatically checks conformance of models to specifications requires formalized specifications

What was done

Model Learning:

requires mapper component requires thorough testing

Model Checking:

requires model transformation requires counterexample validation

slide-12
SLIDE 12

Model Learning + Model Checking

automatically infers models for concrete implementations automatically checks conformance of models to specifications requires mapper component requires formalized specifications requires thorough testing requires model transformation requires counterexample validation

What was done

Patrick’s M. Thesis Toon’s B. Thesis Publication

slide-13
SLIDE 13

Model Learning

  • Spec. formalization

SUL RFC Model Checking

prop1_LTL prop2_LTL SUL: prop1_LTL prop2_LTL SUL:

What was done

slide-14
SLIDE 14

Model Learning

inferred

state model

SUL (System under Learning)

  • utputs

inputs

Learner

slide-15
SLIDE 15

Model Learning

Learner SUL

Learner Queries:

register/ok login

Input Alphabet:

[register, login, logout] Output Alphabet: [ok, nok]

nok

register/ok login/ok logout/ok */nok */nok */nok

Mealy Machine

slide-16
SLIDE 16

Model Learning

Learner SUL

Learner Queries:

register/ok login/nok logout/nok register/ok register/nok register, login

Input Alphabet:

[register, login, logout]

  • k, ok

register/ok login/ok logout/ok */nok */nok */nok

slide-17
SLIDE 17

Model Learning

Learner SUL

Learner Queries:

register/ok login/nok logout/nok register register/ ok nok register, login

  • k, ok

register/ok login/ok logout/ok */nok */nok */nok

Hypothesis:

slide-18
SLIDE 18

Model Learning

Learner SUL

register/ok login/ok logout/ok */nok */nok */nok

Hypothesis:

Tester

slide-19
SLIDE 19

Model Learning

Learner SUT

Test Queries:

register register login/ok nok nok

register/ok login/ok logout/ok */nok */nok */nok

Hypothesis:

Tester tests

slide-20
SLIDE 20

Model Learning

Learner SUT

register/ok login/ok logout/ok */nok */nok */nok

Hypothesis:

Tester correct!

slide-21
SLIDE 21

Model Learning

Learner SUT Tester

New Hypothesis

new queries

slide-22
SLIDE 22

Model Learning

Learner SUL

New Hypothesis

Tester new queries correct! tests

slide-23
SLIDE 23

Model Learning

Learner/ Tester SUL

slide-24
SLIDE 24

Model Learning

Learner/ Tester SUL

login, logout

  • k, nok

SUL.login, SUL.logout true/false

abstract i/o (strings) concrete i/o method calls, returned obj. packets

slide-25
SLIDE 25

Model Learning

Learner/ Tester SUL

login_0 login_1 …

  • k, nok

login(uid)

  • k, nok

small abstract i/o alphabet parameterized i/o alphabet

slide-26
SLIDE 26

Model Learning

Learner/ Tester SUL Mapper

Mapper

  • 1. translates:

➢ between abstract and param. i/o ➢ between param. i/o and concrete i/o

login_valid SUL.login(“admin”) true

  • k

login(“admin”)

  • k

abstract i/o param i/o concrete i/o

slide-27
SLIDE 27

Model Learning

Learner/ Tester SUL Mapper

Mapper

  • 1. translates:

➢ between abstract and param. i/o ➢ between param. i/o and concrete i/o

  • 2. gives a (deterministic) Mealy Machine representation

➢ removes time dependencies, non-determinism..

slide-28
SLIDE 28

Model Learning

Learner Mapper

New Hypothesis

Tester queries correct! tests SUL concrete queries/tests

slide-29
SLIDE 29

Model Learning

Learner Mapper

New Hypothesis

Tester queries correct! tests SUL concrete queries/tests

Model Learning Spec. formalization SUL RFC Model Checking prop1_LTL prop2_LTL SUL: prop1_LTL prop2_LTL SUL:

slide-30
SLIDE 30

Model Learning

Learner Mapper Tester queries correct! tests SUL concrete queries/tests

TODOs:

  • 1. know your SUL
  • 2. define i/o alphabet
  • 3. implement mapper
  • 4. choose learner and tester algorithms
  • 5. connect and execute!
slide-31
SLIDE 31

Model Learning

Learner Mapper Tester queries correct! tests SUL concrete queries/tests

TODOs:

  • 1. know your SUL
  • 2. define i/o alphabet
  • 3. implement mapper
  • 4. choose learner and tester algorithms
  • 5. connect and execute!
slide-32
SLIDE 32

The SSH Protocol

➢ protocol for operating network services (e.g. terminal) securely over an unsecured network ➢ client/server application layer protocol, runs on top of TCP

CLIENT APPLICATION SERVER APPLICATION

UNSECURE NETWORK

slide-33
SLIDE 33

The SSH Protocol

➢ protocol for operating network services (e.g. terminal) securely over an unsecured network ➢ client/server application layer protocol, runs on top of TCP ➢ Learner + Mapper replaces the SSH CLIENT, goal learn the SSH Server!

LEARNER APPLICATION SERVER APPLICATION (= SUL)

UNSECURE NETWORK

Learner + Mapper

slide-34
SLIDE 34

The SSH Protocol

CLIENT APPLICATION SERVER APPLICATION

➢ comprises three layers which interoperate (no encapsulation) ➢ each layer responsible for each of the 3 protocol steps, ➢ for each we define the happy flow at an abstract level

UNSECURE NETWORK

User Authentication Layer Connection Layer Transport Layer TCP/IP Layer

slide-35
SLIDE 35

The SSH Protocol

CLIENT APPLICATION SERVER APPLICATION

UNSECURE NETWORK

➢ 3 steps

1. establish a secure connection ( by exchanging keys)

User Authentication Layer Connection Layer Transport Layer TCP/IP Layer

slide-36
SLIDE 36

The SSH Protocol

CLIENT APPLICATION SERVER APPLICATION

UNSECURE NETWORK

➢ 3 steps

1. establish a secure connection ( by exchanging keys)

User Authentication Layer Connection Layer Transport Layer TCP/IP Layer

slide-37
SLIDE 37

The SSH Protocol

➢ 3 steps

1. establish a secure connection ( by exchanging keys)

User Authentication Layer Connection Layer Transport Layer TCP/IP Layer

  • 1. exchange preferences (KEXINIT)
  • 2. perform key exchange (KEXxx)
  • 3. put new keys to use (NEWKEYS)
  • 4. engage the auth. service (SR_AUTH)

Happy flow: Other inputs: DEBUG, IGNORE, DISCONNECT.. Other outputs: DEBUG, IGNORE, DISCONNECT..

slide-38
SLIDE 38

The SSH Protocol

CLIENT APPLICATION SERVER APPLICATION

UNSECURE NETWORK

➢ 3 steps

1. establish a secure connection ( by exchanging keys)

User Authentication Layer Connection Layer Transport Layer TCP/IP Layer

slide-39
SLIDE 39

The SSH Protocol

CLIENT APPLICATION SERVER APPLICATION

UNSECURE NETWORK

➢ 3 steps

1. establish a secure connection ( by exchanging keys) key re-exchange (rekey): same procedure, old keys are replaced by new ones

can happen any time after the initial key exchange protocol should not affect operation of higher layer protocols

User Authentication Layer Connection Layer Transport Layer TCP/IP Layer

slide-40
SLIDE 40

The SSH Protocol

CLIENT APPLICATION SERVER APPLICATION

password auth user: john pwd: password auth successful

➢ 3 steps

1. establish a secure connection ( by exchanging keys) 2. authentication with server

User Authentication Layer Connection Layer Transport Layer TCP/IP Layer

slide-41
SLIDE 41

The SSH Protocol

➢ 3 steps

1. establish a secure connection ( by exchanging keys) 2. authentication with server

User Authentication Layer Connection Layer Transport Layer TCP/IP Layer

Happy flow: Other inputs: UA_NONE, UA_PK_NOK, UA_PW_NOK… Other outputs: UA_FAILURE

▪ user/public key auth. UA_PK_OK ▪ user/password auth. UA_PW_OK ▪ none auth. UA_NONE

slide-42
SLIDE 42

The SSH Protocol

CLIENT APPLICATION SERVER APPLICATION

password auth user: john pwd: password auth successful

➢ 3 steps

1. establish a secure connection ( by exchanging keys) 2. authentication with server

User Authentication Layer Connection Layer Transport Layer TCP/IP Layer

slide-43
SLIDE 43

The SSH Protocol

CLIENT APPLICATION SERVER APPLICATION

remote terminal request service accept

➢ 3 steps

1. establish a secure connection ( by exchanging keys) 2. authentication with server 3. access network services (say remote terminal)

User Authentication Layer Connection Layer Transport Layer TCP/IP Layer

slide-44
SLIDE 44

Learning SSH

➢ 3 steps

1. establish a secure connection ( by exchanging keys) 2. authentication with server 3. access network services (say remote terminal)

User Authentication Layer Connection Layer Transport Layer TCP/IP Layer

1) open channel (CH_OPEN) 2) request term. service over channel (CH_REQUEST_PTY) 3) channel data management (CH_SEND_DATA) 4) close channel (CH_CLOSE)

slide-45
SLIDE 45

Learning SSH

TODOs:

  • 1. know your SUL
  • 2. define i/o alphabet
  • 3. implement mapper
  • 4. choose learner and tester algorithms
  • 5. connect and execute!

Mapper task

1. translate between abstract, parametrized and concrete i/o

AUTH_PW_OK AUTH_REQUEST(“password”, “john”…)

slide-46
SLIDE 46

Learning SSH

TODOs:

  • 1. know your SUL
  • 2. define i/o alphabet
  • 3. implement mapper
  • 4. choose learner and tester algorithms
  • 5. connect and execute!

Mapper task

1. translate between abstract, parametrized and concrete i/o ➢ needs to be able to encrypt/decrypt compress/decompress ➢ stores information in variables: encryption keys, session ID, sequence number…  implemented by adapting an existing SSH suite implementation (Paramiko)

AUTH_PW_OK AUTH_REQUEST(“password”, “john”…)

slide-47
SLIDE 47

Learning SSH

TODOs:

  • 1. know your SUL
  • 2. define i/o alphabet
  • 3. implement mapper
  • 4. choose learner and tester algorithms
  • 5. connect and execute!

Mapper task

1. translate between abstract, parametrized and concrete i/o ➢ needs to be able to encrypt/decrypt compress/decompress ➢ stores information in variables: encryption keys, session ID, sequence number…  implemented by adapting an existing SSH suite implementation (Paramiko) 2. ensure deterministic Mealy Machine representation ➢ reliable setting of timing parameters (e.g. NO_RESP timing parameter)

false NO_RESP, mapper should have waited longer Learner Mapper Learner Mapper pkt pkt

slide-48
SLIDE 48

Learning SSH

TODOs:

  • 1. know your SUL
  • 2. define i/o alphabet
  • 3. implement mapper
  • 4. choose learner and tester algorithms
  • 5. connect and execute!

Mapper task

1. translate between abstract, parametrized and concrete i/o ➢ needs to be able to encrypt/decrypt compress/decompress ➢ stores information in variables: encryption keys, session ID, sequence number…  implemented by adapting an existing SSH suite implementation (Paramiko) 2. ensure deterministic Mealy Machine representation ➢ reliable setting of timing parameters (e.g. NO_RESP timing parameter) ➢ enforce one output per input by concatenating (‘_’) multiple responses to an input into one output

Learner Mapper Learner Mapper pkt1, pkt2 pkt1, pkt2

slide-49
SLIDE 49

Learning SSH

TODOs:

  • 1. know your SUL
  • 2. define i/o alphabet
  • 3. implement mapper
  • 4. choose learner and tester algorithms
  • 5. connect and execute!

Mapper task

1. translate between abstract, parametrized and concrete i/o ➢ needs to be able to encrypt/decrypt compress/decompress ➢ stores information in variables: encryption keys, session ID, sequence number…  implemented by adapting an existing SSH suite implementation (Paramiko) 2. ensure deterministic Mealy Machine representation ➢ reliable setting of timing parameters (e.g. NO_RESP timing parameter) ➢ enforce one output per input by concatenating (‘_’) multiple responses to an input into one output

Learner Mapper Learner Mapper pkt1, pkt2 pkt1, pkt2

slide-50
SLIDE 50

Learning SSH

TODOs:

  • 1. know your SUL
  • 2. define i/o alphabet
  • 3. implement mapper
  • 4. choose learner and tester algorithms
  • 5. connect and execute!

Learner Mapper Tester queries correct! tests SUL concrete queries/tests

LearnLib algorithms: L* , Observation Pack Tester Algorithms: Random Walk, W Method, Yannakakis (Random + Exhaustive)

slide-51
SLIDE 51

Learning SSH

TODOs:

  • 1. know your SUL
  • 2. define i/o alphabet
  • 3. implement mapper
  • 4. choose learner and tester algorithms
  • 5. connect and execute!

Note on testing:

➢ testing can never guarantee correctness ➢ exhaustive test algs. ensure a well defined level of confidence

➢ but lack penetration

➢ random test algs. have penetration  more likely to find CEs

➢ but give no formal confidence

slide-52
SLIDE 52

Learning SSH

TODOs:

  • 1. know your SUL
  • 2. define i/o alphabet
  • 3. implement mapper
  • 4. choose learner and tester algorithms
  • 5. connect and execute!

si sj

access sequence mid sequence (k length) adaptive sequence test structure

Example Yannakakis random: ➢ choose bigger k ➢ random mid sequences exhaustive ➢ choose smaller k ➢ generate for all mid-sequences ➢ attain confidence We used: Random Yannakakis(k=4) Exhaustive Yannakakis(k=2)

slide-53
SLIDE 53

Learning SSH

TODOs:

  • 1. know your SUL
  • 2. define i/o alphabet
  • 3. implement mapper
  • 4. choose learner and tester algorithms
  • 5. connect and execute!

Learner Mapper Tester queries correct! tests SUL concrete queries/tests

LearnLib: Observation Pack Paramiko Adaptation Yannakakis Tester SSH Server Implementations

slide-54
SLIDE 54

Learning SSH Results

Open SSH Learned Model

slide-55
SLIDE 55

Learning SSH Results

Open SSH Learned Model peculiarities:

  • authentication
  • rekey changes state
  • max one terminal
slide-56
SLIDE 56

Learning SSH Results

➢ rekey (3 step sequence) ➢ buffering ➢ mapper induced behavior

slide-57
SLIDE 57

Learning SSH Results

➢ rekey (3 step sequence) ➢ buffering ➢ mapper induced behavior

state permitting rekey rekey state

slide-58
SLIDE 58

Learning SSH Results

➢ rekey (3 step sequence) ➢ buffering ➢ mapper induced behavior ➢ remember, we learn SUL + mapper, not SUL alone

slide-59
SLIDE 59

Model Learning

  • Spec. formalization

SUL RFC Model Checking

prop1_LTL prop2_LTL SUL: prop1_LTL prop2_LTL SUL:

What was done

slide-60
SLIDE 60

Model Checking

➢ we used NuSMV: ➢ supports LTL, CTL and Real Time CTL specifications ➢ requires conversion to a .SMV model

slide-61
SLIDE 61

Model Checking

➢ we used NuSMV: ➢ supports LTL, CTL and Real Time CTL specifications ➢ requires conversion to a .SMV model ➢ wrote script to automatically perform this conversion Mealy Machine kripke structure with: ➢ state function(next) ➢ output function(out) NuSMV Model

slide-62
SLIDE 62

Model Checking

➢ we used NuSMV: ➢ supports LTL, CTL and Real Time CTL specifications ➢ requires conversion to a .SMV model Mealy Machine kripke structure with: ➢ state function(next) ➢ output function(out) NuSMV Model G (inp=BEGIN -> out=OK) G (out=OK -> X (inp=MSG -> out=ACK) ) G U (out=OK -> X (inp=MSG -> out=NOK))

slide-63
SLIDE 63

Model Checking

➢ we used NuSMV: ➢ supports LTL, CTL and Real Time CTL specifications ➢ requires conversion to a .SMV model Mealy Machine kripke structure with: ➢ state function(next) ➢ output function(out) NuSMV Model G (inp=BEGIN -> out=OK) G (out=OK -> X (inp=MSG -> out=ACK) ) G U (out=OK -> X (inp=MSG -> out=NOK))

slide-64
SLIDE 64

Model Checking

➢ we used NuSMV: ➢ supports LTL, CTL and Real Time CTL specifications ➢ requires conversion to a .SMV model ➢ specification either holds or counterexample (CE) given ➢ CE may ➢ agree with the SUL  non-conformance ➢ disagree with the SUL  a CE for the learner ➢ thus, all CEs must first be confirmed by running it on the system ➢ integrated model checker into testing s.t. all CEs are confirmed

Tester correct! tests Model Checker CEs

RFC

slide-65
SLIDE 65

Formalizing SSH Specifications

➢ LTL formulas with both forward and past modalities ➢ checked on the mapper + SUL assembly (not only on the SUL itself), thus results not fully translatable ➢ 4 types: ➢ basic properties: describe the SUL + mapper setup, all true ➢ security properties: define the overriding goal of each layer ➢ rekey properties: is rekey allowed (does it not disconnect) does rekey preserve state? ➢ functional properties: are MUST/SHOULD statements met

slide-66
SLIDE 66

Formalizing SSH Specifications

➢ basic properties ➢ security properties ➢ rekey properties ➢ functional properties

Only one SSH connection is made and once it is gone, it is gone.

G ( out=NO CONN − > G ( out=NO CONN | out=CH MAX | out=CH NONE) )

connection is gone mapper outputs (w/o SUL intervention) SUL no longer responds

slide-67
SLIDE 67

Formalizing SSH Specifications

➢ basic properties ➢ security properties ➢ rekey properties ➢ functional properties

We consider an transport layer state machine secure if there is: no path from the initial state to the point where the authentication service is invoked without exchanging and employing cryptographic keys.

G ( hasReqAuth − > O ( ( inp=NEWKEYS & out=NO RESP ) & O ( ( inp=KEX30 & out=KEX31_NEWKEYS) & O ( out=KEXINIT ) ) ) )

slide-68
SLIDE 68

Formalizing SSH Specifications

➢ basic properties ➢ security properties ➢ rekey properties ➢ functional properties

SSH_MSG_CHANNEL_CLOSE Upon receiving this message, a party MUST send back an SSH_MSG_CHANNEL_CLOSE unless it has already sent this message for the channel. (RFC 4254, p 9)

G ( hasOpenedChannel − > ( ( inp=CH CLOSE) − > ( out=CH CLOSE) ) W ( connLost | kexStarted | out=CH CLOSE) )

slide-69
SLIDE 69

Formalizing SSH Specifications

➢ basic properties ➢ security properties ➢ rekey properties ➢ functional properties

SSH_MSG_CHANNEL_CLOSE Upon receiving this message, a party MUST send back an SSH_MSG_CHANNEL_CLOSE unless it has already sent this message for the channel. (RFC 4254, p 9)

G ( hasOpenedChannel − > ( ( inp=CH CLOSE) − > ( out=CH CLOSE) ) W ( connLost | kexStarted | out=CH CLOSE) )  in red, predicates not expressed in RFC statement, yet deducted from context  formalization forces clarification

slide-70
SLIDE 70

Formalizing SSH Specifications

➢ basic properties ➢ security properties ➢ rekey properties ➢ functional properties

SSH_MSG_USERAUTH_SUCCESS MUST be sent only once. (RFC 4252 p. 5)

G ( out=UA SUCCESS − > X G out != UA SUCCESS)

SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication requests received after that SHOULD be silently ignored. (RFC 4252 p. 5)

G ( out=UA SUCCESS − > X ( ( authReq − > out=NO RESP ) W (connLost | kexStarted) ) )

slide-71
SLIDE 71

Formalizing SSH Specifications

➢ basic properties ➢ security properties ➢ rekey properties ➢ functional properties

key exchange does not affect the protocols that lie above the SSH transport layer. (RFC 4253 p. 24)

➢ state based property:  cannot be efficiently formulated by LTL  checked using script

slide-72
SLIDE 72

Model Checking Results

UA_SUCC once NO_RESP after UA_SUCC

(*X sends UNIMPL)

CH_CLOSE after CH_CLOSE

slide-73
SLIDE 73

Conclusions and Future Work

Conformance checking of the SSH protocol, using model learning & model checking

➢ inferred models for 3 SSH server implementations ➢ run extensive testing on models ➢ formalized and checked models against security properties, as well as server RFC MUST/SHOULD requirements ➢ found inconsistencies with limited security impact

Future work:

➢ formalize mapper so it is clear what it does (and a concretization can be made) ➢ make mapper abstraction less impactful  reduce num. of mapper induced states ➢ learn SSH client, model check assembly client/server ➢ replace classical learner by a register automata learner, extract parameters and infer their related behavior