Security-ASP as man-in-the middle malware deployment ?

[de-jcup]

Risk estimation

Current Situation

• there is always a client TCP/IP connection to an ASP server and always trusted.
• the communication is not encrypted, but plain json
• But Server IP is always only loopback address, ports can differ
• Client accepts only ASP connections from/to loopback address, so localhost...

What could a Hacker do with ASP?

• Kill the process of the real ASP server instance
• Create a fake server ASP, or an adapted ASP server, but create a control server
• The control server could create and deploy an exploited PDF or HTML

When could a Hacker do this with ASP?

• Hacker must have already access to local machine
• Must have the right to kill the origin process
• Must have the possiblity to create a server process for necessary port on loop back address

If the hacker is able to do the steps described above, he/she is already having access to system.

What would be the "benefit" for an hacker to have access to ASP

Exploit PDF and deliver by ASP:

One potential target: Attacker has normal user/developer rights available but no admin rights. A malware PDF could be a delivered by fake ASP server to client caller and have

• either rights of the caller (not really a "hack benefit")
• maybe gain more user rights (priviledge escalation) by using an HTML or PDF exploit delivered...

[de-jcup]

Plantuml-Code:

component Client as client
component "ASP server" as aspServer
component "ASP attack server" as attackServer
interface "malware PDF" as malware
aspServer <- Alice  :start (1)
Alice -> client
Bob -> aspServer : stop (2)
Bob -> attackServer :start (3)
client ->attackServer: connect (4)
attackServer -> malware :delivers

[de-jcup]

Could we prevent the situation when a hacker has already access/rights to local system?

I do not think so. Inside this scenario an attacker has already access to local system. So he/she is able to replace any existing PDF file on local file system too. Also replacement of JRuby parts etc. could be done, maybe even a replacement of a installed asciidoctor variant.

So I do not think that one can rule out the possibility in general, if an attacker has already access to a developer machine.

[de-jcup]

close ticket, because a local access by attacker cannot be solved that way at all

[de-jcup]

Back again, because: An attacker could have another user account (hacked) and start there a fake ASP server instance. At the hacked account there are not much rights (no admin, etc.). But vicitim developer could use the started ASP server and have e.g. administrative rights so we could have there a priviledge escalation again...

Solution 1 (encryption)

So it would be better if the server would create a random key on startup, give back the key to the starter of the server instance (user/developer).

This secret key should be used by server and also by client to encrypt/decrypt data transfer. So more secure data, but also the communication can only happen if both (client/server) know the same key.

If the encryption fails (no valid json, no teminators etc.) the connection is not trusted.

Solution 2 (mitigation by no reuse of running ASP instances)

As long as there is no encryption implemented, callers could insist on their own running instances of ASP server means, as long as the server instance (process) is running an connected to port its own variant. A server disrupt should automatically terminate client calls or mark them as untrusted. Reuse of running ASP instances is forbidden.