12-NetSec SysHardening + Vuln mngmt edit...• Misuse detection àlist unwanted behaviour, report if...

NetworkSecurityAA2015/2016

Systemhardening(IDS,Vuln Management)

Dr.LucaAllodi

SomeslidesfromM.Cremonini

Dr.LucaAllodi- NetworkSecurity- UniversityofTrento,DISI(AA2015/2016)

1

IntrusionDetectionSystems


2

FunctionofanIDS

• Firewallspreventunwantedaccesstonetworkresourcesthatshouldbeisolatedw.r.t.anothernetwork

• IDSmonitorsincomingconnections• Dependingonitspositioninthenetworkmayprovidedifferentfunctionalities

• Moreonthislater

• IntrusionPreventionSystems(IPS)canactover“malicious”behaviour

• IDSà passivemonitoring• IPSà activemonitoring• Inrealityfunctionalitiesarenotentirelydistinct

• Commerciallingoratherthanactuallydifferenttechnology

Dr.LucaAllodi- NetworkSecurity- UniversityofTrento,DISI(AA2015/2016) 3

IDS– 3phases

1. Datacollection• Host-basedIDSà Sitonanhost(client,server)• Network-basedIDSà Collectsnetworkdata

2. Dataanalysis• Twodistinctapproaches• Misusedetectionàlistunwantedbehaviour,reportifdetected

• Anomalydetectionà buildaverageprofile,reportifcurrentactivitysignificantlydifferentfromaverage

3. Action• IDSà report,logentry• IPSà report,logentry,block/alert


Misusedetection

• IDSequivalentof“defaultallow”policies• ”blacklist”patternsthatarebelievedtoberelatedtomaliciousactivities

• Systemcalls• Payloadsinnetworkprotocols

• Signature-based• Verydiffuseddetectiontechnique• Easytodeploy• Typicalimplementationfornetwork-basedIDSs

• Asallblacklistingapproaches(signature-based)itcanonlydetectpatternsthatarealreadyknown


Anomalydetection

• Assumesintruderbehaviour differsfromlegitimateprofile

• Buildinglegitimateprofilemaybeanissue• Dependsondatausedforprofiling(e.g.sampledvswholedataset)

• Profilecanevolveà new“legitimateactivity”lookssuspicious

• CanbeusedbothforHIDSandNIDS• HIDSà syscall,systemfilehashing,systemstates,..• NIDSà protocolanalysis,similartoapplicationproxy

• Monitoringasopposedtofiltering


NetworkIDS

• Baselineimplementationisoftypemisusedetection

• Easiertoimplement• Networktrafficishardtopredictevenonwell-controlledenvironments

• Signatureexample:


alert tcp $EXTERNAL_NET any -> $HOME_NET 139 flow:to_server,establishedcontent:"|eb2f 5feb 4a5e 89fb 893e 89f2|" msg:"EXPLOIT x86 linux samba overflow" reference:bugtraq,1816 reference:cve,CVE-1999-0811

Thebase-ratefallacy– or,canwehaveactuallygooddetectionrates?• Bothanomalyandmisusesdetectionnecessarilyleadtofalsepositivesandfalsenegatives

• ANIDSwith99%truepositiverateand99%truenegativerateseemstohavehigh-reliabilityalarms

• à analarmfiresupà youshouldworry• à noalarmfiresupà allisgood• Butisit?

• Base-ratefallacy• SimplederivationfromBayestheorem• Verywellknownbymedicsanddoctors• StillmakingitswaythroughinInfoSec


Thebase-ratefallacy[Axelsson2000]• Testswithhightruepositivesandnegativesratesyieldmuch“worse”resultsthanexpectedbytheaverageuser

• RememberBayestheorem


• Let’smaketheclassicmedicalexample• Attack=illness• IDSAlarm=medicaltest

ThisisP(B)expandedtoall“n”casesforAthatBcomprisesP(A|B)

Base-ratefallacyexample

• A=eventispatientissick• B=medicaltestsayspatientissick• P(A|B)=patientisactuallysickgiventhattestsaidso

• Equivalentto“thereisanactualattackgiventhatNIDSfiredalarm”• SetTP=99%;TN=99%à P(B|A)=0.99• Diseasesarerare.Say1/10.000peoplehavetheillnessàP(A)=1/10.000

• Mostnetworktrafficislegitimate


