1.3 -Given a scenario, analyze potential indicators associated with application attacks. Flashcards

Given a scenario, analyze potential indicators associated with application attacks.

1
Q

Privilege escalation + mitigation

A

-perps explot sys. processes to gain higher level access
-gives them more capabilities
-by vuln, bug, design flaw,etc

mitigation
-patch vulns
-update antivirus/antimalware
-data execution prevention (only data in executable areas can run)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Cross-site scripting (XSS)

A

-web apps allow attacker to perform HTML injection which inserts their HTML code into a web page
-often exploit “reflected input”
-another technique is to store XSS code on remote web server (stored XSS)
-“persistent” b/c they stay on server even when perp isn’t there
-causes usr to conduct unauthorized access activities, expose confidential data > usr unaware of participation

Mitigation
-devs must perform “input validation”
-apps shouldn’t let user include

 tag in a reflected input field
-determine type of input app will allow > validate input to ensure it matches pattern
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Injections

A

-injects code into app > changes way it executes
-app should be able to handle input/output properly > allows processing of invalid data
-data types: HTML, SQL,XML,LDAP, etc

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Injections - Structured query language (SQL)

A

-targets database
-modifies SQL requests
-code inserted in strings > passed to database server > server parses + executes code

Chapple 145-148
Weiss 39-40

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Injections - Dynamic-link library (DLL)

A

-targets apps
-inserts malicious code into running processes
-injects DLL > app runs program + runs as part of target process
-proper input validation CAN’T PREVENT
-difficult to trace attack
-Win. uses protected process sys. > ensures only trusted code loads

Prevention
-secure coding practices
-keep sys. patched
-proper input validation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Injections - Lightweight Directory
Access Protocol (LDAP)

A

-targets directory servers
-modifies LDAP requests 2 manipulate app results
-malicious input applied to directory server
-unauthorized queries, granting of permissions, pswd changes, etc
- similar to SQL injection

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Injections - Extensible Markup Language (XML)

A

-XML=rules 4 data transfer + storage
-targets apps
-manipulates app logic
-gains unauthorized access
-performs unauthorized activity
-modifies XML requests

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Pointer/object dereference

A

-app attempts to access/modify portion of data that’s expected to be valid but is null (invalid/reference points to nothing)

Indicators
-crashes
-data corruption/unexpected data modification
-app errors/unexpected app behaviors

Prevention
-safe coding practices
-use of safe pointer libraries
-static code analysis
-dynamic analysis + testing
-mem. safety mechanisms
-reg. software updates
-sec. education

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Directory traversal

A

-AKA path traversal, dot dot slash
-exploits insufficient input validation to access files/directories outside intended directory structure
-takes advantage of poorly written code
-can allow perp to view source code for sites public directories + files
-can lead to unauthorized access, disclosure of sensitive info, remote code execution

Indicators
-unexpected file access
-multiple/repeated reqs
-disrupted services

Prevention
-input validation
-whitelists
-sec. awareness training
-access ctrls
-web app firewalls
-reg. sys. audits
-system hardening

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Buffer overflows

A

-perp manipulates program into placing more data into mem. than what’s allocated for programs use

-overwrite info in mem. with instructions that can be executed by a dif. process running on sys.

-enabled perp to execute code outside specific app

-tends to persist 4 many yrs after it’s initially discovered

-takes time

-perp can obtain special privileges.

-usr gaining privileges wthout authentication

Impact
-disruption of service + lost data
-crashes + failures
-DoS

Prevention
-quality assurance
-secure programming practices
-software updates/patches
-monitor web 4 new vuln.
-devs need to perform bounds checking

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Race conditions, indicators, prevention

A

-when code seq. compete over same resource/data concurrently

-can be bad if unplanned

-perp can exploit sys. processes to gain privilege escalation

-sec of code segment depends upon the sequence of events occurring within the system (Chapple 171)

Indicators
-malfunction
-DoS
-data corruption
-crashes/unpredictable app behavior
-null pointer errors (app gets pointer that it expects to be valid but is null which results in sys.crash)
-data integrity issues

Prevention
-synchronization mechanisms
-atomic ops
-transaction handling
-code reviews/testing
-use of thread safe libraries

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

TOCTOU

A

Time of check/time of use (race condition) AKA TOC/TOU

-takes advantage of time delay btwn checking something and usage of something

-sec. vulns. where sec. of sys. is dependant on timing of certain ops

