News bytes session

1. News Bytes
by Shreyasi Rao

2. Overview
1. Ghost DNS
2. Facebook hacked
3. Whatsapp video call compromised.
4. Hacking into yCombinator HackerNews

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. 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. .
• 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. How does Ghost DNS work?

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. .
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
198.50.222.139
"AS16276 OVH SAS"

9. Below is the hijack result details of a rogue DNS server (139.60.162.188)

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. 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. .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. 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. 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. 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. • 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. 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. 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.

20. WhatsApp: Heap Corruption in RTP processing
To reproduce the issue:
• 1) Apply the attached patch to libwhatsapp.so 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/libn.so.
• 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.

21. .
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.

22. 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.

23. .
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)))

24. .• 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;
}

26. • 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;
}

27. • 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!

28. • 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.

30. • 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

31. • 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.

32. • 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.

33. 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.

34. References
• https://blog.netlab.360.com/70-different-types-of-home-routers-all-together-
100000-are-being-hijacked-by-ghostdns-en/
• https://www.bloomberg.com/news/articles/2018-10-12/facebook-s-recent-
hack-exposed-user-location-search-data
• https://newsroom.fb.com/news/2018/10/update-on-security-issue/
• https://bugs.chromium.org/p/project-zero/issues/detail?id=1654
• https://news.ycombinator.com/item?id=639976