keycloak登录密码设置导致的弱口令安全漏洞

坚持是一种态度

已于 2023-07-04 22:39:23 修改

阅读量3k

点赞数

分类专栏： java 文章标签： keycloak 微服务安全漏洞弱密码

于 2023-06-18 22:07:46 首次发布

本文链接：https://blog.csdn.net/u010882234/article/details/131276588

版权

java 专栏收录该内容

114 篇文章 3 订阅

订阅专栏

文章目录

keycloak介绍

Keycloak是一个开源的身份认证和授权管理系统，它提供了多种身份认证方式（例如：用户名/密码、OAuth、OpenID Connect、SAML 2.0等）和授权策略，为应用程序和服务提供了安全的用户结构和访问控制
Keycloak被广泛应用于企业系统中，尤其是在支持多种身份验证和单点登录的应用程序中，也可以与常用的开发框架（例如：Spring、React等）集成
Keycloak易于使用并提供了可扩展性和灵活性，可适用于各种应用场景，保障应用程序的信息安全和用户数据隐私

管理员弱口令漏洞

本来用于提供安全访问控制的keycloak，由于我们设置的弱密码，变成了安全漏洞（虽然没损失，也不太好）
某天我司被区网信办通报了，下函发文说我们部署在公网上的系统遭到了黑客网络攻击
看了报告，是9080端口的弱密码漏洞，而且是很经典的用户名密码，admin admin
漏洞详情通报如下：

网络安全风险情况

1.漏洞详情
监测发现，5月18日，境外黑客组织利用跳板（176.16.*.*、223.223.*.*），通过管理员弱口令（admin/admin）登录xxxxxx公司交通信号集中控制系统（xx.xx.xx.xx:9080），累计通联流量6.2MB。

2.修复建议
建议排查系统是否存在泄露数据风险，核查数据泄露原因、范围、风险及影响。

风险分析和排查处理

这是我们部署到腾讯云的一套基础版平台系统，用于公司同事在外面访问和给客户远程演示之类的，没有做ip限制，允许互联网访问
这套部署的平台，只有一些添加的测试数据，没有实际的路口和设备信息
可能是我们平台名字或网页代码里带了“交通信号控制”这几个字，被黑客程序扫到了，当成政府软件系统的一部分，被黑客扫了
看了下报告，应该是只扫到部署的中间件keycloak（就它9080端口），里面没有啥实质内容，只是keycloak中间件自带的操作界面
首先是把被扫描到的系统的keycloak密码改掉，改为强密码（防止以后被误启动后仍是弱密码）
然后把平台服务关闭掉，不再提供服务，后续演示平台使用向日葵等远程方式投屏实现
最后修改我们的部署脚本，将对外部署的版本的keycloak服务都改成强密码
在这里还遇到一个小问题，修改完之后，登录和其他功能的权限校验都没问题，但在平台加载用户列表时报错，如下：

09:06:27,355 WARN  [org.keycloak.events] (default task-1) type=LOGIN_ERROR, realmId=master, clientId=admin-cli, userId=49c4ec90-1777-4c99-a1bd-d24339c8539b, ipAddress=172.18.0.13, error=invalid_user_credentials, auth_method=openid-connect, grant_type=password, client_auth_method=client-secret, username=admin, authSessionParentId=ad7d6212-3bf0-4275-bf1c-e31e2246bb9a, authSessionTabId=UfIvlTeTy8g
09:06:47,213 WARN  [org.keycloak.events] (default task-1) type=LOGIN_ERROR, realmId=master, clientId=admin-cli, userId=49c4ec90-1777-4c99-a1bd-d24339c8539b, ipAddress=172.18.0.13, error=invalid_user_credentials, auth_method=openid-connect, grant_type=password, client_auth_method=client-secret, username=admin, authSessionParentId=3990f6da-fa60-4935-a6fa-f47694d674ca, authSessionTabId=syDr4d1V_V8

排查代码后发现，其他接口权限校验是验证已登录的token，用户列表接口是直接请求调用keycloak的服务的API接口，而修改密码时漏改了配置，修改后如下：

  core-app:
    image: core
    container_name: core
    volumes:
      - /etc/localtime:/etc/localtime
    depends_on:
      - postgresql
      - keycloak
      - redis
    environment:
      - _JAVA_OPTIONS=-Xmx1G -Xms512m
      - SERVER_PORT=8181
      - SPRING_PROFILES_ACTIVE=prod,api-docs,no-liquibase
      - SPRING_CLOUD_CONSUL_HOST=consul
      - SPRING_CLOUD_CONSUL_PORT=8500
      - KEYCLOAK_URL=http://keycloak:9080/auth
      - KEYCLOAK_USERNAME=admin
      - KEYCLOAK_PASSWORD=xxxxxx
      - SPRING_DATASOURCE_URL=jdbc:postgresql://postgresql:5432/core
      - SPRING_DATASOURCE_USERNAME=postgres
      - SPRING_DATASOURCE_PASSWORD=xxxxx.pgPW
      - SPRING_REDIS_HOST=redis
      - SPRING_REDIS_PASSWORD=xxxxx.redisPW

其他弱密码漏洞

除了登录界面的弱密码漏洞，还有一些其他的弱密码漏洞，都需要我们注意
例如，数据库弱密码漏洞、zookeeper等其他中间件的弱密码漏洞等
有时候我们明明设置了很强的密码，也会被第三方机构扫描上报为弱密码漏洞。这些是误报，但是客户不会管那么多，肯定是需要我们处理掉的
处理方式也很简单，把端口的调用，用防火墙做好访问限制，只允许自己的服务的ip端口访问，不对外开放
如果是使用docker部署中间件，直接不把端口号暴露出来，服务调用中间件时，使用服务名称调用，也是可以的
例如上面的core服务，使用了Redis和PostgreSQL，直接使用服务名调用，这2个服务的端口都不需要从docker里映射处理

  # 数据库服务，keycloak gateway core unit data-center都依赖此数据库
  postgresql:
    image: postgres:14.2
    container_name: postgres
    volumes:
      - ./volumes/postgresql/:/var/lib/postgresql/data/
      - /etc/localtime:/etc/localtime
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=xxxxx.pgPW
      - POSTGRES_HOST_AUTH_METHOD=md5
      - TZ=Asia/Shanghai
    networks:
      - signal-network
    restart: always
  # 缓存服务
  redis:
    image: redis:7.0.4
    container_name: redis
    volumes:
      - /etc/localtime:/etc/localtime
    command:
      --requirepass "xxxx.redisPW" # 这一行是设置密码
    environment:
      - TZ=Asia/Shanghai
    networks:
      - signal-network
    restart: always