<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>General Thoughts on 0x2142 | Networking Nonsense</title>
    <link>https://0x2142.com/categories/general-thoughts/</link>
    <description>Recent content in General Thoughts on 0x2142 | Networking Nonsense</description>
    <image>
      <title>0x2142 | Networking Nonsense</title>
      <url>https://0x2142.com/logo.jpg</url>
      <link>https://0x2142.com/logo.jpg</link>
    </image>
    <generator>Hugo -- 0.143.1</generator>
    <language>en-us</language>
    <lastBuildDate>Thu, 16 Jul 2020 18:02:27 +0000</lastBuildDate>
    <atom:link href="https://0x2142.com/categories/general-thoughts/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Privileged Access is Dangerous</title>
      <link>https://0x2142.com/privileged-access-is-dangerous/</link>
      <pubDate>Thu, 16 Jul 2020 18:02:27 +0000</pubDate>
      <guid>https://0x2142.com/privileged-access-is-dangerous/</guid>
      <description>My thoughts on the recent Twitter hack, and why access-control is important</description>
      <content:encoded><![CDATA[<p>This week at Twitter, there was a security incident that allowed access to a number of high profile accounts. The end result was a Bitcoin scam, with every account promising to &ldquo;double any BTC sent&rdquo; to them.</p>
<p>Twitter has come out fairly quickly to say that the incident was a result of social engineering. Someone convinced an employee at Twitter to hijack accounts via a backdoor administrative system.</p>
<p>What I wanted to focus on today is this: Why do backdoor systems like this exist - and how do we protect ourselves?</p>
<blockquote>
<p>We detected what we believe to be a coordinated social engineering attack by people who successfully targeted some of our employees with access to internal systems and tools.</p>
<ul>
<li>Twitter Support (@TwitterSupport)</li>
</ul></blockquote>
<h1 id="everything-has-a-backdoor">Everything Has a Backdoor</h1>
<p>If you think there isn&rsquo;t a backdoor way into a system, you probably just haven&rsquo;t found it yet.</p>
<p>From years as working in IT - one thing is certain: Someone controls the data. And that person(s) can do with it what they wish.</p>
<p>Are backdoors always a bad thing? Not inherently, no. We all want the convenience of being able to regain access to a locked account right? Then someone has to have the keys to override the system to make that change.</p>
<p>We all take our corporate email and domain logins for granted. Sure, we have a kind helpdesk employee that may help to reset a password - but how much access does that person have to our account? Even so, maybe we expect that in this case.</p>
<p>For example, there was a company I worked for a long while ago. HR/Payroll wanted to switch to using internal email to distribute paystubs. In order to do so, they required that every employee manually opt-in. None of the systems admins in the organization opted-in. We all knew how easy it was for any of us to read each others email. In fact, our internal security policy <em>required</em> any email containing sensitive information going in or out of the organization to be manually reviewed by someone. You know what qualifies as sensitive info? Payroll data.</p>
<p>Social media platforms (or any major website really) are no different. Someone needs to manage the backend systems. Someone has to be able to reset passwords &amp; assist those who use the platform. In this particular case, someone at Twitter had the ability to hijack accounts by changing email addresses &amp; resetting the passwords.</p>
<h1 id="what-about-mfa">What About MFA?</h1>
<p>MFA is like anything else in security - it&rsquo;s another layer, but it doesn&rsquo;t solve all problems.</p>
<p>MFA can protect you from someone who has your login credentials (username/password). If they don&rsquo;t have your token, phone, or whatever else you&rsquo;re using - they can&rsquo;t successfully authenticate.</p>
<p>That being said, if you already control the keys to the backend systems - bypassing or disabling MFA is just another click on your journey to taking over accounts.</p>
<h1 id="how-do-we-prevent-this">How Do We Prevent This?</h1>
<p>That&rsquo;s a good question. And a hard one to answer.</p>
<p>The general idea is to limit the amount of privilege that a single individual has. For example, if the average Twitter help desk employee is only responsible for resetting passwords - they shouldn&rsquo;t even have the option to disable MFA or change email addresses.</p>
<p>That being said - that&rsquo;s not always easy to accomplish. Systems need to be built around security and implement strict access control where necessary. Unfortunately we still live in a world where security is often an afterthought - or at least not designed into the solution on Day 1. That&rsquo;s not even considering that often security is still under-funded, and/or under-prioritized&hellip;.</p>
<p>Depending on the size of the organization, this control comes in many flavors. On the more strict side, we could have an administrative panel that is only accessible by high-level, trusted employees. Even then, we could implement a multi-step process by which a single employee could not make changes to sensitive accounts without secondary approval (or more). Going a step further - proper logging &amp; alerting may be triggered to alert someone that a change has happened, which prompts review to see if this was legitimate.</p>
<p>More commonly, what I see in organizations is just a simple policy. Yes, we acknowledge that you have unrestricted access to view/modify/delete customer data. But we have a <em>policy</em> that tells you not to.</p>
<p>The problem with that? One, it expects that most people read (and care about) the policies. I&rsquo;ve seen quite a number of organizations that hand you a huge pile of policies &amp; paperwork to review in your first week of employment. How many people truly take the time to read, review, and consider the content of those?</p>
<p>For two, a policy does nothing to prevent someone from taking action. Sure, fear of repercussion or losing a job may help. But if we&rsquo;re talking about a potentially malicious individual, those things likely do not concern them.</p>
<p>As another example, I&rsquo;ve previously worked at an organization with such policies. &ldquo;Don&rsquo;t look at customer data unless you have explicit approval from the customer&rdquo;. Okay, but the customer opened a support ticket because of some issue they&rsquo;re having. This issue sounds familiar and I can fix it real quick, if I just log into their tenant and make a change. OH. Whoops. I just saw sensitive data.</p>
<p>I wish I could say things like that never happened&hellip;</p>
<hr>
<h1 id="what-now">What Now?</h1>
<p>Well, now we wait.</p>
<p>Twitter has been fairly forthcoming with information so far. Yes, it&rsquo;s been vague - but that&rsquo;s to be expected while they pick up the pieces of what happened. The important thing is that they&rsquo;ve been steadily communicating what they <em>do</em> know so far.</p>
<p>Rumors are that an internal employee may have been paid to make changes to the accounts. I suppose we&rsquo;ll find out eventually - but if this is truly the case, there isn&rsquo;t much to be done.</p>
<p>One would hope that access to high-profile accounts would be restricted. One would hope that the people with that access are trusted, reliable individuals. Yet here we are.</p>
<p>It will certainly be interesting to see how much data Twitter releases about the actual events &amp; timeline. Preventing this from happening again will likely require further restricting access to those accounts &amp; possibly some form of the multi-tiered change approval mentioned earlier.</p>
<p>In the end - it sounds very likely this was an internal job. Those can be extremely hard to prevent, and require security training, additional security controls, etc. Even then - Humans create security controls, which means we also create ways to get around them.</p>
]]></content:encoded>
    </item>
  </channel>
</rss>