P(A|B)

• Thereisonly1%chancethatpatientissickwhentestsaysso• Analarmisnotverymeaningfulà IDSalarmsarehardtomanageà loganalysis

P(A|B)

Base-ratefallacyandIDSs

Dr.LucaAllodi- NetworkSecurity- UniversityofTrento,DISI(AA2015/2016) 11Noticethatthefalsepositivesrateistheonethatdominates thecurve

Architecturalaspects

• ExternalNIDS• Analysisofallsetofincomingtraffic• Onlygeneralsignaturesarepossible

• highincidenceofFP• Alldetected“attemptedattacks”arelogged

• "normal"Internettraffic maygeneratemanyalarms

• InternalNIDS• Analysisoftrafficallowedbythefirewall

• Morespecificsignaturesarepossible

• e.g.basedonservicesbehindfirewall,subnetcharacteristics,..

• Saysnothingaboutattacksattemptedbutblockedbyfirewall


Internet

InternalNIDS

ExternalNIDS

NIDSoncomplexnetworks


Publicservices• Front-facing

webservers• Contentdelivery

systems

Datamanagement• Databases• Querybackend/

dataelaboration

Dataservers

Webservers

Applicationlogic• Backendmanagement• Dynamicpage

generation

Backend

Borderrouter(staticfiltering)

SecondlevelRouterIntranet

Internalclients

1. Generalrulesforinternettraffic• Alarmslowpriority

2. Detectionofgeneralattacksfortrafficallowedbyrouter

• Alarmslowpriority3. Twosetsofrules

a. Incomingtraffic• Mediumpriority (filteredby

firewall)b. Outgoingtraffic

• Lowpriority (intranet-generated)

4. Specialised alarms• e.g.SQLi signatures• Alarmshighpriority

172.16.0.0/16

172.17.0.0/16

172.17.1.0/24 172.17.2.0/24

NIDS

NIDS

NIDS

NIDS

1

2

3

4

Internet

NIDSevasion[Siddharth 2005]

• Signature-basedevasioncanbefairlytrivial• Dependsonimplementationofactualsignature

content:”/bin/bash” • à detectsremotecallstobash• Doesnotdetectstring“/etc/../bin/bash”,etc.

• MoreadvancedtechniquesaretypicallybasedonIPfragmentation

• Alltechniqueshavecommongoal:NIDSseesdifferentpacketthanclient

• Lookatthesekeepinginmindyoumaywanttopreventtheattackerfromperforming

• Networkmapping• OSfingerprinting


Evasiontechnique– Reassemblytime-out• NIDShaslowerreassemblytimeoutthanreceivingclient


Evasiontechnique– Reassemblytime-out(2)• NIDShashigher reassemblytimeoutthanreceivingclient


Evasiontechnique– Time-to-live

• Routerdropspacketanalysed byNIDSthatwillnotbedeliveredtovictim


Evasiontechnique– Fragmentreplacement• Someoperatingsystemsreplacefragmentswithnewerones,otherskeepoldfragments


Suggestedreading

• Wool,Avishai."Aquantitativestudyoffirewallconfigurationerrors."Computer 37.6(2004):62-67.

• Axelsson,Stefan."Thebase-ratefallacyandthedifficultyofintrusiondetection."ACMTransactionsonInformationandSystemSecurity(TISSEC) 3.3(2000):186-205.

• [Siddharth 2005]http://www.symantec.com/connect/articles/evading-nids-revisited


Vulnerabilitymitigation


20

Attacksurfaceminimisation inpractice- recap• Networkhardening

• Firewallsà blockunwantedtraffic• Defaultallowà easierconfiguration,lesssecureingeneral• Defaultdenyà cancausedisservicesfortheusers,highsecurity

• IDSà analyse trafficpayloadtocheckformaliciouspackets• Misuses detectionà signaturesthatmatchknownpayloads• Anomalydetectionà signalsbehaviour (host,network)significantlydifferentfromexpected

• Systemhardening• “can’tbreakwhat’snotthere”à trimsystemconfigurationtoonlyallowactionsthatareneededforsystemfunctionality

• Authenticationàminimise setofuseractionstominimal• Openvulnerabilitiesrepresentariskofincomingattacks

• Vulnerabilities patchesnotalways(immediately)possible• Mitigationtechniques


OSvulnerabilitymitigation– BoFvsDEPprotection

