back to article Hacked serverless functions are a crypto-gold mine for miscreants

PureSec, a maker of security software for serverless apps, has been poking about various cloud service providers, and found that hosted functions offer a shortcut to illicit crypto-mining. Crypto-mining attacks that hijack processing power do best with mass distribution. Those who can harness large numbers of processors – CPUs …

  1. Cronus

    I don't get how a SQL injection flaw could open the door to Crypto mining. What am I missing here?

    1. MiguelC Silver badge

      I guess that once you own the instance (be it via an initial SQL injection flaw or any other means) you can go on a rampage. Crypto mining is just one of the possibilities, but it's the one being discussed in the article.

      1. Jim Mitchell Silver badge


        If an attacker can own the instance a "serverless" function runs on, that is the providers problem, not yours.

    2. Anonymous Coward
      Anonymous Coward

      There’s no relation between the two. The article simply mentions that serverless functions can still include common application-level flaws like vulnerability to cross-site scripting or SQL injection.

  2. israel_hands

    I think the issue being exploited here is the auto-scaling nature. Compromising a web-app through something like SQL-injection then allows you to execute your own code on the server instance. You don't need to gain access to the actual back-end of the cloud system, just get the code running on the server-space that's been provisioned and then, as the compute requirements increase, the cloud provider will automatically spin up new server instances to cope with the load.

    It seems to be that it's not a case of compromising the entire system, just getting your code running somewhere (even within a VM or container sitting atop the AWS/Azure/whatever instance) and the programmatic elasticity will do the rest for you. You'd think that any company running something with auto-scaling will have configured alerts to let them know when the loads are spiking and by how much, in that same way that on-prem servers will have thresholds set up for things like CPU load, disk space, latency, etc.

  3. Claptrap314 Silver badge

    Basic security discipline

    This is really more of the same. In general, you need hard limits to prevent autoscaling from blowing your budget. For hosted services, this really is a form of basic security. That anyone would buy autoscaling without fine-grained controls blows my mind.

  4. Anonymous Coward
    Anonymous Coward

    CloudFog: When renting Cloud time is a bit too much like an expensive overseas cellphone Data-Plan:

    "It should also be possible to shut down cloud computing resources programmatically once expenses reach a specified point, but none of the major cloud providers appear to offer this out of the box – it appears they'd rather not make it too easy for customers to limit spending."

  5. Anonymous Coward
    Anonymous Coward

    Armchair quarterbacking...

    As others have pointed out, you still need good coding and deployment practices. Puresec and their backers have fired up a FUD campaign to gain attention and sell their wares to unsuspecting management types.

    The idea that a serverless function can "self-replicate" or "clone themselves" is nonsense, at least with respect to AWS. Lambda functions in AWS do not autoscale per se but rather they are created based on event or workload requirements and the code deployed is immutable, so any exploit would need to be repeatable at runtime.

    The examples provided are highly speculative and to create such an exploit in the wild require insider knowledge, poor coding/architectural practices and possibly compromising the control plane as well. None of which will really be solved by Puresec's "epoxy-potting" code injection.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021