TIME

NEPAL QATAR BELFAST, UK MALAYSIA DUBAI

Saturday, May 9, 2020

Powerob - An On-The-Fly Powershell Script Obfuscator Meant For Red Team Engagements


An on-the-fly Powershell script obfuscator meant for red team engagements. Built out of necessity.

Installation
git clone https://github.com/cwolff411/powerob

Usage
python3 powerob.py obfuscate originalfile.ps1 obfuscatedfile.ps1
Takes an INPUTFILE obfuscates it and dumps the obfuscated version into OUTPUTFILE.
python3 powerob.py list
Lists all of the currently obfuscated files along with their commands and associated obfuscated commands.
python3 powerob.py getcommand Invoke-AllChecks
For reference on the fly for when you forget. Takes the original command name and displays the obfuscated command name to be used in Powershell.
python3 powerob.py cleardb
Maintenance function to clear the db of past obfuscated files and functions.

About
This was built out of the need to bypass endpoint security on a recent engagement. During priv esc attempts I could not download PowerUp.ps1 until it was obfuscated.
This is v1. It obfuscates the functions only and I will enhance the functionality as time allows. Pull requests and collaboration welcomed.
I work at Layer 8 Security. Come say hi.

License
MIT License




via KitPloitRelated news

Group Instant Messaging: Why Blaming Developers Is Not Fair But Enhancing The Protocols Would Be Appropriate

After presenting our work at Real World Crypto 2018 [1] and seeing the enormous press coverage, we want to get two things straight: 1. Most described weaknesses are only exploitable by the malicious server or by knowing a large secret number and thereby the protocols are still very secure (what we wrote in the paper but some newspapers did not adopt) and 2. we see ways to enhance the WhatsApp protocol without breaking its features.


We are of course very happy that our research reached so many people and even though IT security and cryptography are often hard to understand for outsiders, Andy Greenberg [2], Patrick Beuth [3] and other journalists [4,5,6,7,8] wrote articles that were understandable on the one hand and very accurate and precise on the other hand. In contrast to this, we also saw some inaccurate articles [9,10] that fanned fear and greatly diverged in their description from what we wrote in our paper. We expected this from the boulevard press in Germany and therefore asked them to stick to the facts when they were contacting us. But none of the worst two articles' [9,10] authors contacted us in advance. Since our aim was never to blame any application or protocol but rather we wanted to encourage the developers to enhance the protocols, it contradicts our aim that WhatsApp and Signal are partially declared attackable by "anyone" "easily" [9,10].