-issues arises when condition is checked at one point in time but the state of system changes b4 corresponding op is performed

-window btwn creates opportunity 4 perp to manipulate/exploit resource in unexpected way

-race condition that occurs when program checks access permissions too far in advance of a resource request (Chapple 172)

Indicators
-inconsistent resources states
-data corruption/integrity issues
-unpredictable app behavior
-unauthorized access

Prevention
-minimize time gap btwn chcek and use phases (to reduce window of opportunity 4 perp)
-atomic ops
-file locking
-time of use checks
-access ctrls
-consistent state management
-secure coding practices
-dev should evaluate access permissions at the time of each request rather than caching a listing of permissions (Chapple 172)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Error handling

A

-the way sys. responds to unexpected events, errors, conditions
-proper error handling = crucial 4 maintaining sec + stability of sys.

Indicators
-error msgs revealing sensitive info
-app crashes
-incorrectly handled inputs

Prevention
-customized error msgs
-input validation
-graceful degradation
-logging + monitoring
-user education
-secure coding practices
-regular sec. audits

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Improper input handling

A

-sys. doesn’t adequately validate, sanitize, or handle usr inputs
-can open door to attacks (injection, buffer overflows, etc)

Indicators
-injection attacks
-unexpected app behavior
-data corruption/manipulation
-error msgs wth sensitive info

Prevention
-input validation
-parameterized queries
-secure coding practices
-use of web app firewalls
-regular sec. audits
-check everything

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Replay attack

A

-perp takes advantage of info transmitted over net. > info can help perp replay data 2 appear as someone else
-packets captured using sniffers > info extracted > packets placed back on net.
-need access to raw data (EX: net. tap, ARP poisoning, malware on vics comp.)