• Bufferoverflow• attackercanoverwritedatainstackwithexecutableshellcode

• Redirectexecutiontoshellcode• Butinstackthereshouldneverbecode,onlydata

• DataExecutionProtection(DEP)• Dataareasinmemoryaremarkedasnon-executable

• Hw supportà AMDNXbit,IntelXDbit

• Defeatscodeexecutionviastackcorruption

• DoesnotpreventcorruptionofHeaporredirectiontootherfunctionsinmemory


Startofstack

Endofstack

RETURN ADDRESS=kRETURN ADDRESS=K

k=c+n

newBuffer (128 bytes)

NOP

shellcode

shellcode...

… (NOP sled)

Exec

ution di

rection

shellcode

RETURN ADDRESS=KRETURN ADDRESS=K

RETURN ADDRESS=K

NOP

c+1

c

c-32

OSvulnerabilitymitigation- BoF vsASLR• WithDEPattackercanstillredirectexecutiontocodeareasinmemory

• e.g.writeastackframeinmemoryandpointtolib-corotherknownfunctions(thatareofcourseexecutable)

• Mostmemorycorruptionattacksrelyontheattackerbeingabletoguessstartaddressofstackframe/heap/otherareasinmemory

• e.g.writenbyteswithn=offsetbetweenbufferandRET• AddressSpaceLayoutRandomizationà ASLR

• Randomise locationinmemoryofstack,heap,libraries• Randomisationhappensinan-bitsspace

• WindowsVistaà 8bità 1/256guesseswork• Linuxà ExecShiel/PaX à 16bits


DEP+ASLR

• DEPà preventsexecutionofdatainmemory• Canstilljumptoexisting libraries

• ASLRà makesitmoredifficultfortheattackertocorrectlyguessmemoryaddressoflibraries

• Insomecases(e.g.lowmemory,olderimplementations) stillpossibletomakeaguess

• Advancedexploitationtechniquesredirectexecutiontoexistingcodeinmemory

• ReturnOrientedProgrammingà Turing-complete• BypassDEP• ASLRcanbebypassedtoo(mostapplicationsrunsw modulesinnon-randomised memoryareas)

• DEP+ASLRshouldbeusedtogether• Notperfectprotection

• à Vulnerabilitypatching


Vulnerabilitypatching

• Softwarepatchfixesvulnerabilityincode• ”Justinstallthepatch”approachdoesnotalwaysworkwell

• OSpatchesoftenrequiresystemreboot• Apatchmodifiessoftwarecode

• Softwarefunctionalitiesmaychange• Deprecatedthird-partylibraries

• Productionsystemsneedtobeupandrunning• Can’talwaysinstallpatch• Testpatchbeforeinstall

• Vulnerabilitypatchingiscostlyprocess• “getridofallvulnerabilities”isnotalwaysviable


Countingvulnerabilities!=securityassessment• Morevulnerabilitiesdonottranslatedirectlyinto“riskofattack”

• Wealreadyknowthatvulnerabilitiesenablethreatscenarioswithacertainimpactandacertainprobability

• Risk!=sum_v(severity_v)• CVSSmeasuresseverity

• Risk=f(impactxlikelihood)• CVSSdoesnotmeasurerisk

• Yet,securitystatusisoftenmeasuredbyhowmanyvulnerabilitieswehave

• SymantecThreatreport2015• Secunia Vuln report2011-2015• “Thegrayedoutsectionrepresentsthevendorwiththeworstsecurityofthemonth.” →


Doweneedtopatchallvulns?

• Let'slookatthenumbers• ExploitationLevel=EL• EL1→NVD:vulnerabilityisdisclosed• EL2→EDB:Exploit-DB,PoC existsandispublic• EL3→EKITS:datasetcollected@UniTn,infiltrationinundergroundmarkets→exploitistradedintheRussianCybercrimeMarkets

• EL4→SYM:vulnerabilityisreportedasexploitedinSymantec’sThreatExplorerdataset(atleastoneexploithasbeendetected)

• EL5→WINE:Symantecdatasetofdetectedattacksinthewildovermorethan1Msensors


CVSSvs exploitationlevels


LOWCVSS

MEDIUMCVSS

HIGHCVSS

EL:1

EL:3

EL:2

EL:4

Howtoevaluateariskmetric

• MuchlikewedidbeforetoevaluateeffectivenessofIDSalarms

