Dear hackers: If you try to pwn a website for phishing, make sure it’s not the personal domain of a senior Akamai security researcher

July 30, 2019

Dear hackers: If you try to pwn a website for phishing, make sure it’s not the personal domain of a senior Akamai security researcher

Institute For Ethical Hacking Course and Ethical Hacking Training in Pune – India

Extreme Hacking | Sadik Shaikh | Cyber Suraksha Abhiyan

Credits: The Register

Exclusive Think you have bad luck? Imagine being the script kiddie who inadvertently tried and failed to pwn an Akamai security pro.

Larry Cashdollar, a senior security response engineer at the US-based global web giant, told us late last week he just recently noticed something peculiar in the logs on his personal website. Further investigation turned up signs of someone scanning for remote file inclusion (RFI) vulnerabilities.

Anyone in charge of public-facing servers will know these boxes come under continuous scanning and probing by miscreants, bots, and security researchers. However, in this particular case, Cashdollar has today helpfully documented his findings as a heads up, or warning, to website admins and webapp developers. If anything, you should ensure your software is not vulnerable to RFI, otherwise you may well fall to the same fools who tried to pwn the infosec engineer’s website.

He told The Register his site’s logs showed the would-be attacker probing for RFI holes that would allow them to trick web applications into fetching and running a remote malicious script. In this case, the scumbag was trying, unsuccessfully, to load a file via a custom tool Cashdollar had created for his site.

“Based on my log entries they appear to be parsing web sites looking for form variables and automatically testing if those variables allow remote file inclusion,” Cashdollar told El Reg.

“It’s a generic test against any website where they can parse out the form input variable and then supply a URL to that variable to see if the content is included and executed.”

Unfortunately for the attacker, Cashdollar also used the logs to follow the GET requests to the payload the attacker was trying to load: a script that attempted to harvest information about his server. By dissecting that and other files the hacker had ready to execute commands and take over vulnerable websites, Cashdollar was also able to extract the criminal’s email address and their preferred language – Portuguese.

While RFI exploits are usually performed to hijack a web server, in this case Cashdollar believes the attackers were trying something different: using file-injecting holes as a way to transform the site into a base for phishing. The miscreant’s arsenal of scripts included commands that would create HTML files on the victim’s server that mimicked the site of a popular European bank.

In other words, the attacker was probing for an RFI vulnerability that would allow them to quietly install phishing pages on the host server that masqueraded as a legit bank’s login webpage, and then direct victims to those pages to harvest their bank account credentials as they tried to log into the fake.

“It’s interesting to consider that of all the things the attacker could do with a system after discovering an RFI vulnerability, they chose to upload phishing landing pages rather than install a crypto currency miner or other means to monetize their access to the system,” Cashdollar explained.

“This is further proof that phishing is a profitable and highly-successful method of compromising credentials and victim information.”

The Akamai security engineer told El Reg that, for admins, the big takeaway from his experience is the importance of watching logs, patching site management tools, and writing web code that cannot be exploited for RFI.

“Make sure their application patches are up to date,” Cashdollar advised. “Keep track of any new vulnerabilities discovered in software they’re using for content management and site delivery and patch when new vulnerabilities are disclosed by the vendor.”