Has anyone experienced security issues with this version of geonode-project in production? #561
Replies: 2 comments 2 replies
-
|
@romelvazquez for sure it would be good to know, which version of GeoNode you have deployed. Have you already checked the Security section of this repository? |
Beta Was this translation helpful? Give feedback.
-
|
@romelvazquez I moved your comment under this thread |
Beta Was this translation helpful? Give feedback.
-
|
Not sure about the report you sent. It looks like some other report which is not related to you. However, the files do not indicate that they belong to GeoNode or any other component GeoNode uses. So it looks like some malicious activity. I could not find any specific CVE reports but in any case you should update your GeoNode instance as |
Beta Was this translation helpful? Give feedback.
-
|
git checkout -b 4.2.2 pip install Django==3.2.13 DOCKER_API_VERSION="1.24" GEONODE_BASE_IMAGE_VERSION=master |
Beta Was this translation helpful? Give feedback.
-
A server that I installed was hacked, and malware was installed inside some containers that carry out attacks.
I would like to know if it is a system bug or if it was caused by a private attack. If anyone has any idea how I can solve it, I would appreciate it.
This is what the suppliers reported to me
If you enter container 45f13a398683, you will see several files inside the /tmp directory:
g and g.1 (same content)
imnotmalware
The first two are scripts used to download and execute malware. The source from which the malware is currently being downloaded is not working (which is common), but it previously did, and more concerningly, if they were able to upload it once, they could do it again. This means someone can write and execute files inside your containers.
The other file, imnotmalware, produces the following output when executed: "JEW was here lol". A quick Google search returns this information: https://www.joesandbox.com/analysis/1570043/0/pdf.
It is highly likely that these are not the only suspicious files—this was found within seconds by simply entering and checking the most common path. A skilled attacker would know how to hide much better.
Regardless, it is evident that the application is not secure, and the most recommended course of action right now is to completely remove the VPS server.
his is an automated abuse complaint regarding active TCP port scan
(establishing multiple connections). All these connections are to dynamically
located tarpit type honeypots and thus provide sufficiently reliable evidence
to claim an ongoing port scan activity.
This means the host behind IP address XX.XX.XX.XX is either:
(Telnet at 23/tcp, Samba at 445/tcp, FTP at 21/tcp, SSH at 22/tcp and so on).
We insist that you and/or your end-user will take all necessary actions to
resolve the current issue. If you are an established VPN provider with zero-log
policy, please let us know about that, so we will be able to whitelist you.
We are a hosting provider Skhron, please DO NOT block any of our single IP
address or entire blocks!
Wish to stop receiving such messages (are you a security researcher)? Please
reply to this message - all replies are processed manually.
Incident details are attached below:
Timestamp SrcIP SrcPort DstIP DstPort
2025-02-23T15:38:08.903Z XXXX 51522 XXXXXX 23
2025-02-23T23:38:46.354Z XXXXX 55702 XXXXXX 23
2025-02-24T01:27:53.303Z XXXXXX 34416 XXXXXX 23
2025-02-24T03:34:05.348Z XXXXXX 37936 XXXXXX 23
This table contains established TCP connections (ones confirmed using 3WHS -
three way handshake, which makes our data not vulnerable to an IP spoofing
attack). These events cannot be forged and can be reliably verified even if you
use sampled network monitoring, for example, with sFlow.
Please do not hesitate to reply to this letter if you have any questions or
concerns regarding the current case.
Beta Was this translation helpful? Give feedback.
All reactions