Summary
In the Laf version design, the log uses communication with k8s to quickly retrieve logs from the container without the need for additional storage; However, this interface does not verify the permissions of the pod, which allows authenticated users to obtain any pod logs under the same namespace through this method, thereby obtaining sensitive information printed in the logs.
Details
The new version of LAF log directly obtains container logs through client node, but the authentication of this interface only passes the dual authentication of 'JwtAuthGuard' and 'Application AuthGuard'. In other words, as long as my Jwt and appID are legal enough, it can pass the verification.
The current goal is to construct a communication channel, where client node obtains specific log content through ns and podName; PodName is controllable, we only need to find the corresponding podName to view its log information.
There is no network isolation in each container of LAF. We successfully sniffed Prometheus through service detection of the cluster, but unfortunately, we were unable to access Prometheus. Upon closer inspection of the code, we found that feature (server): support resource monitor (#1468) restricted Prometheus's network access, requiring it to be a container under the same ns. Currently, the two ns of LAF in the public cloud are still distinguished, It's a bit regrettable.
However, Prometheus components are usually not authenticated, so we can access metrics information and successfully obtain relevant metadata information for all clusters:
curl http://prometheus-kube-state-metrics.xxxxxx:8080/metrics
now we can use this infomation to create a poc, first login and get your own token, then:
curl https://laf.run/v1/apps/xxxx/logs/<container_name>\?containerName\=<container> -H "Authorization: Bearer <YOUR_SELF_TOKEN>"
PoC
curl https://laf.run/v1/apps/xxxx/logs/<container_name>\?containerName\=<container> -H "Authorization: Bearer <YOUR_SELF_TOKEN>"
Impact
all users in laf.
DVKunion Reporter
Summary
In the Laf version design, the log uses communication with k8s to quickly retrieve logs from the container without the need for additional storage; However, this interface does not verify the permissions of the pod, which allows authenticated users to obtain any pod logs under the same namespace through this method, thereby obtaining sensitive information printed in the logs.
Details
The new version of LAF log directly obtains container logs through client node, but the authentication of this interface only passes the dual authentication of 'JwtAuthGuard' and 'Application AuthGuard'. In other words, as long as my Jwt and appID are legal enough, it can pass the verification.
The current goal is to construct a communication channel, where client node obtains specific log content through ns and podName; PodName is controllable, we only need to find the corresponding podName to view its log information.
There is no network isolation in each container of LAF. We successfully sniffed Prometheus through service detection of the cluster, but unfortunately, we were unable to access Prometheus. Upon closer inspection of the code, we found that feature (server): support resource monitor (#1468) restricted Prometheus's network access, requiring it to be a container under the same ns. Currently, the two ns of LAF in the public cloud are still distinguished, It's a bit regrettable.
However, Prometheus components are usually not authenticated, so we can access metrics information and successfully obtain relevant metadata information for all clusters:
curl http://prometheus-kube-state-metrics.xxxxxx:8080/metricsnow we can use this infomation to create a poc, first login and get your own token, then:
PoC
Impact
all users in laf.