Against this background, we understand Moxie's vexation about certain headlines that were on the Internet in the last days [11]. However, we believe that the ones who understand the weaknesses, comprehend that only the malicious server can detectably make use of them (in WhatsApp) or the secret group ID needs to be obtained from a member (in Signal). As such, we want to make clear that our paper does not primarily focus on the description of weaknesses but presents a new approach for analyzing and evaluating the security of group instant messaging protocols. Further we propose measures to enhance the analyzed protocols. The description of the protocols' weaknesses is only one part of the evaluation of our analysis approach and thereby of the investigation of real world protocols. This is the scientific contribution of our paper. The practical contribution of the analyzed messengers, which is the communication confidentiality for billion users (in most cases), is great and should be noted. Therefore we believe that being Signal, WhatsApp, or Threema by applying encryption to all messages and consequently risking research with negative results is much better than being a messenger that does not encrypt group messages end-to-end at all. We do not want to blame messengers that are far less secure (read Moxie's post [11] if you are interested).

Finally we want note that applying security measures according to the ticket approach (as we call it in the paper [12]) to the invitation links would solve the issues that Facebook's security head mentioned in his reply [13] on our findings. To our knowledge, adding authenticity to group update messages would not affect invitation links: If no invitation link was generated for a group, group members should only accept joining users if they were added by an authentic group update message. As soon as a group invitation link was generated, all joining users would need to be accepted as new group members with the current design. However there are plenty ways how WhatsApp could use invitation links without endowing the server with the power to manage groups without the group admins' permission:
One approach would be generating the invitation links secretly and sharing them without the knowledge of the server. An invitation link could then contain a secret ticket for the group and the ID of the group. As soon as a user, who received the link, wants to join the group, she can request the server with the group ID to obtain all current group members. The secret ticket can now be sent to all existing group members encrypted such that the legitimate join can be verified.

Of course this would require engineering but the capability of WhatsApp, shipping drastic protocol updates, can be assumed since they applied end-to-end encryption in the first place.

[1] https://www.youtube.com/watch?v=i5i38WlHfds
[2] https://www.wired.com/story/whatsapp-security-flaws-encryption-group-chats/
[3] http://www.spiegel.de/netzwelt/apps/whatsapp-gruppenchats-schwachstelle-im-verschluesselungs-protokoll-a-1187338.html
[4] http://www.sueddeutsche.de/digital/it-sicherheit-wie-fremde-sich-in-whatsapp-gruppenchats-einladen-koennen-1.3821656
[5] https://techcrunch.com/2018/01/10/security-researchers-flag-invite-bug-in-whatsapp-group-chats/
[6] http://www.telegraph.co.uk/technology/2018/01/10/whatsapp-bug-raises-questions-group-message-privacy/
[7] http://www.handelsblatt.com/technik/it-internet/verschluesselung-umgangen-forscher-finden-sicherheitsluecke-bei-whatsapp/20836518.html
[8] https://www.heise.de/security/meldung/WhatsApp-und-Signal-Forscher-beschreiben-Schwaechen-verschluesselter-Gruppenchats-3942046.html
[9] https://www.theinquirer.net/inquirer/news/3024215/whatsapp-bug-lets-anyone-easily-infiltrate-private-group-chats
[10] http://www.dailymail.co.uk/sciencetech/article-5257713/WhatsApp-security-flaw-lets-spy-private-chats.html
[11] https://news.ycombinator.com/item?id=16117487
[12] https://eprint.iacr.org/2017/713.pdf
[13] https://twitter.com/alexstamos/status/951169036947107840

Further articles:
- Matthew Green's blog post: https://blog.cryptographyengineering.com/2018/01/10/attack-of-the-week-group-messaging-in-whatsapp-and-signal/
- Schneier on Security: https://www.schneier.com/blog/archives/2018/01/whatsapp_vulner.html
- Bild: http://www.bild.de/digital/smartphone-und-tablet/whatsapp/whatsapp-sicherheitsluecke-in-gruppenchats-54452080.bild.html
- Sun: https://www.thesun.co.uk/tech/5316110/new-whatsapp-bug-how-to-stay-safe/
Related word

Save Your Cloud: DoS On VMs In OpenNebula 4.6.1

This is a post about an old vulnerability that I finally found the time to blog about. It dates back to 2014, but from a technical point of view it is nevertheless interesting: An XML parser that tries to fix structural errors in a document caused a DoS problem.

All previous posts of this series focused on XSS. This time, we present a vulnerability which is connected another Cloud Management Platform: OpenNebula. This Infrastructure-as-a-Service platform started as a research project in 2005. It is used by information technology companies like IBM, Dell and Akamai as well as academic institutions and the European Space Administrations (ESA). By relying on standard Linux tools as far as possible, OpenNebula reaches a high level of customizability and flexibility in hypervisors, storage systems, and network infrastructures. OpenNebula is distributed using the Apache-2 license.


OpenNebula offers a broad variety of interfaces to control a cloud. This post focuses on Sunstone, OpenNebula's web interface (see Figure 1).

Figure 1: OpenNebula's Sunstone Interface displaying a VM's control interface

Before OpenNebula 4.6.2, Sunstone had no Cross-Site Request Forgery (CSRF) protection. This is a severe problem. Consider an attacker who lures a victim into clicking on a malicious link while being logged in at a private cloud. This enables the attacker to send arbitrary requests to the private cloud through the victims browser. However, we could find other bugs in OpenNebula that allowed us to perform much more sophisticated attacks.

Denial-of-Service on OpenNebula-VM

At its backend, OpenNebula manages VMs with XML documents. A sample for such an XML document looks like this:
<VM>
   <ID>0</ID>
   <NAME>My VM</NAME>
   <PERMISSIONS>...</PERMISSIONS>
   <MEMORY>512</MEMORY>
   <CPU>1</CPU>
   ...
</VM>
OpenNebula 4.6.1 contains a bug in the sanitization of input for these XML documents: Whenever a VM's name contains an opening XML tag (but no corresponding closing one), an XML generator at the backend automatically inserts the corresponding closing tag to ensure well-formedness of the resulting document. However, the generator outputs an XML document that does not comply with the XML schema OpenNebula expects. The listing below shows the structure that is created after renaming the VM to 'My <x> VM':
<VM>
   <ID>0</ID>
   <NAME>My <x> VM</x>
      <PERMISSIONS>...</PERMISSIONS>
      <MEMORY>512</MEMORY>
      <CPU>1</CPU>
      ...
   </NAME>
</VM>
The generator closes the <x> tag, but not the <NAME> tag. At the end of the document, the generator closes all opened tags including <NAME>.

OpenNebula saves the incorrectly generated XML document in a database. The next time the OpenNebula core retrieves information about that particular VM from the database the XML parser is mixed up and runs into an error because it only expects a string as name, not an XML tree. As a result, Sunstone cannot be used to control the VM anymore. The Denial-of-Service attack can only be reverted from the command line interface of OpenNebula.

This bug can be triggered by a CSRF-attack, which means that it is a valid attack against a private cloud: By luring a victim onto a maliciously crafted website while logged in into Sunstone, an attacker can make all the victim's VMs uncontrollable via Sunstone. A video of the attack can be seen here: