| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
- base64
- Suninatas
- otter
- frida
- 안드로이드
- kibana
- imageinfo
- beebox
- diva
- MFT
- SQL Injection
- Openstack
- Strings
- CTF-d
- dreamhack
- Volatility
- igoat
- 인시큐어뱅크
- filescan
- vulnhub
- binwalk
- lord of sql injection
- InsecureBank
- Docker
- foremost
- elasticsearch
- ctf
- XSS
- 2018
- ESXi
- Today
- Total
목록Docker (11)
Information Security
개요 CVE-2025-14847, 일명 MongoBleed는 MongoDB Server에서 발견된 치명적인 정보 노출 취약점으로, 외부 공격자가 인증 절차를 거치지 않고도 원격에서 서버 메모리의 일부를 유출할 수 있다는 점에서 매우 높은 위험도를 가집니다. 이 취약점은 MongoDB가 클라이언트와 통신할 때 사용하는 네트워크 메시지 압축 기능(zlib)의 처리 과정에서 발생합니다. MongoDB는 네트워크 성능을 향상시키기 위해 압축된 메시지를 수신하고 이를 해제(decompression)하는데, 이 과정에서 특정 조건 하에 메모리 초기화가 제대로 이루어지지 않는 결함이 존재합니다. 공격자는 이러한 결함을 악용하여 의도적으로 조작된 압축 요청을 서버로 전송할 수 있습니다. * zlib 압축 통신 과정에..
Apache Struts2는 Java EE1 웹 애플리케이션 개발을 위한 오픈소스 프레임워크다. Java EE 웹 애플리케이션 분야에서 수많은 활용 사례가 존재한다. Apache Struts2 파일 업로드 우회를 통한 원격 코드 실행 취약점이다. 마찬가지로 파일 업로드 로직 결함으로 인해 발생하며 공격자는 OGNL 표현식2을 이용해 임의의 경로에 웹쉘(Web Shell)과 같은 악성파일을 업로드할 수 있다. S/W 구분취약점 버전Apache Struts2Struts 2.0.0 – Struts 2.3.37Struts 2.5.0 – Struts 2.5.33Struts 6.0.0. – Struts 6.3.0.2 이름정보피해자Struts 6.3.0.2(192.168.238.134)공격자Kali Linux(19..
이 사이트의 컨테이너를 불러온 뒤 워드프레스 설치를 했다. 워드프레스를 다운로드했다. 압축을 풀면 wordpress 디렉터리가 생성된 것을 알 수 있다. 컨테이너로 접속 후 소유자를 daemon으로 변경했다. 해당 디렉터리의 파일들을 backup 디렉터리로 옮겼다. cp 명령어로 wordpress를 컨테이너로 복사했다. wordpress 디럭터리의 파일들을 밖으로 옮겼다. 127.0.0.1 접속하면 wordpress가 설치된 것을 알 수 있다.
test_server.py 코드를 실행시킨다. 다른 터미널에서 접속을 시도한 것을 알 수 있다. 이미지 빌드를 위한 docker 코드를 작성했다. docker build 하는 과정이다. dockerfile 소스코드 대로 등록이 된 것을 알 수 있다. images 명령어를 통해 등록한 것을 볼 수 있다. echo_test image를 -t 옵션을 주면 실행시키면 동작하는 것을 알 수 있다. 접속이 된 것을 알 수 있다.
Hostname이 Docker 컨테이너로 변경되어 쉘로 접속된 것을 알 수 있다. Docker 컨테이너의 파일 시스템을 확인할 수 있다. 로그는 파일에 담긴 로그가 아니라 프로그램이 실행되면서 에러 출력되는 로그들이다. test.txt 파일에 test1234 값을 저장 후 docker cp 명령어를 이용해 docker 안으로 복사했다. 이번에는 Docker 안에서 밖으로 복사가 된 것을 알 수 있다. Docker 컨테이너 이름만 보이게 할 수 있고 docker 전체를 중지 후 삭제시킬 수 있다. rm 옵션을 해도 삭제되지 않았는 데 docker 정지 시 rm 명령어가 동작해 삭제된것을 알 수 있다.
hub.docker.com/r/jupyter/datascience-notebook nginx 설치를 하고 env_name=test1234 환경변수를 적용했다. docker 쉘로 접속 후 printenv 명령어로 확인해 보니 test1234 환경변수를 확인할 수 있다. mysql 환경변수를 적용 후 mysql 다운로드하였다. exec 명령어로 바로 mysql로 접속했다. MySQL 명령어가 동작하는 것을 알 수 있다.
왼쪽: 이미지 A를 지운다 하더라도 이미지 B에서 레이어 A, B, C를 사용하고 있기 때문에 지워지지 않음 오른쪽: 이미 존재하는 레이어 A, B는 새로 다운로드 받을 필요가 없음 Storage Driver가 설치된 위치 overlay2라는 것을 알 수 있다. Docker가 설치 된 위치 /var/lib/docker라는 것을 알 수 있다. docker가 설치된 디렉터리에서 image, overlay2, containers 크기를 확인할 수 있다. docker의 image의 정보를 알 수 있다. 실제 파일시스템을 구성하는 부분이다. rmi 명령어로 삭제 시 이미지가 삭제되는 부분이다. cache-id 확인 서로 다른 것을 알 수 있다. layerdb는 overlay2의 정보를 가지고 있고 실제로 데이터를..
docker nginx를 다운로드하였다. nginx의 이름을 nx로 만들어진 프로세스를 확인했다. start 옵션으로 name nx로 구동시켜도 되고 CONTAINER ID로 지정하여도 된다. 다시 ps 명령어로 확인하면 Create에서 UP로 되어 있는 것을 알 수 있다. nginx가 구동되어 있어 접속하면 기본 페이지를 확인할 수 있다. port와 name을 동일하지 않게 만든 후 프로세스를 확인하면 바로 UP이 되어 있는 것을 알 수 있다. rm 명령어로 삭제가 된 것을 알 수 있다. 동작중인 docker는 삭제되지 않는 것을 알 수 있다. nx를 정지 후 삭제를 하면 삭제된 것을 알 수 있다. nginx 프로세스를 전부 삭제 후 images를 확인 후 nginx 이미지를 삭제했다.