전체 글

어차피 이 세상은 아만보
· Cloud/AWS
이전에 pfsense를 통해 간단한 인프라를 구성하고 suricata 패키지로 IDS/IPS 구동까지 진행했었다. pfsense도 충분히 좋은 솔루션이긴 하지만, 실제로 이런 구성의 인프라를 운영하다 보니 몇가지 큰 문제가 있었다. 1. HTTPS를 적용한 경우 suricata가 트래픽을 정상적으로 분석할 수 없음 이 점이 가장 치명적으로 다가왔었는데, 막상 다 구축해두고 Exploit을 날려보니 suricata의 alert에는 해당 내용이 없어서 계속 확인해 보니 HTTP로 들어온 공격은 잡았지만, HTTPS를 타고온 공격은 잡지 못한 것을 확인했다. 관련해서 내용을 찾은 결과, suricata는 ssl inspection을 제공해주지 않는다는 것을 알게되었다. SSL inspection(SSL 가시성..
· Study/Server
관련 이전 글 : SSRF와 Cloud Metadata -1 'Capital One'에서의 SSRF Cloud Metadata leak을 간단하게 설명했었다. 이와 유사한 취약한 환경을 구축하고 탈취 시나리오를 간단하게 살펴보자 취약환경 구축 인스턴스를 생성 후 SSRF에 취약한 Application을 올린 후, S3 bucket에 대해 full_access 권한을 갖는 IAM role을 만들고 이 인스턴스에 연결해준다. 민감정보를 담을 S3 bucket을 생성하고 object를 넣어준다. (해당 bucket은 인터넷 open하지 않음) 정말 간단하게 취약환경을 구성해 보았다. 'Capital One'의 Exploit과 동일하게 SSRF로 Metadata를 탈취해 S3 bucket의 object까지 탈취..
· Study/Server
SSRF Server Side Request Forgery의 약자로, 직역하면 서버측 요청 위조 서버 측에서 위조된 요청을 발생시켜 직접적인 접근이 제한된 내부 서버의 자원 등에 간접적으로 접근해 데이터 유출 및 오동작을 유발하는 공격이다. 외부로 공개된 서버와 내부망에 존재하는 서비스(DB 등)로 이루어진 구조에서 외부서버가 내부서버로 보내는 요청을 외부 사용자가 임의로 변조하는데, 이때 내부서버는 신뢰할 수 있는 위치에서 전달된 Request로 확인하기 때문에 변조된 Request에 대한 응답값을 반환해준다. 주로 내부 서버에 저장된 이미지와 같은 자원에 접근하거나 외부로 Request를 발생시키는 구간에서 자주 발생하고, 사용자가 제공한 데이터(입력값, 쿠키 등등)을 서버 측에서 별다른 검증 로직없..
· Study/CVE
CVE-2021-21311 [adminer Server-Side Request Forgery] 요약 : 로그인 시 에러메시지를 통해 SSRF Exploit 가능 오픈소스 데이터베이스 관리 툴인 Adminer는 단일 PHP페이지로 구성되어있다. 4.7.9 버전부터 패치가 되었음 (patch commit) Adminer는 각 데이터베이스에 로그인할 수 있는 모듈을 각각 별도로 제작함 취약점이 발생되는 구간은 ElasticSearch와 Clickhouse 로그인 모듈로, 로그인 오류 시 나타나는 에러메시지를 통해서 내부 서버의 자원에 접근할 수 있음 취약한 버전 Adminer 4.0.0 ~ 4.7.8 선행조건 없음 분석 1. 취약한 환경 구성 Victim : ubuntu 22.04 / apache 2.4.52..
보호되어 있는 글입니다.
· Study/Python
이전에 탐지할 객체가 담긴 이미지를 라벨링하고, 학습을 진행했었다. 이제 학습 결과를 바탕으로 모델을 추출하고, 실제 detection까지 진행해보자 모델 추출(Export) 학습을 시작했을때 결과물들이 저장될 경로인 model_dir을 실행인자로 넣어주었다. 학습이 진행됨에 따라 해당 경로에 ckpt라는 파일이 점차 쌓이는데, 이를 체크포인트(checkpoint)라고 한다. 체크포인트는 Tensorflow를 통해 학습된 모델의 구조를 제외한 변수(가중치)만을 담고있는 파일이다. 그렇기 때문에 체크포인트를 바탕으로 재학습이 가능하고, 파일 크기가 크다는 특징이 있다. 이러한 체크포인트는 크기가 커 공유하거나 Tensorflow Serving과 같은 다른 환경으로 배포하기가 힘들다. 즉, 체크포인트를 모델..
· Cloud/AWS
배경 클라우드 상에 운영중인 외부 서비스의 로그 모니터링을 진행하고자 했다. 모니터링 할 대상은 WAF 로그, ALB 로그, DNS Query 로그가 있었고, 추가로 해외 IP 접근 이력, 관리자 페이지에 접근한 IP 등을 모니터링 해줄 것을 요청 받았다. 사실 Cloudwatch를 통해 모니터링이 가능하지만, 더 깔끔한 UI/UX와 모니터링 방법을 원하셨고, Splunk나 ELK의 구축에는 시간도 오래걸리고, 결정적으로 사내에 모니터링 인프라를 구축할 pc가 없었다. 이에 따라 로그모니터링을 위한 외부 서비스를 추천해주셨고, 그것이 바로 DataDog였다. 서비스 소개 DataDog는 on-premise환경부터 클라우드 환경의 서버까지 통합된 모니터링(로그,이벤트)을 할 수 있는 서비스로, 깔끔한 UI..
· Cloud/GCP
캡스톤 프로젝트로 인해 GPU 서버를 사용해야 할 일이 생겼다. 모델 학습에는 내 본체의 GPU를 이용해 어떻게 학습 모델을 추출하기는 했으나, 이걸 웹서버 백엔드단으로 올려서 이미지를 받고 이미지내에서 객체 검출을 해 반환을 해줘야 했다. 학교가 네이버 클라우드(ncloud)와 협약을 맺어서 무료 크래딧 20만원을 사용할 수 있다고 해서 찾아봤지만, GPU 서버는 기본적으로 개인계정에서 생성을 제한한다고 한다. 개인계정에서 GPU서버, 고사양 CPU서버등의 고가용성 서버를 사용하기 위해서는 신청서를 작성해 제출하고, 또 서버 결제에 크레딧과는 다른 재화인 '코인'을 사용해서만 결제를 할 수 있다고 한다. 단순히 tensorflow 테스트를 할 뿐인데 신청서를 작성하고 코인 재화를 선결제해야하는 등의 작..
Omoknooni
Memorize