Hack The Company - Challenges

Each challenge is based on a historical hack that occurred.

Background

In 2012, John McAfee (founder of anti-virus company McAfee) was on the run from the police after one of his neighbors was found shot dead.

While on the run, he blogged about his adventures and conducted media interviews. One such media interview involved VICE, who breathlessly published a piece entitled "We Are with John McAfee Right Now, Suckers".

As it happens, in their article the VICE authors included a photo they took from their Apple iPhone 4S, which included GPS coordinates in the EXIF data of the photo, publicizing the location McAfee was hiding at.

Additional Reading: Similar Attacks:

Challenge

Find John McAfee's location. The flag is the name of the nearest gas station that is NOT named Shell.

Scope:

[Walkthrough]

Background

Not too long in the past, flash games were all the rage online - particularly in forums that had them integrated. These flash games often had high score boards.

The problem with these games is that they ran on the client-side, and then after the game ended they would submit an api call to the backend with the user's score... and even 10 years ago this was trivial to intercept and modify, which many people did, dominating the high score boards.

Additional Reading:

Challenge

Beat the highest score on the game to get the flag.

Scope:

[Walkthrough]

Background

In June 2010, a group calling themselves Goatse Security extracted 114,067 records from AT&T iPad users. These records included an email address and an ICC-ID (which is a unique identifier for the SIM card associated with a mobile device).

This hack was done using a minor convenience feature which pre-populates your email address on a form on your iPad when you sign up for 3G service. To power this convenience feature, an api call takes as input an ICC-ID and returns any email address connected to that ICC-ID. The api call checked the User-Agent header to ensure it was coming from an iPad, but that was it as far as security went.

Goatse Security noted that the ICC-IDs were essentially just a large number (e.g. 89014104243219000000). By manipulating the digits on the end and passing that to the api call, the call would return another user's email address. They wrote a script to automate this, and extracted 114,067 themselves. They also shared the script and an unknown number of records were retrieved by other actors.

This data uncovered who early adopters of the iPad were, including numerous people in the Department of Defense, the military, and even William Eldredge, who "commands the largest operational B-1 [strategic bomber] group in the U.S. Air Force."

This type of Enumeration vulnerablility has been the culprit behind a lot of data leaks in recent years.

Additional Reading: Similar Attacks:

Challenge

A whitehouse person was one of the first people to obtain an iPad - the flag is their email address.

Scope:

[Walkthrough]

Background

In March 2014, an IP address from New York city logged into Flexcoin ("the Bitcoin Bank") on two separate accounts. The first account held 1 bitcoin, and the second account was empty. The attacker rapidly sent a multitude of requests to send his 1 bitcoin from his first account to his second account. A number of the transactions went through, and his second account now held several bitcoins, and his first account held NEGATIVE bitcoins. Elated, the hacker proceeded to login to a third account, and repeated the process, sending a multitude of bitcoin transfer requests from his second account to his third account - and his second account went negative and his third account received more bitcoins than he started with.

Eventually the hacker had an account with 896 bitcoins, and he withdrew them - leaving Flexcoin to keep his other accounts with negative bitcoins. This race condition attack allowed the attacker to siphon around $600,000 and destroyed the bitcoin exchange Flexcoin.

This attack has been successfully used in a wide variety of settings, such as cryptocurrency exchanges, gift card balances, and beta invitations.

Additional Reading: Similar Attacks:

Challenge

Go from 5 BTC to 10000 BTC, making money out of thin air by exploiting a race condition.

Scope:

[Walkthrough]

Background

BlackNova Traders is a web-based, multi-player space exploration game inspired by the popular BBS game of TradeWars. It is coded using PHP, SQL, and Javascript.

In 2013, ITTIHACK published a SQL Injection vulnerability he found on an inconspicuous page for the game, the news page - which merely displays recent events that have occurred in the universe, and is available both when logged in or logged out.

Blacknova Traders is well protected against SQL Injection, so how did this one slip through the cracks? Two causes likely contributed.

First, to a programmer at first glance it may not appear like a user input. The 'date' parameter is automatically generated in a specific format by PHP and embedded in a GET parameter of a url link on the page. When users click that link, that date value is submitted to the PHP code again. It's never technically edited by the user, but both generated by PHP and then read again by PHP. A developer might pass over this when looking to secure user input, since the user is not expected to edit this - but that's a mistake, as the user CAN still edit it in the URL!

