Evil Portal Fix on Hak5 Pineapple Mark VII
Perhaps you've upgraded to the newest Hak5 Pineapple Mark VII. For the most part, your old tricks will work but there are some changes that broke the Evil Portals. I knew the scripts were working because the .logs
file was populating with credentials but the dashboard had zero notifications for when the page was rendered or quick visualizations of the captured accounts.
Getting Started
You can pretty much setup everything the same as the steps provided in my prior article on fixing Evil Portal for the Pineapple Tetra. That will get the the pre-made repository of portals installed and a starting point for the scripts.
The only real difference is in how the Mark VII's firmware "looks" for installing the Evil Portal module but the process is identical to prior Pineapple's.
Fix One
For each installed portal, the MyPortal.php
file needs a small modification. The prior guide had single quotes in place to address a hyphen string between two PHP variables. It turns out that was not entirely necessary but will break the solution for the Mark VII. The reason for this will become evident on the second fix.
$this->notify("[creds] $email ' - '$pwd");
$this->notify("[creds] $email - $pwd");
Fix Two
A change needs to be made to the master Portal.php
file in the Evil Portal module. This file can be found in the /pineapple/modules/evilportal/assets/api/
directory. The highlighted change below will correct the self.notify()
function to work again.
protected final function notify($message)
{
$this->execBackground("notify \"{$message}\"");
$this->execBackground("PYTHONPATH=/usr/lib/pineapple; export PYTHONPATH; /usr/bin/python3 /usr/bin/notify info '{$message}' evilportal");
}
The problem was twofold. On the Mark VII, the /usr/bin/notify
utility is purely in Python. Prior versions of the Pineapple only required Evil Portal to do $this->execBackground("notify \"{$message}\"");
. When the function was called, it passed the command directly into an exec()
whose shell instance did not include the Python environment nor implicitly load the utility into Python. This was found by comparing the execution environments of the at now
job by delaying them for a minute and comparing the difference between what Evil Portal created and what running it raw from the command line created.
The second part was that /usr/bin/notify
now included two additional parameters aside from just the notification message. Prior to the message, options like "success" or "info" could be passed which would color code the notification on the Pineapple's dashboard. An optional trailing parameter could name a module, like "evilportal" to create a clickable link from the notification to jump to the module. These were easy to slip into the command but required more judicious attention to quotation marks since the message now required them to delineate it from the other parameters.
Fix Three
Technically, that's all that needs to be updated for Evil Portal to work again. But if you're interested in getting a notification that the page actually rendered, some tweaks to the detection script are necessary to account for the additional /usr/bin/notify
parameters. After following the instructions from the above link, look for the following lines in the ep_detect.sh
script file.
/usr/bin/pineapple/notify "[EP] " $host " " $ip " " $mac
echo $line >> /root/ep_notified.log
These lines will change to reflect the following. It was necessary to build the message string in advance in order to keep the quotation marks clean for passing to the /usr/bin/notify
utility.
message=`echo "[EP] " $host " " $ip " " $mac`
/usr/bin/notify success "$message"
printf "$line \t $mac $host\n" >> /root/ep_notified.log
Summary
The changes are small and all stem from a change to the notification utility and the execution environment used during the exec()
spawned shell. Once implemented, the Mark VII will be providing useful notifications and indicators of success again.