I don't believe we've seen anything similar. But, of course, it could be that you are the only person to have spotted it.
I doubt they would do anything and would simply say that it is something to do with your configuration. There are many ways to mess up the security of AWS. For example, if you are using S3 storage, there are all too many people who end up leaving it unsecured.
I would suggest that if you are using Docker containers on AWS, you should rebuild the container from scratch on a clean machine. Take everything you can off AWS, go through all your AWS settings and make sure everything is locked down. Then reset any logins and change passwords. Finally put the clean container back in place.
A compromised dependency would not need to edit the Node-RED flow, it would just do all this from within it's own code and not expose it's self to being discovered like this.
The fact the flow was edited very much indicates that something/someone had access to the Node-RED instances API to inject these tabs. As others have mentioned there are bots scanning for access to unsecured Node-RED instances, they normally install crypto-miners (which given the CPU counting sounds like that was the intention)
The other reason I say this is because anything just editing the flow file on disk wouldn't actually be run unless they also restarted the Node-RED process (or issued an API call) to trigger reloading the flow file. Making the changes via the API causes the code to be running straight away.
My opinion is that the Node-RED instance was actually exposed to the internet some how. If IPv4 is all locked down (behind a NAT gateway and no port forwarding and VPN only access) then it could be IPv6, if your network is IPv6 enabled and you don't have default firewall rules blocking incoming traffic that would be my first guess. Lots of routers still come with no IPv6 Firewall enabled.
Normally the IPv6 address range is too large to scan, but it may be that attackers have found ways to narrow the search.
Unfortunately, my instance turned out to be exposed to the internet. The Bosch Home Connect APIās authorisation callback function (node-red-contrib-homeconnect) that arrives on a random port of the firewall and is configured via reverse proxy redirects to the default Node-RED port.
Fortunately for others, it wasnāt a software vulnerability, but a human oversight. Again you will say. Thanks for all your reactions that helped me analyse and find the cause.
Yesterday, I was busy taking measures. Like:
In the firewall I have disabled the port and enabled logging for incoming traffic (on the port) and outgoing traffic (to the mentioned IP).
I set a NodeRED password, changed github keys and also changed passwords used in flows, starting with the major systems, like my website-provider, NAS, etc.
Most passwords were set as credentials: exported flows donāt contain the secrets but they were able to see and copy them. I am to finish the renewal of them today.
You should write an article describing your problem, how you discovered it and the steps you took to regain control over your instance. Many people over here are probably not as experienced as you, or the people that helped you. As mentioned above, this type of attack seems pretty common, so this article could be helpful for the community. Don't forget to add a searchable title.
At the end of the article you could partner with flowfuse and say something catchy to influence people to buy their license, in exchange for a % haha
Haha, lol. In my opinion add-ons like homeconnect should be rated dangerous, and some pattern may be designed to make them possible (opening and closing firewalls is not novice-friendly). Also all add-ons whose setup donāt hide passwords/api-keys/etc. should get a flag.
For people reading this post: The cause is still your instance exposed to internet, even if you know it is not. Look further
a: Writing a thread and naming it for what you see it is. Dangerous.
b: Write to the bozos who make homeconnect and tell them.
It may be an innocent mistake on their part. (Cough).
But on the off chance they care, it may prompt them to address this problem.
I added the port as the callback uri (myexternalip:outsideport) and forwarded it (through reverse proxy) to mynodered:internalport (=1880). So it was my manual action in both the router and setting the reverse proxy. (yeah, i am ashamed afterwards)
In the thread on github of the home-connect module (I followed Trying_to_learnās advise) I get the message the callback uri does not need to be connected to the mynodered:internalport which I consider not the truth.It is how the oauth method āAuthorization Code Flow with PKCEā (home-connect method) works to get the final token to the client-application.
As I am not an authority on security I did not continued the discussion.
For future readers: whether it is needed or not: it is only needed on the first exchange to get the token and not needed during the use (send commands or getting data) nor is it needed for refreshing the token.
They are probably correct. Try setting the callback url to the internal address rather than an the external one. Generally, for OAuth, the callback is triggered locally not remotely.
I've not used home-connect though so I might be wrong. Worth a try anyway.