Protection
-> secure protocols (EX: IPsec = prevents replays of data traffic + provides authentication/encryption
-> avoid with SALT > use session ID wth pswd hash > creates unique authentication hash each time
-timestamp associated wth packets OR time valued, non repeating #s

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Replay attack - Session replays

A

-web apps assign usrs session IDs (often stored in cookie)
-perp gets session ID + uses to appear as authorized usr in app
-when perp gets cookie > can manipulate cookie to alter details sent back to site OR use cookie as badge req. to gain access to site

Prevention
-end to end encryption > can’t capture if they can’t see it
-protect cookie theft by marking cookies with the “SECURE” attribute > secure cookies r never transmitted over unencrypted HTTP connections
-HTTPS
-TLS

17
Q

Integer overflow

A

-result of arithmetic op.
-tries to store integer that’s too large to fit in specified buffer
-specific to whole #s
-variant of buffer overflow

18
Q

Request forgeries

A

-types of attacks that take advantage of how web servers handle URLs
-exploit trust relationships + attempts to have usrs execute cmds against remote server unwittingly
-two types > Cross site (CSRF) + server side (XSRF)

19
Q

Server side request forgeries (SSRF)

A

-occurs when an app processes user provided input to make requests from server to other resources on same/dif. net.
-perp finds vuln. web app > sends requests to web serv. > serv. performs request on perps behalf
-to compromise info from web serv. OR
-> enable more attacks (bypass input validation ctrls)
-> enable perp to execute more cmds
-exploits trust relationships

Consequences
-lead to unauthorized access to internal sys.
-data exposure
-remote code execution

server side = performs requests from the client (HTML, PHP), transfers $ from one acct to another

Causes
-bad programming
->never trust usr input
->serv. should validate input + responses

Prevention
-proper input validation
-list of allowed domains + protocols should be required (whitelist)

20
Q

Cross-site request forgeries (XSRF/CSRF)

A

-takes advantage of trust web app has 4 usrs sys. > execute cmds on usrs behalf
-wthout usrs consent/knowledge
-one click attack, session riding
-perp prepares special URL initiated on the client side from the web browser

client side = renders pg. on screen (HTML, javascript)

Protection
-devs create web apps that use secure tokens > perp wouldn’t know it to embed in the links
-sites check referring URL in requests from end usrs > only accept requests originating from own site

21
Q

Application programming
interface (API) attacks

A

-exploiting vuln. in interfaces used btwn diff. software apps
-gain unauthorized access, manipulate data, disrupt services

Indicators
-unusual API req.
-abnormal API traffic patterns
-auth. failures
-service disruptions
-unauthorized access

Prevention
-API sec. best practices
-encryption
-rate limiting
-API monitoring + logging
-auth. mechanisms
-API sec. testing
-web app firewalls
-education + awareness

22
Q

Resource exhaustion

A

-sys. or app becomes overwhelmed + depleted of resources
-can lead to degraded performance, service disruption, sys. failure
-may consume all of mem., storage, processing time, etc available to them

Indicators
-sluggish sys. performance
-frequent crashes/downtime
-unresponsive/sluggish apps
-service outages

Prevention
-capacity planning
-rate limiting
-monitoring + alerts
-load balancing
-resource limiting
-failover mechanisms
-resource mgmt
-antivirus
-monitor + filter incoming archive files

23
Q

Memory leak

A

-unused mem. not released
-grows in size + eventually uses all available mem.
-resource exhaustion occurs if unaddressed

Indicators
-slow op/degraded performance
-unresponsiveness
-sys. crashes/freezes
-inefficient mem. usage
-sys. instability

Prevention
-code review + testing
-use of automated tools
-memory profiling
-reg. maintenance + updates
-resource monitoring
-automated testing 4 mem. mgmt

24
Q

SSL stripping (Secure Sockets Layer)

A

-downgrades secure HTTPS connection to unsecured HTTP connection
->makes it easier to intercept/manipulate sensitive info
-takes advantage of how many sites off both HTTPS and HTTP connections
->perp tricks vic into using unsecured version

indicators?
-unencrypted connection
-missing padlock icon
-HTTP instead of HTTPS in URL
-unexpected login prompts
-altered content

mitigation
-usrs should be cautious about accessing websites via unsecured nets.-
-educate usrs
-use secure/up to date browsers
-implement policy on company devices
-enable secure cookies 4 usrs

25
Q

Driver manipulation

A

-unauthorized modification of device drivers
-attack often result of mal. written code for sys. device drivers to modify their behavior
-2 concepts related (shimming, refactoring)

Process can be legit. to….
->improve performance
->ensure compatibility
->improve sec.

why?
-compromise sys. integrity
-gain elevated privileges
-execute mal. activities

Indicators?
-unexpected changes in driver files
-unusual sys. behavior
-sys. crashes
-unauthorized access/modification of sensitive data
-abnormal net. traffic

26
Q

Shimming (driver manipulation)

A

-aka API hooking (intercepts API calls)
-perp inserts code/software btwn components
->to intercept/modify comm. btwn them
-typically operates @kernal level (inside OS) = harder to detect

shim = piece of code between two components that’s then capable of intercepting calls (API calls)

why?
-manipulate sys. behavior
-exploit vuln.
-gain unauthorized access

indicators?
-unexpected sys. file changes
-abnormal net. traffic
-unusual sys. behavior
-unexpected popups/alerts
-changes in app behavior (crash, freeze, etc)

Mitigation
-monitor sys. integrity
-update/patch software
-use sec. software to detect/defend
-implement least privilege
->app and usr privileges

27
Q

Refactoring (driver manipulation)

A

-process of restructuring existing code/software wthout changing its external behavior
-standard practice in software dev.
-improves code quality/manageability + reduces complexity
-perp can refactor code + trick sys. into using manipulated driver

Indicators
-code anomalies
-increased bug frequency
-unauthorized access points
-sec. vuln.

End users
-app instability
-changes in usr interface
-new features/capabilities

Prevention
-verify trusted code wth cryptographic techniques
-code reviews
-secure coding practices
-comm. wth end usrs about updates/changes

28
Q

Pass the hash

A

-form of REPLAY attack
-against OS (not web apps)
-perp captures hashed creds of usr -> uses hash values to authenticate to sys. wthout needing actual plaintext pswd
-effective against sys. that use hashed pswds 4 authentication

Indicators
-unusual acct activity
-multiple logins from diff. locations
-failed authentication attempts
-acct lockouts
-unexpected acct activity

Prevention
-strong authentication mechanisms
-use of Kerberos or Win. authentication protocols
-regular pswd changes
-sec. awareness training
-monitoring + logging
-privilege mgmt

29
Q

Horizontal privilege escalation

A

-perp wth certain level of access attempts to gain access to more accts/resources at same privilege level
-perp aims to move laterally within same privilege tier

Indicators
-unusual acct access patterns
-multiple concurrent logins
-account lockouts
-access to unusual resources

Prevention
-least privilege
-reg. access reviews
-usr behavior analytics
-net. segmentation
-MFA
-logging + monitoring
-sec. awareness training