annyoung

파일 다운로드(Local File Inclusion)이번 모의해킹에서는 SpingBoot를 사용하고 있으나 초기에? 사용하던 레거시한 기능에서 파일 다운로드 취약점을 발견했다. 원래 파일 다운로드 취약점, 속히 말하면 LFI(Local File Inclusion) 취약점을 발견하면 이 취약점을 이용해 어디까지 내부 탈취가 가능한가까지 진행하는데, 그 이유는 passwd 고작 그거 받아서 뭐할 수 있는데? 하는 개발자나 윗분들의 생각으로 인해 더 깊게 진행한다.(이런 하나하나의 디테일이 보고서의 퀄리티가 달라지기 때문이기도함) 우선 첫번째로, 변태스럽긴한데 passwd를 다운로드 받아 붙어있는 쉘을 확인해서 이에 맞는 history들을 확인한다. 그리고 이후에는 하나하나 확인하는 과정이 필요하다. 개발자들..

이전에 이어서 파일 업로드할 때 AWS의 S3를 많이들 사용하곤 하는데, 잘못된 설정으로 Public인 경우 버킷 오브젝트를 조회하거나 업로드하거나 삭제할 수 있다. 기업의 개발자/보안 담당자라면 버킷 리스트를 쭉 뽑아서 bash shell/python 등으로 간단하게 작성해서 실행해보길 권장한다. aws s3 ls s3://[BUCKET_NAME]/ --no-sign-request 추측하기로 기업에서 public으로 오픈된 버킷이 존재한다면 다른 버킷도 영향이 있을 수 있다.왜냐면 잘못된 IAM role이 적용되어 있는 public 버킷을 복사해서 그대로 쓰는 경우가 대다수이기 때문이다.

모의해킹 하다보면 가끔 서비스에서 AWS accessKey를 발급하는 API를 사용하는 경우가 있다. 적절한 role을 부여받으면 상관은 없다 생각되는데, 이보다 과도한 role을 배정받는 경우 취약한 경우가 발생하곤한다. 예를 들어서 S3로 파일 업로드할 때 버킷에 업로드하기 위해 accessKey(aws_access_key_id, aws_secret_access_key, aws_session_token)를 요청하고 API에서는 결과를 준다. uploadObject role만 할당받은 경우 업로드만 되기 때문에 덜 취약하다고 생각할 수 있는데, 동일하게 취약하다. 왜냐면 공격자가 경로를 아는 경우 파일을 덮어씌워서 공급망 공격을 할 수 있기 때문이다.아무튼.. accessKey는 대부분 IAM role..

필자는 AWS SES를 통해 보내는 메일들의 로그(로우데이터)가 필요했는데, AWS가 꼭꼭 숨겨두어서 이를 정리해보고자 한다.참고로 AWS는 로깅이아닌 아카이빙이라 칭하더라.  우선 SES의 자격 증명에 도메인을 등록한다. 등록을 위해서는 Route53 또는 타사 도메인의 레코드에 등록해줘야 자격 증명이 확인된다.등록이 완되면 로깅(아카이빙)을 설정하기 위해 등록된 도메인을 클릭한다. 구성 세트의 편집으로 들어간다. 우측의 세트 생성을 클릭한다. 구성 세트 이름을 입력하고 밑으로 내리면 아카이빙 옵션이 존재하는데, 활성화됨에 체크해주자. 다시 돌아와서 기본 구성 세트 할당에 체크해주고, 기본 구성 세트에 방금 만든 세트를 선택하고 변경 사항 저장을 클릭한다. 좀전에 만든 구성 세트(이미지에서는 examp..

가끔 하는데 하다보니 헷갈려서 대충 정리해본다.환경Ubuntu 24.04 LTS (GNU/Linux 6.8.0-1009-aws x86_64) 계정 추가sudo suuseradd -m -s /bin/bash [계정명]passwd [계정명] # 새계정 비밀번호 변경passwd ubuntu # default user 비밀번호 변경passwd # root 비밀번호 변경 sudoers 설정sudo vi /etc/sudoerssudoers 열고 다음 내용 추가[계정명] ALL=(ALL:ALL) ALL그래야 sudo 사용할 수 있다. ssh 설정sudo vi /etc/ssh/sshd_configsshd_config 수정 PasswordAuthentication yesKbdInteractiveAuthenti..