Mike Sheward<p>Mini Pen Test Diaries Story:</p><p>The target of the test was an enterprise web app, designed to be hosted and accessed from within a trusted network - like an enterprise LAN. Most customers would login to the app with SSO, or AD-integrated authentication, but it also supported a local login mechanism, so it could have its own accounts.</p><p>Although this app was designed to never go near the dirty dirty internet, we all know how companies be, so as part of the test, I decided to go looking around for any instances of it that may be out there. Plan wasn't to test them of course, not in scope, but I was curious to see how this software was actually being deployed in the real world.</p><p>After about 15 seconds on Shodan, I found dozens of instances of this thing out there on the Internet. From the screenshots of the login page, I could see that all of them were in local authentication mode - meaning, no third party or federated auth was being used.</p><p>I raised this as a finding in the report, mentioning that, "hey, although this isn't directly your issue, there are plenty of examples of your customers using your app like this, so...perhaps consider adding MFA to the local authentication provider, to add that layer of protection to the app? Lest one of your customers expose themselves in the same way that so many apparently have done so."</p><p>At report review time, the dev team was furious about this finding - "why, would you put this finding in our pentest report? It's not our issue whatsoever!"</p><p>So I calmly explained to them, "you're correct, not your direct issue, but you're the folks in the best position to fix it, right? The customers can't add MFA to your code, and clearly theres a reason your customers keep putting these things on the Internet? Have you asked them about it?" </p><p>They still weren't convinced at all. </p><p>Now, I've been doing this for a while, so used to push back from dev teams on certain things occasionally, but you know, this one seemed like a no-brainer, really.</p><p>I asked, who's gonna get the blame when these things get compromised by cred stuffing?</p><p>Who's IP is out there for other malicious actors to find and play with?</p><p>But still, they weren't having it.</p><p>There's no real magical ending to this one unfortunately. The software sits out there to this day, no MFA to be seen. But this one is a perfect example of why we often find ourselves in the situations we do in this industry.</p><p>An unwillingness to just do the right thing, simply because doing that thing doesn't exactly fall within your direct purview. </p><p>Even if, in this example, you didn't want to do MFA - just take the finding, and go ask your customers to take their instances of the internet. Be proactive. It would give your account execs a reason to talk to customers - they'd love it. </p><p>It's not always this way, but when it is, you can very easily understand the chain of decisions that lead to a number of the major breaches we seen on a daily basis. Don't be like these devs, think outside of the box. Or LAN, I suppose.</p><p>Want to read more, slightly less mini stories like this: <a href="https://infosecdiaries.com" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">infosecdiaries.com</span><span class="invisible"></span></a></p><p><a href="https://infosec.exchange/tags/infosec" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>infosec</span></a> <a href="https://infosec.exchange/tags/pentest" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>pentest</span></a> <a href="https://infosec.exchange/tags/pentesting" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>pentesting</span></a> <a href="https://infosec.exchange/tags/redteam" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>redteam</span></a></p>