petrusviet/cve-2019-11581Atlassian Jira 비인증 템플릿 주입
4.4.x
5.x.x
6.x.x
7.0.x
7.1.x
7.2.x
7.3.x
7.4.x
7.5.x
7.6.x before 7.6.14 (the fixed version for 7.6.x)
7.7.x
7.8.x
7.9.x
7.10.x
7.11.x
7.12.x
7.13.x before 7.13.5 (the fixed version for 7.13.x)
8.0.x before 8.0.3 (the fixed version for 8.0.x)
8.1.x before 8.1.2 (the fixed version for 8.1.x)
8.2.x before 8.2.3 (the fixed version for 8.2.x)
./bin/setenv.bat 파일에서 set JVM_SUPPORT_RECOMMENDED_ARGS= 값을 수정하면(Linux에서는 ./bin/setenv.sh로 동일) 원격 디버그를 실행할 수 있습니다.set JVM_SUPPORT_RECOMMENDED_ARGS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
Remote JVM Debug Debug Configuration을 생성합니다. host와 port는 localhost:5005로 설정하고 Command line aguments for remote JVM은 다음과 같이 입력합니다.-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005
./bin/config.bat 파일을 실행하고(Linux에서는 config.sh) "Jira home"을 자신의 jira home 디렉터리로 수정합니다.
./bin/start-jira.bat 파일을 실행합니다(Linux에서는 ./bin/start-jira.sh). Java 버전, 포트 8080과 5005가 사용 가능한 상태인지 확인하세요. 실행되지 않으면 그 때문입니다!
개인 모드를 선택합니다.
이 단계에서는 이메일을 수신할 수 있는 주소를 사용해야 합니다 :)
Conf와 test connection을 모두 완료하세요.
http://localhost:8080/secure/admin/EditApplicationProperties!default.jspa에서 Contact Administrators Form 기능을 활성화합니다.
빌드 시 몇 가지 주의사항만 기록했습니다. 자세한 내용은 building jira from source를 참고하세요.
Advisory를 읽은 결과 이 버그는 ContactAdministrators와 SendBulkMail(이건 인증이 필요해서 건너뜁니다)에 있습니다. 그래서 ContactAdministrators 기능을 테스트하고 request를 잡아보겠습니다.
request가 /secure/ContactAdministrators.jspa로 가는 것을 확인했습니다. 그래서 ./atlassian-jira/WEB-INF/web.xml 파일을 열어 이 request가 어떤 클래스로 전달되는지 확인합니다.
따라서 request는 JiraWebworkActionDispatcher에서 처리됩니다. 그래서 이 클래스의 init과 server에 중단점을 설정하고 디버그를 실행합니다.
프로그램이 server 함수에서 멈췄습니다. 조금 추적하니 프로그램이 ContactAdministrators.doExecute()로 들어갑니다.
이후 send를 거치며, 여기서 프로그램은 활성 상태인 관리자 계정 목록을 표시합니다.
그런 다음 sendTo 함수로 이동합니다. 여기서 프로그램이 MailQueueItem을 생성하고 이를 mailQueue에 추가하는 것을 볼 수 있습니다.
프로그램이 EmailBuilder.withSubject 함수를 호출합니다. 이때 이메일의 subject 문자열(공격자가 보낸 값)이 String에서 TemplateSources로 변환되어 EmailBuilder의 subjectTemplate 파라미터에 할당됩니다.
renderLater 함수에서 프로그램은 EmailRenderer를 생성하고, 그것을 사용해 RenderingMailQueueItem을 생성합니다.
여기서 다시 ContactAdministrators.sendTo 함수로 돌아옵니다. MailQueueItem 생성이 끝나면 프로그램은 item을 mailQueue에 추가한 후 doExecute 함수로 돌아가 Redirect를 수행합니다. 이 디버그 흐름만으로는 프로그램이 이메일을 렌더링하는 부분으로 이동할 수 없어서 템플릿 주입이 발생하는 지점에 도달하지 못합니다. 그렇다면 이메일 처리 과정을 추적하려면 어떻게 해야 할까요?
EmailRenderer에 renderNow 함수가 있는 것을 확인했습니다(프로그램은 renderLater만 호출합니다). 큐에 있는 이메일이 렌더링되기 위해 호출될 때도 renderNow와 동일한 흐름을 따를 것이라고 추측했고, 그래서 renderNow 함수부터 추적하기로 결정했습니다.
renderNow에서 프로그램이 EmailRenderer.render()를 호출합니다. 여기에 중단점을 설정하고 다시 request를 보내 실제로 이 지점까지 실행되는지 확인합니다.
운 좋게도 프로그램이 예상한 방향으로 진행되었습니다. 다음으로 프로그램이 renderEmailSubject를 호출합니다.
다음으로 프로그램이 DefaultVelocityTemplatingEngine.render(this.subjectTemplate)을 호출합니다.
DefaultVelocityTemplatingEngine.applying과 DefaultVelocityTemplatingEngine.asPlainText로 이동합니다.
계속해서 asPlainText(Writer writer)를 호출합니다.
toWriterImpl로 이동합니다. 전달한 writer가 Fragment이므로 프로그램은 else 분기로 들어갑니다.
private void toWriterImpl(Writer writer, boolean attachCartridge) throws IOException {
if (this.source instanceof File) {
File template = (File)this.source;
if (attachCartridge) {
this.context.attachEventCartridge(DefaultVelocityTemplatingEngine.this.createDefaultCartridge());
}
DefaultVelocityTemplatingEngine.this.velocityManager.writeEncodedBody(writer, template.getPath(), "", DefaultVelocityTemplatingEngine.this.applicationProperties.getEncoding(), this.context);
} else if (this.source instanceof Fragment) {
Fragment fragment = (Fragment)this.source;
if (attachCartridge) {
this.context.attachEventCartridge(DefaultVelocityTemplatingEngine.this.createDefaultCartridge());
}
DefaultVelocityTemplatingEngine.this.velocityManager.writeEncodedBodyForContent(writer, fragment.getContent(), this.context);
}