Gophish: RFC: Gophish Community Store

[jordan-wright]

Shortly after creating Gophish, I created the gophish/templates repository that was meant to be a place where community members could share the templates and landing pages they created.

This never really took off, since it wasn't really clear what the guidelines would be for content that could be added, as well as how members could actually use the content.

I've been thinking more about this and I think we can make this happen. This RFC contains notes on where my head is at right now, but more than anything I'd love feedback to make sure we're both adding value and approaching things the best way possible.

Tl;dr - I'd like to make a platform for community members to share their templates and landing pages, and make it easy to import them into Gophish

Sharing Templates and Landing Pages

If you use Gophish, there's a good chance that the templates or landing pages you've created would be useful to someone else. By working together, we can create a dataset of valuable templates that would let new users get up and running more quickly, and give new simulation ideas to existing users.

While right now I'm considering templates and landing pages to be separate, there's some interesting ideas from @glennzw in #1587 around wrapping these in a "scenario" that's worth some thinking about.

In this new model, sharing new templates or landing pages would simply involve creating a pull request with the data. We'd have a set of Github Actions that validate some of the rules mentioned below, as well as doing some plumbing in the background to make sure everything gets merged successfully.

Restrictions on What is Accepted

We would need some ground rules both to protect Gophish, our users, as well as service provider brands. Here are just some rough thoughts:

• No brand names or logos can be included. This is both to protect the trust between users and service providers as well as to try and protect Gophish from trademark issues.
• All assets must be included and referenced locally. We would update Gophish to automatically handle putting these assets in the static/endpoint folder.
• Minimal, if any, Javascript. And no minification - I just don't want to spend all my time trying to review large blocks of JS looking for potential sneakiness

If these (and other as we think of them) requirements are met, we would consider merging the new data into the store.

Accessing The Data

The open-source platform I'd like to make would live at community.getgophish.com, or similar. It would expose an API that lists the items in the Github repo, letting users browse the available entries directly from within Gophish.

Each entry in the community would have a SHA256 hash (or manifest containing hashes for every file in the entry) associated with it, which would be verified when the contents are downloaded.

After verifying the contents and saving the files, you should be good to go! We can figure out some kind of update mechanism, making it easy for users to install new versions of the entries as they are updated upstream.

Feedback Appreciated!

While I'm excited about the possibilities here, there's definitely a lot to consider. I'd love to hear y'all's thoughts and any other ideas you have on how this can provide the most value to our amazing community.

💚

[glennzw]

I think this is a fantastic idea and have been pondering similar thoughts. I agree that there's so much duplicated work by people recreating templates from scratch, and also I think it can be a barrier to entry to folks who don't have the necessary skills or time to create their own templates.

I love the idea of users being able to browse entries directly from within Gophish. The only thing I'd add here is the option to add your own repo. So, for example, a company could host its own internal repo for internal use and add a link to it from within their Gophish - kind of like adding a source to /etc/apt/sources.list. People could fork the community.getgophish.com repo to host their own. I can imagine this being especially useful for people hosting non-English repos. There could be tabs at the top with "Gophish Store", "Widgets Inc Internal Store", "Русский Магазин", for each one that's added.

Some other thoughts:

• Will users 'execute' templates directly from the browsing area, or would they browse and 'install'. Like an AppStore model
• It might be useful to have a manual import/export option (this is the idea I've been working on, easily allowing me to send you a 'complete' phish).
  
  
  
  • I think it'd be cool to add tags to emails/templates/scenarios. e.g "social media" or "it support".
  
  
  • As discussed in https://github.com/gophish/gophish/issues/1587 it'd be neat to include screenshots and maybe a description field or logo field to 'scenarios'.
  
  
  • A success rate metric would be pretty cool too, i.e how many people fall prey to certain scenarios.
  
  

A bit of a brain dump for the minute, but love this idea and think it's super cool.

[glennzw]

Another thought I had; it'd be powerful to have an arbitrary 'action' item in the campaign builder, which could either be JavaScript, TypeScript, Python or maybe even a Gophish scripting language. So for example a campaign might be:

1. Send DropBox email template
2. Delay for 30 minutes
3. Execute action4.js

action4.js could be:

 if !(userEnteredData(rid)) {
    sendSMS({{.phone}}, "Your email account is locked, click here: {{.URL}}")
  }

...where sendSMS is just an ajax call to Zensend or something. @jordan-wright I know you've said you're not keen to build in SMS capability, so this would offload that. This could also allow calling 3rd party APIs (although I guess that could be done the other way around into the Gophish API).

We could have an extra tab for 'script builder' in the menu to facilitate this. The immediate draw back is security, and as you mentioned you do want minimal JS to prevent sneakiness.

This is a pretty pie-in-the-sky idea, but thought I'd throw it out there.

[quelsan]

Nice idea, Jordan.

I've been doing some work with packaging mail templates and landing pages.
I currently use YAML files which map straight to the values that the Python API client expects.

I think this works quite well for technical users, the only hassle is assets like images for landing pages.
I currently use base64 encoded data URIs for those, but it would be nicer to handle these as files that are automatically propagated to static/endpoint, as you suggest.

Not sure about the scripting, as it seems quite dangerous - but it may be a cool feature.

[jordan-wright]

I like the idea of being able to add your own repo. This will help with the request we get often about larger teams wanting to share resources. Great idea, @glennzw!

Here are some further thoughts:

Will users 'execute' templates directly from the browsing area, or would they browse and 'install'. Like an AppStore model

I see this as an AppStore model. We would download and store locally so that users could potentially modify them. We would also be able to periodically notify if there are upstream updates to the downloaded resources.

It might be useful to have a manual import/export option

We sort of have an import already, though this isn't for both a landing page and a template together. Otherwise, an export and perhaps a consolidated import if we choose to go that route would be useful.

I think it'd be cool to add tags to emails/templates/scenarios. e.g "social media" or "it support".

Definitely!

As discussed in #1587 it'd be neat to include screenshots and maybe a description field or logo field to 'scenarios'.

I think a screenshot and description are absolutely possible. The screenshot could be generated from GH Actions automatically to keep things consistent.

A success rate metric would be pretty cool too.

This one is tricky. I've always thought it would be neat to aggregate completely anonymized data from opt-in users, but there's just so many ways things could go wrong. I think we should hold off on this for now.

Regarding the scripting engine, I would also recommend holding off. Creating a Gophish specific scripting language would be a tremendous amount of work, and allowing arbitrary code execution is historically a can of worms that leads to big problems. But for real, please do keep the big ideas coming!

@quelsan, this is all good feedback! The format of how data is exchanged is 100% up in the air right now.

This is a completely new project that would have its own dedicated codebase, sans the bindings we add to Gophish. It sounds like there's interest in the idea, so if y'all would like, I can create the repo and we can start the design process. This would be a great way to jump into a brand new Gophish codebase to see something built from the ground-up.

Thanks again for all the great feedback!

[glennzw]

This is super exciting. Yes, please create the repo and let's make it happen 🙂

[jordan-wright]

I've renamed the old "templates" repository to "hub". The idea is that we can make hub.gophish.com to hold all the templates and landing pages submitted by the community.

There's a lot to do, so to coordinate efforts, I've made a Google group called "gophish-dev". If you're interested in joining (@glennzw / @quelsan) please shoot me an email with your Github username and your Gmail address, and I'll invite you. 😄

Edit: Please send the info to [email protected].

Looking forward to working together!

[quelsan]

I've been thinking of a packaging format for mail templates and landing pages.
The YAML structure below contains an example of how these may be packaged (scenario/simulation concept borrowed from #1587):

# Versioning the structure allows us to change it in the future, if desired.
structure_version: 1
data:
  scenario:
    name: "My example scenario"
    # See PR #1519
    description: |
      Simple scenario that tries to trick users into submitting their credentials 
      by posing as a....

    version: 1
    author: "Jane Doe"

    # Options that could/should be specified during scenario/campaign creation
    # By adding some more meta-data, we could probably do some error checking
    options:
      - name: "Company name"
        description: "Name of company to include in mail template and landing pages"
        variable: "CompanyName"
        type: "string"
        required: true

      - name: "Company logotype"
        description: "Logotype of company, used in mail banner (preferably 200x200px)"
        variable: "CompanyLogo"
        type: "image"
        required: true

  # Basically the same structure of properties that the Python API client expects
  mail_template:
    name: "My example mail template"
    description: "Description of my example template"

    subject: "Dear user, please click on this link"

    html: |
      <html>
      <body>
      <img src="cid:{{CompanyLogo.FileName}}"/>
      Dear {{FirstName}},<br>
      Your friends at {{CompanyName}} wants you to click on 
      <a href="{{URL}}">this link.</a><br><br>
      <u>Scanned by Example Antivirus</u>
      <img src="cid:antivirus_logo.jpeg"/>
      </html>
      </body>

    text:
      Dear {{FirstName}},
      Your friends at {{CompanyName}} wants you to click on this link:
      {{URL}}

    attachments:
      - name: "antivirus_logo.jpeg"
        type: "image/jpeg"
        content: "SGkgR3V5cyAtIEdvUGhpc2ggbm93ISA6RAo="

      # Create attachment from campaign specific configuration
      - name: "{{CompanyLogo.FileName}}"
        type: "{{CompanyLogo.FileType}}"
        content: "{{CompanyLogo.Content}}"

  # Basically the same structure of properties that the Python API client expects,
  # with the exception of resources
  landing_page:
    name: "My example landing page"
    description: "Description of my example landing page"

    html:
      <html>
      <img src="{{CompanyLogo.FileName}}"/>
      </html>

    # I imagine this as an alternative to "static/endpoint"
    resources:
      # Create resources from campaign specific configuration
      - name: "{{CompanyLogo.FileName}}"
        type: "{{CompanyLogo.FileType}}"
        content: "{{CompanyLogo.Content}}"

This type of file would provide the content and guidance to the user/UI how the options should be presented. The options could either be set during import or at creation of a campaign.

If we do not desire to bundle mail templates and landing pages in scenarios, the structure could be modified to only include one of them.

What do you think about this?

[glennzw]

Hi all,

Just wondering how you're getting on with this Jordan? I'm not sure there's
anything I can specifically help with but if it's bouncing ideas or testing
or anything else I'm up for it. Really love the hub idea and want to
champion behind it. I've kept an eye on the Google design doc.

Cheers,
Glenn

On Mon, Sep 23, 2019 at 3:30 AM Jordan Wright [e-mail]
wrote:

I've renamed the old "templates" repository to "hub". The idea is that we
can make hub.gophish.com to hold all the templates and landing pages
submitted by the community.

There's a lot to do, so to coordinate efforts, I've made a Google group
called "gophish-dev". If you're interested in joining (@glennzw
https://github.com/glennzw / @quelsan https://github.com/quelsan)
please shoot me an email with your Github username and your Gmail address,
and I'll invite you. 😄

Looking forward to working together!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gophish/gophish/issues/1589?email_source=notifications&email_token=AA6INFOD6CJLPGD4R5QEG73QLAS5ZA5CNFSM4IWZDGNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7JVLDI#issuecomment-533943693,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA6INFIPRWKG5Y76PR6ZIL3QLAS5ZANCNFSM4IWZDGNA
.

[jordan-wright]

Hey @glennzw!

It's very much still of interest to me. The hardest part has been finding the time to continue working on it between work, holidays, and balancing other Gophish PR reviews and development.

The next step would be to finalize out that doc, adding the API methods we think would best help us solve the problem. At this point, I'd say the simpler the better so we can get an MVP out the door. I believe you have write access, so don't hesitate to drop in thoughts and feel free to tag me as needed.

When that's in good shape, we can implement things here.

It's my hope that when I can finish reviewing #1612 this weekend, then spend a bit of time on Hub.