Second, the value was inputted into a SQL query not as a normal string or integer, but rather as a date like so: WHERE date > '{$startdate} 00:00:00'. One way to sanitize integer input is by typecasting it to an integer in PHP before passing it to the SQL query. The developer here may have felt like the input was being typecast to a date automatically, by being compared to a date and including the '00:00:00' in the string. However, that typecast to a date was occuring in SQL, rather than in PHP before being passed to SQL - and if an attacker can edit the SQL, he can bypass that typecast.

Additional Reading: Similar Attacks:

Challenge: Warm-up

Use SQL Injection to login and obtain the flag. This is the archetypical SQL Injection example.

Scope:

[Guide: OWASP]

Challenge: Blacknova Traders

Use SQL Injection to obtain the password of the ship/user named [email protected] - their password is the flag.

Scope:

[Walkthrough]

Challenge: Wrap-up

Use SQL Injection to login and obtain the flag. This is the archetypical SQL Injection example, with filtering enabled to prevent usage of slashes or whitespace.

Scope:

[Guide: Reiners' Weblog Intro]
[Guide: Reiners' Weblog Cheatsheet]

Background

We've all heard about SQL Injection attacks from form inputs and url parameters... but what about less common attack vectors, such as via HTTP headers? Stackoverflow is inundated with questions of people asking whether this is even possible, with few solid answers.

Not only is it possible, but it's actually a common enough attack - particularly with the way PHP handles IP Addresses.

In 2016, Gwendal Le Coguic was working on a bug bounty project against a Wordpress site. Scanning the plugins installed, he found the plugin Image Gallery by Huge-IT.

Downloading the plugin and scanning through its PHP files, he looked for file upload and SQL injection issues. In gallery-images.php, he found that in the huge_it_image_gallery_ajax_callback function a variable called $huge_it_ip was used numerous times in SQL queries, and did not appear to be sanitized.

In looking at how that variable was defined, he saw it was set to $_SERVER['HTTP_X_FORWARDED_FOR'], though if that value was blank then it was set to $_SERVER['REMOTE_ADDR'].

Jackpot. HTTP headers cannot be trusted, as the user can manipulate them just like form inputs or url parameters. While browsers usually don't expose interfaces to manipulate them, you can install a browser extension to be able to edit them, or just do the same request in a CURL command from terminal.

Gwendal edited his X-Forwarded-For header to contain an injection, and got a successful SQL Injection. He reported the issue to the plugin creator, who patched it within 1 day.

Additional Reading: Similar Attacks:

Challenge

When you create an account and login, you'll see the flag is only visible to users with a user_level of 1. Use SQL Injection while logging in on the X-Forwarded-For header to adjust your user_level and retrieve the flag.

Scope:

[Walkthrough]

Background

In 2017, toctou discovered a vulnerability on news.starbucks.com. It started when he noticed some parameters were passed in to a url when a "download all media in this article" button was clicked. He tweaked those parameters and got various error messages.

Googling those error messages, he found only three results, two of which pointed to a PHP file named mod.zoo_flexible_admin.php that showed up on searchcode.com - this file was related to a mod for ExpressionEngine, an open source CMS.

Perusing that code, he found a variable that was unsanitized and passed directly to a database query. Bingo - a sql injection! He reviewed the variables he needed to pass to trigger that code and attempted it. He was successful! It was a blind SQL injection, but he was still able to exfiltrate data using a time-based attack.

He reported the vulnerability to Starbucks, who fixed it within two weeks.

Additional Reading: Similar Attacks:

Challenge

There exists in the database a table name with the prefix "flag_". Extract the full table name using blind SQLi to obtain the flag.

Scope:

[Walkthrough]

Background

In 2017, George Mauer published a blog post talking about a an old vulnerability that has never really gone away, and isn't widely discussed.

This vulnerability is called CSV Injection. Mauer outlined a common enough scenario of where this can happen.

Imagine a ticket tracking app, or a time tracking app. Users can enter in a ticket (or their time) in a web form, but cannot view those of other users. A site administrator then comes along and exports entries to a csv file, opening it up in a spreadsheet application. No big deal, right?

Turns out, it can be a very big deal. What if someone submitted an Excel formula, such as "=2+2"? In the CSV file, this is treated as just a string - but when the CSV is opened in Excel, this formula is evaluated.

It turns out there's a lot of things you can do with formulas in Excel. For example, there exist functions like "IMPORTXML" in Google Sheets or "WEBSERVICE" in Excel which let you query an external url, and you can pass as parameters values from other cells in the spreadsheet. Put another way... any user who can submit a ticket (or their time) can submit a formula that extract any value from that spreadsheet and submits it to a website they control - leaking that data.

Google has a service called "Google Forms" which allows you to collect form inputs and store them in a Google Spreadsheet automatically - essentially automating the step of the CSV import into a spreadsheet. This service is not vulnerable to having a formula injected, and is fairly popular. People like it enough that its sprung knock-off guides on how to have an HTML Form submit to a Google Spreadsheet - such as this fairly popular guide by David McCoy. McCoy's guide (which is the first in search results on the topic) is indeed vulnerable to formula injection, just like a normal CSV injection (though the CSV import step is automated).

Additional Reading:

Challenge

An admin periodically downloads all support tickets into a CSV file, and then loads it Google Sheets.

The flag is hidden in a support ticket a user filed recently. Submit a support ticket yourself with an injection to extract the flag.

Scope:

[Solution]

Background

While scanning the Alexa Top 1 Million websites, slashcrypto discovered that www.ebay.co.jp/.git/ was exposed to the world. Using a tool published by interwache in 2015, this allowed slashcrypto to download all the source code for www.ebay.co.jp - which included database passwords.

Slashcrypto notified ebay, who patched this within 12 hours. Ebay did not have a cash bug bounty in place, but they did add him to their Hall of Fame, and a $500 donation was made to a charity of slashcrypto's choice.

This issue has been around for a long time. In 2012, SkullSecurity found the same issue in a pen test he conducted. In 2014, I (the creator of this site) found the same issue in the wild at a startup I'd just joined. In that case, the deployment mechanism was zipping up the code, copying the zip file to the server, and then unzipping it - which in the case of this startup's PHP website, accidentally included and served up the /.git/ folder.

Additional Reading: Similar Attacks:

Challenge

The flag is contained in the source code of the index.php page.

Scope:

[Solution]

Background

On March 12, 2018, internetwache published a blog post wherein they scanned the Alexa top 1 million websites for exposed '.DS_Store' files. A '.DS_Store' file is an automatically created file on Mac OSX that stores meta information about the files and folders in its directory - including, interestingly, filenames.

Interwache found that of the 1 million top sites, approximately 1% of them had exposed '.DS_Store' files (likely implying a developer was developing on a Mac and accidentally uploaded/committed this file). For each '.DS_Store' file found, they parsed its contents to see what files it exposed as existing on each webserver. It found a number of backup files, including things like "wp-config.php.bak" and "index.php.bak", along with zipped files (source code?), ".doc" files, ".sql" files, and more.

These files were not intended to be publicly available, and their only 'security' lay in people not knowing how to access them... but these '.DS_Store' files exposed their existence and how to access them.

Additional Reading:

Challenge

The flag is contained in a hidden file in the web directory. Use the DS_Store file to determine the correct file name and access it to retrieve the flag.

Scope:

[Solution]

Background

In 2017, the hacker known as "Alex" posted a lengthy, entertaining blog post about how he hacked his friend Diane (with her permission).

There are a lot of details we won't get into here, but one part is particularly noteworthy. Alex put Diane's email into haveibeenpwned.com and found out that Diane's email and hashed password were leaked in a 2013 tumblr database breach.

He did some googling, and found a link to a place he could download the 2013 tumblr database leak from. Upon downloading, he then ran something like "grep '[email protected]' Tumblr_2013_users.txt". This resulted in a string like "[email protected]:3a1920ceb2791d034973c899907847cb58810808".

Jackpot! Or... was it? It turns out, the tumblr breach's passwords were not JUST hashed, but also salted. This means before each password is hashed, an extra string was added to the end of each password - so instead of hashing coolchic64, they'd hash coolchic64Htc42V8. Since we don't know the salt they used, that means these hashed passwords are practically useless.

But practically is not completely! As it turns out, tumblr stuck the same salt (in our example, Htc42V8) to the end of every password. This isn't considered best practice, as it means users with the same password have the same salted password hash.

So now Alex searched the tumblr breach for Diane's password hash (instead of her email), and he found about 20 other users with the exact same password hash (and thus the same password).

Betting on the fact that at least some of those 20 people re-used the same password across multiple sites, Alex downloaded the 2012 LinkedIn database breach, which had unsalted passwords. Looking up those 20 people and cracking their matching unsalted hashes, he found most of them had identical passwords to each other on LinkedIn - which was the same password all 20 of them (including Diane) must have been using on tumblr.

Additional Reading:

Challenge

The flag is the password of [email protected] from the 2013 tumblr database breach. Obtain it using the same methodology as Alex did to find Diane's password.

Scope:
  • You'll have to obtain the 2013 tumblr and 2012 LinkedIn database breaches on your own


[Solution]

Background

Shortly after lunch, on March 19, 2016, a Russian intelligence operative named Lukashev settled down at his desk to craft an email. He starts typing "Hi John. Someone just used your password to try to sign in to your Google Account [email protected]". He adds in some fake detailed information to make it look real, and then inserts his bait - a call to action, a convenient button in the email that when clicked will let Podesta immediately change his password to secure his Google account.

Of course, clicking that button won't actually take Podesta to Google's websites. Instead, it takes him to a bit.ly shortened url, which Lukeshev had setup earlier with his account "john365gh". The bit.ly url then redirects Podesta to a website Lukeshev setup that looks like an exact clone of the Gmail login screen, but when the login form gets filled out, instead of logging Podesta in it will send the credentials to Lukeshev.

For the finishing touch, Lukeshev spoofs the from address on the email with "Google <[email protected]>" and then hits send.

Back over in America, Podesta receives this email from "Google"/Lukeshev, and scratches his head. He thinks it's a scam, but doesn't know. He forwards it to Sara Latham, who forwards it to their IT Help Desk technician Charles Delavan. Charles takes one look at it and laughs to himself - it's clearly a fake phishing email. He quickly responds "Sara, this is a legitimate email." Wait a second... legitimate? As it turns out, Charles made a typo and had intended to say "not a legitimate email".

Sara receives Charles response, and interprets it exactly as its written - this is a real email and Podesta needs to take action. She replies to Podesta "The gmail one is REAL". Podesta sees her response and goes to reset his password. He clicks the helpful link in the email to change his password, and fills out the form. Task completed, he archives the email and moves on with his day.

Back in Russia, nearly 10 hours have elapsed since Lukashev sent the email. It's getting close to midnight, but as he's about to turn in his cell phone beeps. He looks, rubs his eyes, and looks again. The SMS was from his team, and said they just recovered Podesta's password, and are hopping on now to download all the emails. Lukashev grabs his coat - it's going to be a long night.

Additional Reading: Similar Attacks:

Challenge

Login to the website as Podesta to obtain the flag. Podesta will click all links sent to him by Charles, his trusted IT help desk friend. If the link contains a login form identical to the website below, Podesta will attempt to login.

Scope:

[Solution]

Background

In 2015, some executives at a Ukrainian bank woke up and realized they were missing a bunch of money. Reviewing their security cameras, they saw their ATM machines dispensed a bunch of cash in the early morning hours to people who never bothered inserting their ATM cards.

The bank hired Kaspersky Lab to check it out. At first, the investigators thought the hackers had infected the ATM machines locally with a handheld device. Further investigation proved that was not the case - instead, they found the culprit was emails.

In a classic spear-phishing attack, the hackers (known as FIN7) had sent emails to the bank's employees with malicious attachments. The emails were spoofed to appear to be from suppliers such as ATM manufacturers. When opened, the attachments downloaded a trojan and gave a backdoor to the bank's network.

Using this backdoor, the hackers dropped a piece of malware called ATMitch onto the bank ATMs that gave them the ability to dispense money at any time, at the touch of a button.

Additional Reading: Similar Attacks:

Challenge

Send an email to BankExec from ATMSupplier with a malicious attachment. BankExec automatically trusts all emails ATMSupplier sends him, and will execute any attachments. The flag is in the file "flag.txt" on BankExec's computer.

Note: BankExec is running on a Linux x64 machine, and does not have java/flash/Adobe Acrobat/Microsoft World installed - but he has been known to execute binaries.

Scope:

[Solution]

Background

In 2005, Clive Goodman (a reporter working for News of the World) discovered a trick that let him find out all sorts of exclusive information.

Clive knew if he used his own phone number to call Prince William's personal cell phone, Prince William simply would not answer and his voicemail service would pick up and request that Goodman leave a message after the beep.

To try to get Prince William to pickup, Clive could 'spoof' his number, and make his phone number appear to be coming from Prince William's mother (for example). However the Prince would immediately know something was wrong and be concerned if his phone said his mother was calling, and when he answered Clive was on the line.

To avoid that problem, Clive decided to 'spoof' the Prince's own number so it appeared to the Prince that he was receiving a call from himself. The Prince may attribute that to just a software error, and would not be immediately concerned, but would likely answer.

So Clive did exactly that - he called Prince William's number, while 'spoofing' that the call was coming from that same number. To his surprise, the phone didn't even ring - it went straight to voicemail and started playing back Prince William's voicemail messages. The very first one was about some pain Prince William experienced in his knee.

Clive took his newfound knowledge and published an article about Prince William's knee problems. He continued using this 'spoof' trick to obtain all sorts of information by 'hacking' people's voicemails, and then published what he had discovered. This eventually caught up to him, and was part of what became known as the News International phone hacking scandal.

Additional Reading: Similar Attacks:

Challenge

The hacker formerly known as prince has a voicemail on his phone that contains the flag. Retrieve it.

Scope:
  • "The hacker formerly known as prince"'s phone number: (314) 441-3417


[Solution]

Background

Bank of America offers "Text Banking" from the number 692632 (a short code). As you interact with their service, you establish a 'thread' of messages between them and you.

In 2017, a North Carolina resident named Yanon Gray received a new text message from Bank of America. This message was a notification from BoA to Yanon, informing him that his account is limited, and he should open the link in the SMS message to update his personal information. Upon clicking the link, you're taken to an official-looking BoA page that asks you to update your personal information like name, date of birth, and driver's license number.

The text message was not actually from Bank of America. If he input that information, it would be sent to the hackers. The whole process very closely mimics that of email spoofing, with one major difference.

People trust texting and are less suspicious of it than email. Additionally, if the hacker spoofed BoA's mobile banking number and made it appear like his text message was from 692632... it would actually appear in the thread of conversation you've had with the real BoA in your phone. It would be indistinguishable from the other, valid messages in that thread.

Additional Reading: Similar Attacks:

Challenge

Login to the website as Janon Grey to obtain the flag. Janon Grey will open all links sent to his phone number FROM his bank's phone number. If the link contains a login form identical to the website below, Janon will attempt to login. (Note: Text messages should SOLELY contain the link with no other text, in the format http://examplesite.com)

Scope:
  • Website
  • Janon Grey's phone number: (314) 441-3417
  • Bank's phone number: (989) 704-6016


[Solution]

Background

PlanetPoker was an internet cardroom that offered real-time Texas Hold'em games against other people on the Web for real money. Gambling with real money online requires trust in the people who control the system, so they published their shuffling algorithm to help demonstrate the game's integrity.

Some software developers from Reliable Software Technologies looked at the shuffling algorithm and immediately began to suspect there might be a problem. In a real deck of cards, there are 52! (approximately 2^226) possible unique shuffles. Through systematic analysis of the shuffling algorithm, these developers were able to reduce the possible unique shuffles from this computer algorithm to 200,000 for a given game.

A mere 200,000 possibilities is easy for a computer to search through. These devs build a proof-of-concept that takes as input 5 cards (the two cards the player is dealt, and the first three community cards called the flop). It then started going through the 200,000 possible shuffles, and stopped when it found a match that would deal out those 5 cards. Once found, it would then reveal the cards every other player had, as well as the last 2 hidden community cards.

Additional Reading: Similar Attacks:

Challenge

To obtain the flag, score 40 or better in this High/Low card game. To do this, you will either need to be extremely lucky or compromise the random number system used to shuffle the deck.

Scope:

[Solution]

Background

In 2018, Blaklis hacked one of Facebook's servers. It was not a server with user's specific data on it, but it was a Facebook server nonetheless. How did he do it?

The first step was in finding a Django (Python) server hosted on a Facebook IP address. He noted that Debug mode was turned on for this server. Note that Django has a big warning to "Never deploy to production with debug mode turned on!" in their docs. People who publicly question why are told "it'll let people hack into your server easily" and "it's a gaping security hole", but nobody explains how or why...

Blaklis can tell you why. As he probed this Django server with debug mode turned on, he got a debug error page to display. This displays all the variables set in the Django settings file (minus a few white-listed sensitive ones). One of those variables told him the application was using signed pickled cookies, and another variable gave him the private signing key used for the cookies.

Using that signing key, Blaklis was able to sign his own cookie with an arbitrary string. He crafted a string which when unpickled would execute code he specified. He then signed this string with the signing key he had obtained and sent it to the server in a cookie. The server received the cookie and executed his code. Facebook granted a $5000 bug bounty for his find.

Additional Reading: Similar Attacks (Information Leakage) Similar Attacks (Pickle Code Execution)

Challenge: Debug Mode

The flag is the environmental value COOKIE_SESSION_STORAGE_SIG, which can be accessed from a debug error page.

Scope:

[Solution]

Challenge: Signed Pickled Cookies

Craft a cookie to achieve code execution and exfiltrate the contents of "flag.py" to get the flag.

Scope:
  • Website
  • The "COOKIE_SESSION_STORAGE_SIG" value from Challenge A, which is actually the Cookie Signing Private Key for the pickled cookies.


[Solution]

Background

You've heard of SQL Injection, but have you heard of SQL Truncation? It's a rarer form of attack, but it still does exist in the wild.

In December of 2016, Dhaval Kapil came across a code sample that exhibited this error. His blog post on the topic is an excellent introduction (and serves as the concept behind the warm-up challenge).

In August of 2008, Stefan Esser discovered a SQL Truncation vulnerability in Wordpress 2.8.1. He found that when open registration is activated, a user can register the name "admin", followed by 55 spaces, followed by a letter 'x'. This will pass the 'does user already exist' check, and then gets inserted into the database as simply "admin" followed by 55 spaces (but truncating the "x").

Since SQL ignores trailing whitespace (it's used as padding to compare strings of different lengths), that means he now had control of an account that would match the SQL query "SELECT * FROM users WHERE username = 'admin'". Stefan then looked through Wordpress to see how he could leverage this account, and hit paydirt in the password reset feature. When the password reset is triggered with the email address of the fake admin, Wordpress creates a random password reset token, and then writes it to the database as the current password reset token for both the fake admin account and the real admin account. The token is then sent to the email of the fake admin. When the fake admin uses the token, Wordpress resets the password of the first user the token is valid for - which is the real admin user. It then generates a random password and emails it to the real admin.

At this point, Stefan had successfully reset the admin's password to a randomly generated password. He then combined this attack with another one where he can discover the seed used for the random number generator that created the new admin password. Using the seed and the same random number generator, he was then able to re-create the new random admin password.

Additional Reading:

Challenge: Warm-up

Using SQL Truncation, successfully login to the admin's account to retrieve the flag.

Scope:

[Solution]

Challenge: CVE-2008-4106 + CVE-2008-4107

Using SQL Truncation, reset the admin's password in Wordpress to a randomly generated password (CVE-2008-4106). Retrieve that randomly generated password by utilizing the information in the blogpost on the target site to determine the seed.

Scope:

[Solution]

Background

In 2014 Kaspersky Lab outlined a CSRF attack that was primarily targeting people in Brazil.

The attacks started with a spam/phishing email that asks users to click on a link. The link leads to a staging website that loads specially crafted urls (or forms) that trigger CSRF attacks on a user's router.

The premise is that a router is usually not visible to the external internet, but is visible to users connected to the router. A bad guy cannot open your router's configuration panel, but he can trick your computer into opening your router's configuration panel in the background - and through a CSRF attack, he can make your machine issue a request to your router to update the DNS server it is using.

And that's the crux of the attack. Many routers support Basic Authentication to login to their control panels, which can be passed via the url (e.g. http://admin:[email protected]) - and many routers have common default passwords like admin/admin. These things aid in making the CSRF attacks possible.

Once the attacker has updated your router's DNS server to a malicious server in the attacker's control, you're in a bad spot. The next time you load bitcoinbank.com (for example), your router will query the attacker's DNS server to ask what IP address the url bitcoinbank.com should point to. Instead of giving the correct response, the attacker's DNS server will then say "send them to this IP address that I control, where I've put up a spoofed login page for bitcoinbank.com". If you login to that spoofed page, the attacker will now have your login credentials - and why wouldn't you, since you're on the correct url after all, and the page looks correct?

Additional Reading:

Challenge

To obtain the flag, login to JDawg's Bitcoin Bank account. To do so, you'll need to use a CSRF Attack against JDawg's router to point his router to use a DNS server that you control - then, when JDawg next attempts to load the Bitcoin Bank website, have your DNS server point him to a website you control instead that has a spoofed login page for Bitcoin Bank that will capture his credentials.

Scope:
  • JDawg's Email Address: [email protected]
    Note that JDawg will click all links sent to him, but he always logs into Bitcoin Bank manually by typing the address into his browser's address bar.
  • Router Login page - This is YOUR personal router login page (similar to Netgear's routerlogin.com or TPLink's tplinkwifi.net). Anything changed in the settings here has no affect on JDawg. You can use it to figure out what kind of CSRF attack you need to send JDawg to update his router, which happens to be this exact same type.


[Solution]