🇰🇷 한글 설명
Authelia의 4.38.0부터 4.39.19 버전에서 Basic Auth를 사용할 때 사용자 이름의 대소문자 처리 방식 차이로 인해 발생하는 취약점입니다. LDAP은 대소문자를 구분하지 않지만, 규제 시스템의 SQL 쿼리는 대소문자를 구분하여 처리함으로써 각 대소문자 변형마다 별도의 차단 기록이 생성됩니다. 이로 인해 공격자가 차단 정책을 우회할 수 있는 가능성이 존재합니다.
💡 쉬운 설명
로그인 시 아이디의 대소문자만 살짝 바꿔서 입력하면, 시스템이 이를 다른 사람으로 착각하여 차단 기록을 피할 수 있는 문제입니다. 공격자가 비밀번호를 여러 번 틀려도 차단되지 않고 계속 시도할 수 있게 만듭니다.
🇺🇸 원문 (English)
Authelia is an open-source authentication and authorization server providing two-factor authentication and single sign-on (SSO) for applications via a web portal. In versions 4.38.0 through 4.39.19, when a user authenticates via Basic Auth (i.e via the `Authorization` header with the `Basic` scheme) on the authz verification endpoint, Authelia takes the username directly from the `Authorization` header and passes it as is to the regulation system for ban checking and attempt recording. LDAP treats usernames case insensitively : `john`, `John`, and `JOHN` all bind as the same user. But the regulation SQL queries treat the lookup of these values in certain scenarios as case sensitive. This allows each variation of a usernames case to have its own ban bucket. Upgrade to 4.39.20 to receive a patch. As a workaround, explicitly disable the basic auth mechanism.
📍 영향받는 시스템
Authelia versions 4.38.0 through 4.39.19
⚔️ 공격 벡터
Basic Auth 헤더의 사용자 이름 대소문자를 변경하여 차단 시스템(Ban bucket) 우회
🛡️ 대응 방법
Authelia를 4.39.20 버전 이상으로 업그레이드하거나, 임시 방편으로 Basic Auth 메커니즘을 비활성화하십시오.
🔧 검증 코드
명령어 결과에 취약한 버전 범위가 출력되면 해당 버전이 설치되어 있는 상태입니다.
curl -s http://<authelia-host>/api/version | grep -E '4\.(38\.|39\.(0|1|2|3|4|5|6|7|8|9|1[0-9]|2[0-9]))'
💻 영향받는 소프트웨어
IBM WebSphere Application Server