Upgrade to Pro — share decks privately, control downloads, hide ads and more …

XSSing Your Way to Shell

XSSing Your Way to Shell

Cross-Site Scripting isn’t new, but there is generally a large belief among vendors, corporations and even some hackers that XSS can only be used to conduct client-side attacks such as session hijacking and similar attacks, or with tools such as BeEF.

A while back I discovered a 0day in vBSEO, that enabled an attacker to inject a payload into the administration control panel, and when this was viewed, the administrator would automatically and unknowingly create a new plugin enabling the attacker to execute arbitrary code on the server. During the early research a simple document.write() was used to write the payload into the administrator’s browser, but as this was visible it was likely that the attack would not go unnoticed and thus an asynchronous payload was developed instead.

The re-developed payload creates a hidden iframe outside the visible frameset, loads the plugin page, and reads the “anti-csrf token” and “administrator hash”, and finally submits a prepopulated form, with the stolen tokens used to authenticate the request. After the weaponized payload was released to the public, more and more independent researchers began to submit their proof of concept’s as weaponized payloads that would grant the attacker arbitrary code execution on the target servers.

Not long ago, the Ubuntu forums were compromised and a study of how it happened began. It was discovered that Canonical’s findings were inaccurate, as the session cookie in vBulletin have had “httpOnly” set for several years, meaning it could not have been session hijacked under normal circumstances. Instead, the attackers used most likely the same or a very similar payload as described above, which brings up the question whether we (the independent researchers) should still release highly weaponized payloads, even if a patch has been issued by the vendor.

This talk dives into finding a 0day in a web application, creating a basic payload, and then; the development of an idea, that becomes an asynchronous JavaScript payload able to use any administrative feature enabling the attacker to execute arbitrary code on the server. During the talk, custom-built JavaScript payloads enabling arbitrary code execution will be demonstrated.

Location: Thursday 29th May 2014 - 12:15 @ Beurs van Berlage - Amsterdam - Netherlands.

Toolkit: https://github.com/Varbaek/xss-shell-payloads
YouTube: https://www.youtube.com/playlist?list=PLIjb28IYMQgoZaHaHUYCc8VsFETfHl4i3
Vimeo: https://vimeo.com/varbaek/videos

86016acd75637c95d22f4fff04aaf5bf?s=128

Hans-Michael Varbaek

May 29, 2014
Tweet

Transcript

  1. Sense of Security Pty Ltd Sydney Level 8, 66 King

    St Sydney NSW 2000 Australia Melbourne Level 10, 401 Docklands Dr Melbourne VIC 3008 Australia T: 1300 922 923 T: +61 (0) 2 9290 4444 F: +61 (0) 2 9290 4455 info@senseofsecurity.com.au www.senseofsecurity.com.au ABN: 14 098 237 908
  2. • • • •

  3. None
  4. None
  5. • • • • •

  6. • • • •

  7. None
  8. None
  9. None
  10. • • •

  11. None
  12. None
  13. None
  14. None
  15. None
  16. None
  17. None
  18. • • • •

  19. None
  20. None
  21. None
  22. None
  23. None
  24. None
  25. None
  26. None
  27. None
  28. None
  29. • • • •

  30. None
  31. • • •

  32. None
  33. None
  34. • • • •

  35. • • •

  36. None
  37. None
  38. None
  39. None
  40. None
  41. None
  42. None
  43. None
  44. None
  45. None
  46. None
  47. None
  48. None
  49. None
  50. None
  51. None
  52. None
  53. None
  54. None
  55. None
  56. None
  57. None
  58. • • • • • • •

  59. None
  60. None
  61. None
  62. None
  63. None
  64. None
  65. None
  66. None
  67. • • • • • •

  68. None
  69. • • •

  70. None
  71. • • • • • •

  72. None
  73. None
  74. • • • • • •

  75. • • • •

  76. None
  77. • • • •

  78. None
  79. None
  80. None
  81. None