Bunny.net corta en 20 minutos un nodo CDN comprometido en Armenia
Bunny CDN Security Incident
Un proveedor de infraestructura de Bunny.net reportó acceso no autorizado a software de gestión de servidores. Un nodo CDN en Armenia estaba alojado en uno de esos servidores: la empresa dejó de enrutar tráfico en 20 minutos, borró el servidor y revocó sus accesos. No hay evidencia de intrusión, pero se revocaron y reemitieron los certificados TLS de sus dominios; los de dominios personalizados se están reemitiendo.
Si se produjo un acceso no autorizado a nuestro nodo CDN, la información potencialmente expuesta habría sido: contenido CDN almacenado en caché temporalmente, configuraciones de Pull Zone y certificados TLS almacenados en ese servidor.
- colonCapitalDee
Respuesta rápida y competente, como se espera de bunny.
"La semana pasada, uno de nuestros proveedores de infraestructura reportó acceso no autorizado relacionado con software de gestión de servidores de terceros. Uno de nuestros nodos CDN, ubicado en Armenia, estaba alojado en un servidor suministrado por este proveedor.
Después de recibir la alerta del proveedor afectado, nuestro equipo de ingeniería tomó medidas inmediatas. En 20 minutos, dejamos de enrutar tráfico a través del servidor. Luego revisamos y preservamos los registros de seguridad relevantes para la investigación, borramos de forma segura el servidor y revocamos su acceso a nuestros otros sistemas. El servidor afectado ha sido eliminado permanentemente de nuestra infraestructura."
- eraclide
Bunny usó Gcore en Armenia. Gcore mismo fue hackeado, no Bunny. Bunny fue solo un afectado aguas abajo, en solo uno de sus POPs.
https://lowendtalk.com/discussion/222315/gcore-compromised-v...
El título es muy engañoso.
- bobtheborg
Aunque ninguna de las investigaciones ha encontrado indicios de acceso no autorizado a nuestro servidor, no podemos descartar completamente la posibilidad.
Si ocurrió acceso no autorizado a nuestro nodo CDN, la información potencialmente expuesta habría sido: contenido CDN almacenado en caché temporalmente, configuraciones de Pull Zone y certificados TLS almacenados en ese servidor.
Como precaución adicional, hemos revocado y reemitido todos los certificados TLS para los dominios de la plataforma bunny. net (b-cdn. net y bunny. run). La reemisión de certificados TLS gestionados para dominios personalizados está en curso y se espera que se complete dentro de las próximas 24 horas. No se requiere acción por parte de los clientes que usan certificados gestionados. Publicaremos una actualización adicional en nuestra página de estado una vez que este proceso esté completo.
Si gestionas tus propios certificados TLS, recomendamos revocarlos y reemitirlos con nuevas claves privadas como precaución.
Ningún otro dato de cliente, incluidos los datos de cuenta de bunny. net, estaba almacenado en el servidor en cuestión, y ningún sistema interno se vio afectado.
así que parece que el proveedor subyacente potencialmente permitió, por ejemplo, lectura de disco, ¿eso es lo que bunny dice que podría haber estado en el disco en este caso? ¿Lo estoy leyendo bien?
- evan_a_a
> Después de recibir la alerta del proveedor afectado, nuestro equipo de ingeniería tomó medidas inmediatas. En 20 minutos, dejamos de enrutar tráfico a través del servidor. Luego revisamos y preservamos los registros de seguridad relevantes para la investigación, borramos de forma segura el servidor y revocamos su acceso a nuestros otros sistemas. El servidor afectado ha sido eliminado permanentemente de nuestra infraestructura.
Al responder a una posible brecha, el protocolo correcto es contener el incidente y PRESERVAR TODO para la investigación. No intentes ser selectivo con los datos que conservas o no conservas. Lamentablemente, probablemente han destruido evidencia y no podrán determinar si el atacante realmente penetró el servidor o no, y si lo hizo, cómo. Esto indica que tienen un plan de respuesta a incidentes deficiente o inexistente.
- bitlad
Parece que hay un incidente cada hora.