Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

News2 bytes


Published on

News bytes session

Published in: Education
  • Be the first to comment

  • Be the first to like this

News2 bytes

  1. 1. News Bytes by Shreyasi Rao
  2. 2. Overview 1. Ghost DNS 2. Facebook hacked 3. Whatsapp video call compromised. 4. Hacking into yCombinator HackerNews
  3. 3. GhostDNS: New DNS Changer Botnet • Between September 21 and 27, the GhostDNS campaign compromised greater than 100,000 routers (87.8% devices in Brazil) • Many similarities with the notorious DNSChanger malware. • It attempts to guess the password on the router's web authentication page or bypass the authentication through the dnscfg.cgi exploit, then changes the router's default DNS address to the Rogue DNS Server. • It is a real threat to the Internet as it is highly scaled, utilizes diverse attack vector, adopts automated attack process.
  4. 4. DNS Domain Name System • Resloves domain names to IP addresses. • Cybercriminals create DNS changer malware to modify the DNS settings of a system Resolver Server/ ISP Top Level Domain Server (.com, .net) Authoritative Name Server 13 clusters
  5. 5. . • DNSChanger worked by changing DNS server entries in infected computers to point to malicious servers under the control of the attackers, rather than the DNS servers provided by any ISP or organization. • The DNS changer malware did not target browsers, rather it targetted routers that run unpatched firmware or are secured with weak admin passwords.
  6. 6. How does Ghost DNS work?
  7. 7. . These four parts work together to perform DNS hijacking function. Here we call the whole campaign GhostDNS: • DNS Changer. This is the main module of GhostDNS designed to exploit targeted routers based upon collected information • Web Admin. It seems to be a web admin website on one of the PyPhp DNSChanger node for attackers secured with a login page. • Rogue DNS. Lets the hackers to figure out domain names from the attacker controlled web server. A total of 52 domains being hijacked. • Phishing Web. The rogue DNS server hijacks specific domains and resolves their IP addresses to the Phishing webserver, which will respond the victims with specific phishing sites for the corresponding hostname.
  8. 8. . label "Elite Priv8" on the login page of the Web Admin System. After some googling, researchers found the same description on a post on a Brazilian security forum IP address of Web Admin Server "AS16276 OVH SAS"
  9. 9. Below is the hijack result details of a rogue DNS server (
  10. 10. DNSChanger Module Includes 100+ attack scripts altogether, affecting 70+ different routers. It has three modules, which Netlab has dubbed Shell DNSChanger, Js DNSChanger, and PyPhp DNSChanger.
  11. 11. PyPhp DNSChanger • PyPhp DNSChanger, written in a combination of Python and PHP, is the most potent of all three. • Deployed on over 100 Google Cloud servers, from where the attackers are constantly scanning the Internet to identify vulnerable routers. The PyPhp DNSChanger node has infection statistics.
  12. 12. .It mainly composes of three parts: • Web API. Through which attacker can control and schedule to run the program conveniently. • Scanner. The scanner utilizes both Masscan port scanning and Shodan API service (to pick specific banners) to obtain target router IPs located only in Brazil. • Attack Module.This attack module totally includes 69 attack scripts against 47 different routers/firmwares. • It collects active router IPs from scanner and launchs Web authentication bruteforce or dnscfg.cgi vulnerability exploits to bypass authentication, after that it will change the routers' default DNS resolver to the rogue DNS server, which is used to hijack specific websites for phishing.
  13. 13. Preventions • The broadband users in Brazil update their router systems. • Check if the router's default DNS server is changed and set more complicated password for router web portal. • Router vendors increase the complexity of router default password and enhance the system security update mechanism for their products.
  14. 14. Facebook HACKED!!! • The company has said the cyber-attack disclosed on Sept 28 was one of the worst to hit Facebook. It affected 30 million people. • For 15 million people, attackers accessed two sets of information – name and contact details (phone number, email, or both, depending on what people had on their profiles). • For 14 million people, the attackers accessed the same two sets of information, as well as other details people had on their profiles. • This included username, gender, locale/language, relationship status, religion, hometown, self-reported current city, birthdate, device types used to access Facebook, education, work, the last 10 places they checked into or were tagged in, website, people or Pages they follow, and the 15 most recent searches. • For 1 million people, the attackers did not access any information.
  15. 15. How did this happen? • The attackers exploited a vulnerability in Facebook’s code that existed between July 2017 and September 2018. • The vulnerability was the result of a complex interaction of three distinct software bugs and it impacted “View As,” a feature that lets people see what their own profile looks like to someone else. • It allowed attackers to steal Facebook access tokens, which they could then use to take over people’s accounts. • Access tokens are the equivalent of digital keys that keep people logged in to Facebook so they don’t need to re-enter their password every time they use the app.
  16. 16. • First, the attackers already controlled a set of accounts, which were connected to Facebook friends. • They used an automated technique to move from account to account so they could steal the access tokens of those friends, and for friends of those friends, and so on, totaling about 400,000 people. • In the process, however, this technique automatically loaded those accounts’ Facebook profiles, mirroring what these 400,000 people would have seen when looking at their own profiles. • That includes posts on their timelines, their lists of friends, Groups they are members of, and the names of recent Messenger conversations.
  17. 17. How did Facebook find out? • They saw an unusual spike of activity that began on September 14, 2018. • So they started an investigation. • On September 25, they determined this was actually an attack and identified the vulnerability. • Within two days, they closed the vulnerability, stopped the attack, and secured people’s accounts by resetting the access tokens for people who were potentially exposed. • As a precaution, they also turned off “View As.” • Facebook continues to investigate the incident with the FBI. • This sort of personal detail can help identity thieves accomplish hacks for years into the future.
  18. 18. Don't pick up the whatsapp video call!!! Google Project Zero security researcher Natalie Silvanovich found a critical vulnerability in WhatsApp messenger that could have allowed hackers to remotely take full control of your WhatsApp just by video calling you over the app The vulnerability is a memory heap overflow issue triggered when the WhatsApp mobile application receives a malformed RTP packet (Real- time Transport Protocol) via a video call request, which results in the corruption error and crashing the WhatsApp mobile app.
  19. 19. WhatsApp: Heap Corruption in RTP processing To reproduce the issue: • 1) Apply the attached patch to in the Android application using bsdiff. this patch intercepts a memcpy right before srtp_protect is called, and alters the RTP buffer. The SHA1 of the original library used was cfdb0266cbd6877e5d146ddd59fa83ebccdd013d, and the SHA1 of the modified library is 042256f240367eaa4a096527d1afbeb56ab2eeb4. • 2) Build the attached file, natalie2.c for the Android device the application is running on, and copy it to /data/data/com.whatsapp/ • 3) Copy the files in the attached folder into /data/data/com.whatsapp/files so that /data/data/com.whatsapp/files/t0 is a valid location. • 4) Restart WhatsApp and call the target device and pick up the call. The deivce will crash in a few seconds.
  20. 20. . Silvanovich discovered and reported the vulnerability to the WhatsApp team in August this year. • WhatsApp acknowledged and • Patched the issue on September 28 in its Android client • and on October 3 in its iPhone client.
  21. 21. Hacking into yCombinator HackerNews • An exaple of a true whitehat hacking ft. dfranke • The news.yc code, prior to the the release of arc3, contains a remotely-exploitable vulnerability permitting account theft. • Hacker News login cookies are random eight-character strings, stored server-side in a hash table mapping them to user names. • These strings were rather less random, and, through a delightful combination of exploits, could be predicted, enabling an attacker to steal accounts.
  22. 22. . Here's the rand-string function from arc.arc, version 2. It gets called with n=8 to generate login cookies, and n=10 for the "fnids" that get used all over the site as hash keys identifying closures. (def rand-string (n) (with (cap (fn () (+ 65 (rand 26))) sm (fn () (+ 97 (rand 26))) dig (fn () (+ 48 (rand 10)))) (coerce (map [coerce _ 'char] (cons (rand-choice (cap) (sm)) (n-of (- n 1) (rand-choice (cap) (sm) (dig))))) 'string)))
  23. 23. .• The 'rand' function is an arc primitive, bound directly to mzscheme's 'random': The comment seen here is prescient, as we'll see. The mzscheme's 'random' fn: ; need to use a better seed (xdef 'rand random) static long sch_int_rand(long n, Scheme_Random_State *rs) { double x, q, qn, xq; /* generate result in {0..n-1} using the rejection method */ q = (double)( (unsigned long)(m1 / (double)n) ); qn = q * n; do { x = mrg32k3a(rs); } while (x >= qn); xq = x / q; /* return result */ return (long)xq; }
  24. 24. • It was obviously, not a cryptographically strong PRNG. It was possible that someone could break it but was TOO MUCH MATH! • So he went looking for an easier approach. Where does the RNG seed come from? Ah ha The random seed is merely the number of milliseconds since epoch at the time the seed function was called rs = scheme_make_random_state(scheme_get_milliseconds()); long scheme_get_milliseconds(void) { struct timeb now; ftime(&now); return now.time * 1000 + now.millitm; }
  25. 25. • For starters, he thought, perhaps I could determine the server's start time to within a few seconds or minutes. A boring way to go about this would be simply to monitor the server for downtime, and record when it became accessible again. a more proactive approach: crash it!
  26. 26. • A few months ago news.yc recovered from some downtime and the server had since been upgraded, so these crashes are/were no longer happening. • He figured that the watchdog works by requesting a page and checking to make sure it gets a response, and that if it doesn't get one, then it assumes the server is wedged and restarts it.
  27. 27. • So, there's a limit of 50 concurrent threads, and threads are killed after 30 seconds if they haven't already terminated. So if I were to hold open 50 concurrent connections, and the watchdog were to run during the following 30 seconds, then the server ought to restart. • So, a one-minute interval is 60,000 possible PRNG seeds. • If he kept polling to see when the server came back up after the watchdog killed it, then he very conservatively assumed that he could be among the first 50 people to issue an HTTP request. • Each page that comes back from the server typically contains 2-3 fnids, so the reply he got would contain some from among first few hundred to be generated, and thus from among the first few thousand iterations of of the PRNG. • This leaves determination of the PRNG seed comfortably within the reach of brute force: run the PRNG for 10,000 iterations for each of the 60,000 possible seeds, and see which one produces the fnids he saw in response to his request and wrote a program that does just this
  28. 28. • So now he was able to determine PRNG seeds. • But only a tiny fraction of rand-strings that the server generates correspond to login cookies. • Since fnids and login cookies have different lengths, and since the PRNG gets called for a few other purposes at unpredictable times. • Every individual PRNG iteration begins a candidate login cookie. That's 40 or more false candidates produced for every page view. • If each page view produces an average of 50 candidates, and one in every thousand page views is a login (this might be slightly optimistic), that's 50,000 attempts necessary in order to find a working login. HN gets about 500,000 hits on a busy day, so this could be done in a day or two while likely staying under the radar.
  29. 29. • To login:- • 1. Request a page. Find a generated fnid from the page source and look it up in our candidate list. Call this A. • 2. ERC> /join #startups <dfranke> Hey guys, I haven't been able to log in to news.yc since the server restarted a little while ago. Anyone else having problems? <jrandomsucker> dfranke: Works for me. <dfranke> Hmm, weird. I'll just try again later I guess. • 3. Request another page, note the fnid, find it in the candidate list. Call this B. • Step 4: Test the cookies that fall between A and B. If this conversation takes one minute, then this reduces the search to about 17,500 attempts -- less than a day's worth at a modest rate of querying -- and possibly picks up multiple accounts in the process.
  30. 30. In the End • His better implementation of rand-string which reads from /dev/urandom and obeys a proper uniform distribution was implemented in arc3. • The 50-thread concurrency limit was removed and replaced with a per-IP rate limiter, so the DoS attack described here should no longer work.
  31. 31. References • 100000-are-being-hijacked-by-ghostdns-en/ • hack-exposed-user-location-search-data • • •