Credential-Probing Attacks
TripAdvisor Security Guild
2017-08-17
Copyright By PowCoder代写 加微信 powcoder
¡ñ What a credential-probing attack looks like
¡ñ How to detect it
¡ñ How to blunt an attack in progress
¡ñ Industry best-practices
¡ñ Key take-aways
TripAdvisor detected a credential-probing attack the evening of April 24, 2017, based on a large event spike within our registration member audit logging. We determined that the attacker was playing credentials from list(s) compiled from other compromised sites around the ¡®net. This first attack was dubbed the ¡°Trusov¡± attack given the owner of all involved subnets was ¡° Igorevych.¡± Using the patterns established in the Trusov attack, we uncovered a few other attacks, occurring over 15 intervals.
We believe the intent of this probing activity was to validate the credentials to increase value for resale. All compromised accounts were re-secured. There was no indication of fraudulent activity, or a data breach within TripAdvisor.
Anatomy of a Probing Attack | Precursor
¡ñ The perpetrator conducts manual testing to understand our flows, the required format of requests, and expected responses
¡ð This activity is lost in the noise of normal site behavior
¡ñ There is often a sentinel account that the perp uses to verify that the attack
configuration is still valid before opening the floodgates
¡ñ When the probing is detected, using the pattern or identifying the sentinel
account to look for the original testing is our best chance to catch the criminal
Anatomy of a Probing Attack | Detection
¡ñ The attacks may be highly distributed, making them difficult to detect and block via DoS filters
¡ð Trusov featured > 100 subnets from around the world, including the U.S., with ~41 K possible IP addresses
¡ñ Once the probing attack is underway via a botnet, it can still be hard to detect an anomaly in the context of general traffic
¡ð Having specific signals for suspicious behavior is critical
¡ð The event rate is substantially higher if you know what to look for…
Anatomy of a Probing Attack | Detection
¡ñ Long-lived login events ¡ð TA_LOGIN
¡ð Looks fine
¡ñ E-mail as the source ¡ð TA_CREDENTIALS
¡ñ Password update required
¡ð TA_UPDATE_PASSWORD_REQUIRED ¡ð Uh, oh!
Anatomy of a Probing Attack | Detection
¡ñ Kibana was invaluable for rapid data mining and investigation
¡ð Community-team Kibana – Ops dashboard and investigation tool
¡ð ¡°ELK¡± stack: ElasticSearch, Logstash, Kibana
¡ñ The TA_UPDATE_PASSWORD_REQUIRED event saved the day, but wasn¡¯t the best event to use as a signal.
¡ñ We added events for failed password attempts per e-mail and invalid e-mail login attempts (no such user).
¡ð Clear indicators of illegitimate behavior in bulk
¡ð These events were deliberately omitted in initial build; thought to be
extraneous data. We hadn¡¯t considered this scenario.
Anatomy of a Probing Attack | Detection Now we have a consistent, clear signal, with alerting
Anatomy of a Probing Attack | Thwarting
¡ñ Trusov attack
¡ð Identified the common network provider owner using ¡°whois¡± on IPs
¡ð Forced Captcha on for the Russian Federation and Ukraine (53% of IPs)
¡ð Subnets were added to DoS filters, supplementing individual IPs
¡ð Ops implemented better DoS capabilities that allowed for CIDR* rules
going forward
¡ñ User Agent (UA) attack
¡ð Added UA rewrite rules to block specific, illegitimate user agents
¡ñ These are small hurdles to overcome for a dedicated attacker
¡ñ Recent enhancements
¡ð Additional technical requirements for API registration or login
¡ð Invisible Captcha, always on for registration and login * CIDR = Classless Inter-Domain Routing
Anatomy of a Probing Attack | Thwarting
Following the steps noted the previous slide, Trusov probed us again on 5/4. We improved blocking verification of pwned accounts by orders of magnitude.
Anatomy of a Probing Attack | Remediation
¡ñ Identified compromised accounts by mining logs for successful logins using irregular patterns that included:
¡ð UserAgent string
¡ð IPs and subnets (identified by network provider ownership)
¡ð Omission or repetition of spoofed device id(s)
¡ñ All accounts were re-secured by resetting the password to a strong, random value, and invalidating logged-in sessions.
¡ñ Users were notified via e-mail of suspicious activity, and encouraged to change their passwords where they might be used elsewhere.
¡ð Some states and countries require this communication, though we all agreed it was the right thing to do.
¡ð The passwords were invariably used elsewhere, since there was no data leak at TripAdvisor
¡ñ Logins issued were legit email/password credentials
¡ð Our brute-force attack security measures weren¡¯t tripped
¡ð Our network and server security wasn¡¯t compromised
¡ñ We determined passwords were not guessed
¡ð Used internal anti-fraud tools to determine there was a low frequency of
similar passwords across the millions of requests
¡ð That conclusion was reinforced using the new FAILED_PASSWORD_ATTEMPT
event to determine only 1-2 attempts were made per e-mail account
¡ñ There was no data breach
¡ð Our internal member DB contains many testing accounts that don¡¯t exist in the wild
¡ð These accounts can be used as ¡°honeypots¡± to detect an internal breach. They were not probed.
¡ñ We were lucky
¡ð We detected the attack, because old accounts needed to update
non-SSL-created passwords. The botnet caused those events to fire at an
abnormal rate.
¡ð We historically had Logstash import errors that caused all ElastAlerts to
fire with regularity. This made it difficult to tell a true signal from noise.
We fixed this right around the time of the April probing.
¡ñ Probing had been going on periodically since November, 2016. April
represented a huge ramp-up in volume.
Industry Security Notes
We met with the security team from another online travel website to trade notes. Our collective conclusions were:
¡ñ Captcha is the best protection against botnet attacks
¡ñ A WAF appliance (web application firewall) can protect your site from
hackers and would-be criminals.
¡ð You need to train the appliance to recognize legit traffic patterns from
irregularities.
¡ð It¡¯s huge time investment to set up, requiring around a year of training
to become reliable
¡ð The WAF automatically blocks traffic by IP/Subnet/CIDR when it
detects abnormalities
¡ñ Probing attacks have ramped up significantly since November, 2016
¡ð Dealing with these events is the new ¡°normal¡±
Take-aways
¡ñ You will be attacked
¡ñ Captcha is an easy-to-deploy security mechanism
¡ñ You must be able to measure and detect anomalies
¡ñ Visualizing anomalies via an Ops dashboard is super-helpful
¡ñ Automated alerts help you respond in near-real time
¡ñ Consider how your data is secured and gated.
¡ð If an account is compromised, don¡¯t leak critical information
¡ð Obfuscate email addresses, phone numbers, and credit card numbers
¡ö xxxxxxxxxxx5007, expires 04/20 (just like a receipt)
Questions?
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com