CWE for backdoors

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

CWE for backdoors

Kurt Seifried
So we have:



But we don't have (as far as I can tell) a good CWE for other types of backdoors, e.g. some types of backdoors:

1) straight up apis/functions that just take a command (e.g. an API with a non documented call "ExecCode"
2) port knocking style backdoors, e.g. does this count as a hard coded credential, or is it something else (I would say something else)
3) phone home backdoors, e.g. the system itself communicates back to a mothership and takes commands, not documented/etc (e.g. an auto updater that is documented wouldn't fall into this category typically).

I think a generic catch all for "Backdoor allowing command/code execution initiated by remote attacker" would be a good thing to add as this seems to be happening more and more. 

--
Kurt Seifried
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: CWE for backdoors

Josh Bressers
Would any of these cover a maliciously inserted backdoor? Do we want an identifier specifically for that?

While I can't think of an example off the top of my head, it's going to happen. Luck favors the prepared.

-- 
    JB


On Wed, Jun 6, 2018 at 12:12 PM, Kurt Seifried <[hidden email]> wrote:
So we have:



But we don't have (as far as I can tell) a good CWE for other types of backdoors, e.g. some types of backdoors:

1) straight up apis/functions that just take a command (e.g. an API with a non documented call "ExecCode"
2) port knocking style backdoors, e.g. does this count as a hard coded credential, or is it something else (I would say something else)
3) phone home backdoors, e.g. the system itself communicates back to a mothership and takes commands, not documented/etc (e.g. an auto updater that is documented wouldn't fall into this category typically).

I think a generic catch all for "Backdoor allowing command/code execution initiated by remote attacker" would be a good thing to add as this seems to be happening more and more. 

--
Kurt Seifried
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CWE for backdoors

Pascal Meunier
In reply to this post by Kurt Seifried
These sound like children of "CWE-506: Embedded Malicious Code"

Pascal

On Wed, 2018-06-06 at 11:12 -0600, Kurt Seifried wrote:

> So we have:
>
> https://cwe.mitre.org/data/definitions/489.html Leftover debug code
>
> https://cwe.mitre.org/data/definitions/798.html Use of hard coded
> credentials
>
> But we don't have (as far as I can tell) a good CWE for other types of
> backdoors, e.g. some types of backdoors:
>
> 1) straight up apis/functions that just take a command (e.g. an API with a
> non documented call "ExecCode"
> 2) port knocking style backdoors, e.g. does this count as a hard coded
> credential, or is it something else (I would say something else)
> 3) phone home backdoors, e.g. the system itself communicates back to a
> mothership and takes commands, not documented/etc (e.g. an auto updater
> that is documented wouldn't fall into this category typically).
>
> I think a generic catch all for "Backdoor allowing command/code execution
> initiated by remote attacker" would be a good thing to add as this seems to
> be happening more and more.
>

Reply | Threaded
Open this post in threaded view
|

Re: CWE for backdoors

Kurt Seifried
The problem is "malicious code" may not be correct, e.g. poorly configured crypto defaults that allow weak hashes that can be spoofed/forced for example. 

On Wed, Jun 6, 2018 at 11:51 AM, Pascal Meunier <[hidden email]> wrote:
These sound like children of "CWE-506: Embedded Malicious Code"

Pascal

On Wed, 2018-06-06 at 11:12 -0600, Kurt Seifried wrote:
> So we have:
>
> https://cwe.mitre.org/data/definitions/489.html Leftover debug code
>
> https://cwe.mitre.org/data/definitions/798.html Use of hard coded
> credentials
>
> But we don't have (as far as I can tell) a good CWE for other types of
> backdoors, e.g. some types of backdoors:
>
> 1) straight up apis/functions that just take a command (e.g. an API with a
> non documented call "ExecCode"
> 2) port knocking style backdoors, e.g. does this count as a hard coded
> credential, or is it something else (I would say something else)
> 3) phone home backdoors, e.g. the system itself communicates back to a
> mothership and takes commands, not documented/etc (e.g. an auto updater
> that is documented wouldn't fall into this category typically).
>
> I think a generic catch all for "Backdoor allowing command/code execution
> initiated by remote attacker" would be a good thing to add as this seems to
> be happening more and more.
>



--
Kurt Seifried
[hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: CWE for backdoors

Joe Jarzombek
In reply to this post by Pascal Meunier
Backdoors left in operational code represent exploitable weaknesses, regardless of the intent of why they were inserted. Backdoors can often be used by actors other than those who inserted them (regardless of original intent). As such, I recommend not attempting to attribute malicious intent to categorize it a weakness.

Joe J

Sent from my Android phone using Symantec TouchDown (www.symantec.com)

-----Original Message-----
From: Pascal Meunier [[hidden email]]
Received: Wednesday, 06 Jun 2018, 12:58
To: Kurt Seifried [[hidden email]]; CWE-RESEARCH-LIST CWE RESEARCH DISCUSSION [[hidden email]]
Subject: Re: CWE for backdoors

These sound like children of "CWE-506: Embedded Malicious Code"

Pascal

On Wed, 2018-06-06 at 11:12 -0600, Kurt Seifried wrote:
> So we have:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__cwe.mitre.org_data_definitions_489.html&d=DwICaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=uxVVCWR8UcUyeakFZXcD5bxiMa6Nx1hPouclYdJYz00&m=ANiYNGZcZM0aM5yO0FFdVUjVlvFlbqyYdfdObTolung&s=ocKx-G3RaJbUSdHh6zOmUiH56B_Bqbg69_SZMzMtEdQ&e= Leftover debug code
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__cwe.mitre.org_data_definitions_798.html&d=DwICaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=uxVVCWR8UcUyeakFZXcD5bxiMa6Nx1hPouclYdJYz00&m=ANiYNGZcZM0aM5yO0FFdVUjVlvFlbqyYdfdObTolung&s=WmKvqZ8y3OJfbvwaVVxtXuFB2mXQbo1v78LatY23gwc&e= Use of hard coded
> credentials
>
> But we don't have (as far as I can tell) a good CWE for other types of
> backdoors, e.g. some types of backdoors:
>
> 1) straight up apis/functions that just take a command (e.g. an API with a
> non documented call "ExecCode"
> 2) port knocking style backdoors, e.g. does this count as a hard coded
> credential, or is it something else (I would say something else)
> 3) phone home backdoors, e.g. the system itself communicates back to a
> mothership and takes commands, not documented/etc (e.g. an auto updater
> that is documented wouldn't fall into this category typically).
>
> I think a generic catch all for "Backdoor allowing command/code execution
> initiated by remote attacker" would be a good thing to add as this seems to
> be happening more and more.
>

Reply | Threaded
Open this post in threaded view
|

Re: CWE for backdoors

Pascal Meunier
Agreed, original intent doesn't matter, what does is that it could be used for malicious
purposes.  By default I consider that 1-3 meet the description of CWE 506, "appears to be
malicious in nature", regardless of original intent.  However, you're correct in pointing
out that considering maliciousness could be unnecessarily distracting, let's avoid that
debate.

Pascal

On Wed, 2018-06-06 at 18:10 +0000, Joe Jarzombek wrote:

> Backdoors left in operational code represent exploitable weaknesses, regardless of the
> intent of why they were inserted. Backdoors can often be used by actors other than those
> who inserted them (regardless of original intent). As such, I recommend not attempting
> to attribute malicious intent to categorize it a weakness.
>
> Joe J
>
> Sent from my Android phone using Symantec TouchDown (www.symantec.com)
>
> -----Original Message-----
> From: Pascal Meunier [[hidden email]]
> Received: Wednesday, 06 Jun 2018, 12:58
> To: Kurt Seifried [[hidden email]]; CWE-RESEARCH-LIST CWE RESEARCH DISCUSSION [CWE-RE
> [hidden email]]
> Subject: Re: CWE for backdoors
>
> These sound like children of "CWE-506: Embedded Malicious Code"
>
> Pascal
>
> On Wed, 2018-06-06 at 11:12 -0600, Kurt Seifried wrote:
> > So we have:
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__cwe.mitre.org_data_definitions_48
> > 9.html&d=DwICaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=uxVVCWR8UcUyeakFZXcD5bxiMa6Nx1hPouclYdJYz00
> > &m=ANiYNGZcZM0aM5yO0FFdVUjVlvFlbqyYdfdObTolung&s=ocKx-
> > G3RaJbUSdHh6zOmUiH56B_Bqbg69_SZMzMtEdQ&e= Leftover debug code
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__cwe.mitre.org_data_definitions_79
> > 8.html&d=DwICaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=uxVVCWR8UcUyeakFZXcD5bxiMa6Nx1hPouclYdJYz00
> > &m=ANiYNGZcZM0aM5yO0FFdVUjVlvFlbqyYdfdObTolung&s=WmKvqZ8y3OJfbvwaVVxtXuFB2mXQbo1v78Lat
> > Y23gwc&e= Use of hard coded
> > credentials
> >
> > But we don't have (as far as I can tell) a good CWE for other types of
> > backdoors, e.g. some types of backdoors:
> >
> > 1) straight up apis/functions that just take a command (e.g. an API with a
> > non documented call "ExecCode"
> > 2) port knocking style backdoors, e.g. does this count as a hard coded
> > credential, or is it something else (I would say something else)
> > 3) phone home backdoors, e.g. the system itself communicates back to a
> > mothership and takes commands, not documented/etc (e.g. an auto updater
> > that is documented wouldn't fall into this category typically).
> >
> > I think a generic catch all for "Backdoor allowing command/code execution
> > initiated by remote attacker" would be a good thing to add as this seems to
> > be happening more and more.
> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: CWE for backdoors

Pascal Meunier
In reply to this post by Kurt Seifried
I see, you want to consider all possible types of backdoors.  From your examples I thought
you were bringing up the ones that appear malicious.


On Wed, 2018-06-06 at 12:04 -0600, Kurt Seifried wrote:

> The problem is "malicious code" may not be correct, e.g. poorly configured
> crypto defaults that allow weak hashes that can be spoofed/forced for
> example.
>
> On Wed, Jun 6, 2018 at 11:51 AM, Pascal Meunier <[hidden email]>
> wrote:
>
> > These sound like children of "CWE-506: Embedded Malicious Code"
> >
> > Pascal
> >
> > On Wed, 2018-06-06 at 11:12 -0600, Kurt Seifried wrote:
> > > So we have:
> > >
> > > https://cwe.mitre.org/data/definitions/489.html Leftover debug code
> > >
> > > https://cwe.mitre.org/data/definitions/798.html Use of hard coded
> > > credentials
> > >
> > > But we don't have (as far as I can tell) a good CWE for other types of
> > > backdoors, e.g. some types of backdoors:
> > >
> > > 1) straight up apis/functions that just take a command (e.g. an API with
> >
> > a
> > > non documented call "ExecCode"
> > > 2) port knocking style backdoors, e.g. does this count as a hard coded
> > > credential, or is it something else (I would say something else)
> > > 3) phone home backdoors, e.g. the system itself communicates back to a
> > > mothership and takes commands, not documented/etc (e.g. an auto updater
> > > that is documented wouldn't fall into this category typically).
> > >
> > > I think a generic catch all for "Backdoor allowing command/code execution
> > > initiated by remote attacker" would be a good thing to add as this seems
> >
> > to
> > > be happening more and more.
> > >
>
>
>

Reply | Threaded
Open this post in threaded view
|

RE: CWE for backdoors

Christey, Steven M.
Just my quick opinion without having discussed with Drew Buttner to provide a shared CWE-team view, but: theoretically, every instance of a backdoor should be able to be described by some other CWE.  Intent shouldn't matter.  A port is left open without authentication? Then it's CWE-287 or similar.  Weak crypto?  Then it's CWE-327 or something else.

CWE-wise, in my opinion, the focus should be on what the insecure behavior is - irrespective of how it was introduced into the software.

(This also means that since CWE-489 "leftover debug code" does not accurately describe what is inherently insecure about the code's behavior, it's not an ideal CWE entry, either.)

- Steve



> -----Original Message-----
> From: Pascal Meunier [mailto:[hidden email]]
> Sent: Wednesday, June 06, 2018 2:43 PM
> To: Seifried, Kurt <[hidden email]>
> Cc: CWE Research Discussion <[hidden email]>
> Subject: Re: CWE for backdoors
>
> I see, you want to consider all possible types of backdoors.  From your examples
> I thought
> you were bringing up the ones that appear malicious.
>
>
> On Wed, 2018-06-06 at 12:04 -0600, Kurt Seifried wrote:
> > The problem is "malicious code" may not be correct, e.g. poorly configured
> > crypto defaults that allow weak hashes that can be spoofed/forced for
> > example.
> >
> > On Wed, Jun 6, 2018 at 11:51 AM, Pascal Meunier
> <[hidden email]>
> > wrote:
> >
> > > These sound like children of "CWE-506: Embedded Malicious Code"
> > >
> > > Pascal
> > >
> > > On Wed, 2018-06-06 at 11:12 -0600, Kurt Seifried wrote:
> > > > So we have:
> > > >
> > > > https://cwe.mitre.org/data/definitions/489.html Leftover debug code
> > > >
> > > > https://cwe.mitre.org/data/definitions/798.html Use of hard coded
> > > > credentials
> > > >
> > > > But we don't have (as far as I can tell) a good CWE for other types of
> > > > backdoors, e.g. some types of backdoors:
> > > >
> > > > 1) straight up apis/functions that just take a command (e.g. an API with
> > >
> > > a
> > > > non documented call "ExecCode"
> > > > 2) port knocking style backdoors, e.g. does this count as a hard coded
> > > > credential, or is it something else (I would say something else)
> > > > 3) phone home backdoors, e.g. the system itself communicates back to a
> > > > mothership and takes commands, not documented/etc (e.g. an auto
> updater
> > > > that is documented wouldn't fall into this category typically).
> > > >
> > > > I think a generic catch all for "Backdoor allowing command/code
> execution
> > > > initiated by remote attacker" would be a good thing to add as this seems
> > >
> > > to
> > > > be happening more and more.
> > > >
> >
> >
> >