• Evaluatetrueandfalsepositivesvsallalarms

• Sensitivityà truepositives vsall"sick people"• HIGHà thetestcorrectly identifies exploited vulns• LOWà lots of“sick people”undetected

• Specificityà true negatives vsall healthy people• HIGHà thetestcorrectly identifiesnonexploited vulns• LOWà lots of“healthy people” flagged

29

CVSSversusriskofexploitation

30

Sensitivity

SpecificityPCI-DSS

High+MediumCVSS(e.g.NISTSCAP)

Numericalexamples


Test forPatching Sensitivity SpecificityPatch Everything 100% 0%

CVSS High+Med 91% 23%

CVSS+PoC in EDB 97% 22%

CVSS+EKITS 94% 50%

3BT: DownSyndrome 69% 95%

PSA: ProstateCancer 81% 90%

CVSSdoesnotcorrelatewithrisk,buthowisriskdistributed?• HereweareatEL5• Evaluateoverallnumberofattacksinthewild

• Howmanyattacksdoesavulnerabilitydriveonaverage?• Answerisinnextslide


Vuln. Category Samplesoftware names No.ofvulns Attacks(Millions)PLUGIN Acrobatreader,FlashPlayer 86 24.75

PROD MicrosoftOffice, Eudora 146 3.16

WINDOWS WindowsXP, Vista 87 47.3

BROWSER InternetExplorer 55 0.55

Tot: 374 75.76

Distributionofattackspervuln


WINDOWS

log(attacks)

Frequency

0 2 4 6 80

510

1520

0 1 2 3 4 5 6 7 8

PROD

log(attacks)

Frequency

0 1 2 3 4 5 6 7

010

2030

40

0 1 2 3 4 5 6 7

BROWSER

log(attacks)

Frequency

0 1 2 3 4 5 6

05

1015

0 1 2 3 4 5 6

PLUGIN

log(attacks)

Frequency

0 2 4 6 8

010

2030

4050

0 1 2 3 4 5 6 7 8

0.0 0.2 0.4 0.6 0.8 1.00.0

0.2

0.4

0.6

0.8

1.0

WINDOWS

p

L(p)

0.0 0.2 0.4 0.6 0.8 1.00.0

0.2

0.4

0.6

0.8

1.0

PROD

p

L(p)

0.0 0.2 0.4 0.6 0.8 1.00.0

0.2

0.4

0.6

0.8

1.0

BROWSER

p

L(p)

0.0 0.2 0.4 0.6 0.8 1.00.0

0.2

0.4

0.6

0.8

1.0

PLUGIN

p

L(p)

% vulnerabilities % vulnerabilities % vulnerabilities % vulnerabilities

% a

ttack

s

• Lorentzcurveofattackspervulnerability• x-axis=percentageofvulnerabilities

receivinganL(p) fractionofattacks• AllcategoriesbutPLUGINsee10%of

vulnerabilities responsible for90%+ofattacks

• ExampleforPROD:• 7vulnerabilitiesreceive3.000.000attacks• 139vulnerabilitiesreceive100.000attacks

Riskofvulnerabilityexploitation-recap• Somevulnerabilitiesareexploitedseveralorderofmagnitudemorethanthe”average”vulnerability

• Risk=likelihoodofexploitationximpactofexploitation• Riskisnotuniformlydistributed

• CVSSmeasuresvulnerabilityseverity• Doesnotmakeaclaimtoestimateexploitlikelihood• Currently,bestavailablemeasure(worstcasescenarioisaccountedfor)

• Howtocalculateexploitationriskisstillanopenresearchproblem

• Technicalevaluations• Attackereconomics


Suggestedreading

• Allodi,Luca,andFabioMassacci."Comparingvulnerabilityseverityandexploitsusingcase-controlstudies."ACMTransactionsonInformationandSystemSecurity(TISSEC) 17.1(2014):1.

• Nayak,Kartik,etal."Somevulnerabilitiesaredifferentthanothers."ResearchinAttacks,IntrusionsandDefenses.SpringerInternationalPublishing,2014.426-446.


12-NetSec SysHardening + Vuln mngmt edit...• Misuse detection àlist unwanted behaviour, report if...

Documents

Transcript of 12-NetSec SysHardening + Vuln mngmt edit...• Misuse detection àlist unwanted behaviour, report if...