ashirt-ops/ashirt-server

Adversary Simulators High-Fidelity Intelligence and Reporting Toolkit

ashirt-server's Issues

ASHIRT Tagging Features

• While on tag edit page, add filter toggles to the header (filter tags by alphabetical order, by number of evidence attached, or by date tag was added)
• While on tag edit page, clicking on tag would bring you to tag's evidence filter view

Super admins don't see all operations in admin area

The list of operations in the admin area only displays operations that the user is a member of.

Group operations by status on main page.

Once you have completed many operations, the main page can get very busy, with lots of completed operations filling up the page and making it harder to find a specific one still being worked on.

It would be cool to have the pending/active/complete operations in separate sections/groups for a better visual context of which ones are still being worked on.

Also, having the ability to toggle hide/collapse those groups would be useful for managing the visual clutter.

GCP Storage

It looks like the only remaining coupling ashirt has with AWS is s3 storage.
Ashirt should have the ability to also target GCP storage for evidence.

Add toggle for evidence zoom

Add the ability to toggle the zoom for fit and full when the evidence modal is up.

Help dialog for search queries

Currently we have a help modal that pops up or hotkeys in the timeline. It would be nice to have a modal that describes all the options for the search queries and how to use it as right now you either need to guess or know. I don't think we need to tie it to a hotkey, so we don't need to worry about hotkey collision for help but maybe have an icon next to the search bar to pop it up?

Are there technical issues with implementing it this way? If needed we could always add this into the normal help modal but I think having a separate one would probably be a bit nicer to keep things separate.

Mature authentication offering

This is more of a tracking issue for a series of features around building out and maturing the authentication capabilities of ashirt. This is meant to ask and answer questions so that we can move toward creating the set of individual features that we'll end up actually building. This issue does not mean that all of the below features have the same priority or that we need to build all of them but they are at least worth discussing and coming up with a plan for if and when they will be built.

Currently ashirt supports local auth and okta which meets our needs internally and likely the needs of some potential users. In general we're missing integration with some other common single sign on options and new/upcoming mfa options that we are likely to see others desiring to use. This will split into two categories: authN and mfa options.

AuthN

• Generic OIDC2 (can okta share this?)
• SAML
• webauthn

MFA

• u2f/FIDO2

Overview causes internal server errors for some operations

Digging into this, it is caused by group_concat hitting it's maximum length during concatenation which results in malformed dates after a certain point if there are over a certain number of tags present.

Make finding categories editable

Currently the finding categories are a fixed list of options. Let's make this editable from the admin interface and instead store them in the database.

Requirements

1. Editing the list should be only allowed by a system administrator
2. The list of categories should be controlled system wide (not unique to a specific operation)
3. Seed data should be provided to create the current set as the default options

Unknown questions

1. What is the behavior when a category that a finding uses is removed?

Failing to build on windows

Need to dig into what is failing to execute. This is all in the container so many it's pathing issue, converting from windows to linux separators.

1. docker compose up --build

Provide logs (if relevant):

ashirt-server-backend-1   | standard_init_linux.go:228: exec user process caused: no such file or directory
ashirt-server-backend-1 exited with code 0
ashirt-server-backend-1 exited with code 1
ashirt-server-backend-1 exited with code 1
ashirt-server-backend-1 exited with code 1
ashirt-server-backend-1 exited with code 1
ashirt-server-backend-1 exited with code 1
ashirt-server-backend-1 exited with code 1
ashirt-server-backend-1 exited with code 1

Add filtering by evidence type

Create a new search tag to allow searching by a specific evidence type (eg. only screenshots, text snippets, etc.)

Account recovery is broken

Golang version (go version): 1.14

OS version (uname -a if on a Unix-like system): N/A

Description of the problem including expected versus actual behavior:

When a recovery code/url is used, recovery validation occurs (and is successful), but the next call to /user fails due to an authentication issue, kicking the user back to the login screen.

Steps to reproduce:

1. Have an instance with 2+ users: one admin (call 'A') and one other (call 'B')
2. Have the admin log in. Go to the admin screen, then user management
3. Find user B, then click the actions arrow and select "Generate Recovery Code". Copy the recovery code, and in an incognito/private browser window, try using that code

Result: user gets sent to the autherror/recoveryfailed endpoint, and the user can only return to the main menu
Expected Result: the user should be logged in temporarily, and be prompted to change their password.

Provide logs (if relevant):

timestamp=2020-09-29T22:36:12.505346177Z ctx=e4fa9531-1234-444d-9e79-88070c360fa9 msg="Incoming request" method=GET url="/auth/recovery/login?code=usLFdafsSK_RMb0a0T_e-oY-XRhuWTIgiPMWsRNQApRunTkFPqfquA==" from=192.168.144.4:47614
timestamp=2020-09-29T22:36:12.50575902Z msg="executing query" query="SELECT user_id FROM auth_scheme_data WHERE user_key = ? AND TIMESTAMPDIFF(minute, created_at, ?) < ?" values="[usLFdafsSK_RMb0a0T_e-oY-XRhuWTIgiPMWsRNQApRunTkFPqfquA== 2020-09-29 22:36:12.505709587 +0000 UTC m=+19.113118880 1440]"
timestamp=2020-09-29T22:36:12.506491846Z msg="executing query" query="DELETE FROM auth_scheme_data WHERE user_key = ?" values="[usLFdafsSK_RMb0a0T_e-oY-XRhuWTIgiPMWsRNQApRunTkFPqfquA==]"
timestamp=2020-09-29T22:36:12.517034011Z ctx=e4fa9531-1234-444d-9e79-88070c360fa9 msg="Request Completed" status=302 sizeInBytes=48 duration=11.689908ms
timestamp=2020-09-29T22:36:12.748556113Z ctx=4a2cfeb4-1034-499b-97db-a562fe8ccfa0 msg="Incoming request" method=GET url=/user from=192.168.144.4:47632
timestamp=2020-09-29T22:36:12.748705095Z ctx=4a2cfeb4-1034-499b-97db-a562fe8ccfa0 msg="Error handling request" error="Unwilling to read user : DenyPolicy failed permission check policy.CanReadDetailedUser{0}" status=404 url=/user
timestamp=2020-09-29T22:36:12.748745507Z ctx=4a2cfeb4-1034-499b-97db-a562fe8ccfa0 msg="Request Completed" status=404 sizeInBytes=21 duration=197.72µs

Create new "event" evidence type

The original implementation of ASHIRT had evidence and events as the two highest level types in the timeline hierarchy. The original intent I don't believe was understood widely and events eventually morphed into findings as a method which are useful but don't quite capture the intended function of events. My original concept for events was to capture points in time where some action took place (eg. completion of a phase, accomplishment of some objective, etc.) They represent some important event happening and apply a timestamp to it but don't contain direct evidence because because all of that is supported by the evidence that already exists in the timeline.

How events differ from findings

A finding is some insight that should eventually be reported to stakeholders and addressed. Findings capture a collection of evidence that supports a specific finding but findings themselves don't represent a specific point in time. They link a group of evidence to prove that some outcome took place. Events are a single point in time where some discrete thing took place. They are a marker to be used for re-constructing a high level timeline of when specific key events took place during an operation. This is useful for reconciling detections (or lack there of) at a high level without having to look at each supporting piece of evidence to re-construct a timeline of when the event took place but have a rough estimate.

What events should contain

All of the normal evidence data (eg. description/title, timestamp, operator, operation, etc.) but they need no attached evidence. It would probably make sense to create some sort of icon that we can place in the timeline that all events share so that it can be rendered along with the other evidence.

Supporting work

While useful on its own this would become much more useful if #339 were implemented. This would allow for an operator to filter for just events creating a high level timeline of the major milestones that took place during an operation without having to use tags or some other hack in order to implement this using existing functionality.

Visible error for multifactor options with local auth

Description of the problem including expected versus actual behavior:
When local auth is disabled if you go to the security tab in account settings there will be a 404 page under the multifactor heading. I'm assuming this is because the routes aren't added since the auth method is disabled. It's probably fine for multifactor to be tied directly to local auth and let other providers worry about how they'll do additional factors but it probably shouldn't error out.

Steps to reproduce:

Please include a minimal but complete recreation of the problem,
including (e.g.) index creation, mappings, settings, query etc. The easier
you make for us to reproduce it, the more likely that somebody will take the
time to look at it.

1. Disable local authentication (and use just Okta)
2. Start server
3. Go to security tab in account settings (http://localhost:8080/account/security)

In Query Builder, the combo boxes don't hide their drop downs when they become unselected.

While viewing All Evidence on an operation with pre-existing tags and users, open the Query Builder by clicking on the pencil icon in the Filter timeline text box at the top of the screen.

Query Builder pops open.

Click into the "include tags" field. A drop down appears with all current tags. Do not select any tags.
Click onto the "Sort Direction" drop down, guess that it's the "Sort Direction" box because the tags list doesn't disappear and hides everything below it.
Click on the Users drop down, same problem, all the lists are still open and overlapping.

Tags Pagination

In operation settings the tags page should have pagination and a filter box similar to how users are displayed.

Upgrade and rewrite docker-push integration for actions

A major release of the docker-push action has been released and is incompatible with our current setup. Most specifically the tagging options have changed and we can no longer get the exact tagging behavior we want out of the box. We can either redefine one of the steps for the action to add the correct logic or switch our tagging behavior.

Left rail icons overlapped

It looks like after adding in the icon for the overview view can now cause the icon to overlap with the icon.

Minor UI tweaks

This issue captures some UI comments that were brought up during a demo.

• When logging into a new operation, reading L > R "create finding" is listed before "create evidence" we should consider swapping the order since evidence is used first, and more ofted.
• When entering timeline view of a blank operation the generic error "Tags are not being utilized" could be more helpful. Including messaging about the purpose of the page after tags are added would be useful.

Don't bring user to top after editing evidence

When a user edits evidence currently the entire page seems to re-render bringing the user back to the top of the timeline. Not sure if the re-render is necessary or not but if it is can we redirect the user to an anchor at the evidence they just edited to keep them where they were or some other solution?

Implement UI based query builder

#217 will make it much simpler to identify all the options for writing filter queries but it still requires manually writing it out. It would be nice to have a UI based building like the one that exists in the ashirt client.

Add evidence type search to help and query builder

#429 added support to search based on the evidence type however the option was not added to the query builder or information about how to use it added to the search help modal. Let's get it added to both.

Multi-word tags urls on settings page go to invalid URLs in the evidence view

If you click on a multiword tag on the settings page to view all evidence with that tag, no evidence will be displayed.

The tag is generated without a set of enclosing double quotes and thus is treated like multiple different search values.
eg you see tag:foo bar baz instead of tag:"foo bar baz".

HTTP evidence type

Create a new evidence type for representing HTTP request/responses. This evidence type should be capable of storing either a single or multiple request/response pairs.

Upload

Uploading of request/response pairs should be handled by the web UI for the initial implementation and function similarly to how the image upload currently works. A set of pairs should be uploaded as a single file.

Visualization

Unclear what the best visualization method is for this data type. There are existing HAR viewers available, though many are old and may no longer be supported at this point. From a data standpoint we don't care about the timing information that HAR visualizers provide, as we don't care about performance data. We also specifically want to make sure that no rendering of HTML content or images is performed as it may contain live exploits that could trigger. Utilizing the syntax highlighting from ace may make sense if we can correctly identify the content type from the headers. One possible other UI option is to build something like burp.

Format

It probably makes sense to store the data uploaded as a file in the storage backend rather than the database itself as these could be fairly large. There are no hard requirements on the file format but HAR likely makes the most sense because it is the most universally supported. We should probably put some effort into understanding if there is a better alternative as the spec has not been ratified and it seems that development on HAR has stalled.

Exports

• cURL request (required)
• Burp session (maybe)
• HAR (if we use HAR for storage just allow it to be saved otherwise not required)

Add endpoint to create new operation

Expose an endpoint in the api server to allow creation of a new operation. We likely will be able to use the same handler from web and just expose a route. Let's make sure we don't expose all the other handlers (eg. edit, delete, etc.) to the api server.

Switch dependencies to monthly

Dependabot is still pretty loud for npm and go after switching it to weekly due to the number of dependencies and frequency that some release. It's probably safe to push this to monthly.

Update node major release

We're current still using node 14.14; upgrade to 16.

Full logout needed after admin promotion

Description of the problem including expected versus actual behavior:
On account promotion to admin, the user can view the admin page, but there are errors for each of the views. The user must log out of ashirt and log back in to fix.
Steps to reproduce:
and

1. Log in as non-admin user, and as admin user.
2. Promote non-admin to admin
3. Attempt to view admin settings as new admin

Provide logs (if relevant):

Remove limitation to delete last auth method

Currently it's impossible to remove the last auth method. This means that if you only have one auth method (eg. okta) but your auth info get's desynced from the IDP you're not able to simply unlink and re-link with the new data. We can already handle getting a locked out user back in via recovery codes but once they're in there's no way to get permanent access back to their account.

There are clearly frontend changes that need to be made to allow the UI to allow this behavior; unsure if backend safeguards need to be removed as well.

Move evidence between operations

Provide the ability to move evidence from one operation to another. This is not as straightforward as just changing the foreign key in the row because the associated tags are references to tags that exist in the operation and not globally. Based on the recently added work to allow tagging at creation time, we have two options:

1. Delete tags that exist then move the evidence over
2. Try to match referenced tags to existing ones in the other project or create new ones, if they don't exist, remove existing tag references, the move the evidence over.

I'm open to either currently.

Choose between chronological and reverse chronological order for saved queries

Currently we provide all evidence in reverse chronological order in the timeline. Can we add an option to the saved query dialog to switch between chronological and reverse chronological? We don't need to currently add this to the general timeline but maybe in the future a second feature to do that?

+ isn't centered for new operation button

The + is slightly above the center point in the circle. Setting the line height to 43px rather than 40px seems to center it but I'm not quite sure why. The width and height of the div are 40px so 40px for the line height should make sense.

Add webauthn as an auth scheme

#304 was closed out after the auth was rebuilt to support generic OIDC2. We should evaluate adding support as webuathn as an auth scheme for non-federated authentication. Not 100% sure if it makes sense to use it simply as an alternative second factor to TOTP or as a totally separate passwordless auth scheme.

Cache for frontend is stale sometimes after update

Unclear where the actual issue is (nginx or file generation) but after an update refreshing can sometimes cause 404 for loading CSS. Doing a full refresh cmd+shirt+r that busts the cache seems to fix it. Can provide more context next time it occurs.

Switch default evidence zoom to fit

The default zoom should be zoom to fit rather than full size.

Add ability to remove operations

Provide the ability to remove existing operations

Requirements

1. This action should remove all associated data with the operation: tags, findings, evidence, etc.
2. A new option should be added to the operation settings page to perform a deletion. This should require a confirmation (typing the operation name) in a modal and only be allowed by an operation admin. The modal should also warn that it is unsafe to redeploy a server during a delete operation

Help modal is triggered when typing '?' key in text boxes

When entering a question mark in any of the input fields

Steps to reproduce

1. Click "Create Evidence"
2. enter '?' into the description field

Switch recovery token from base64 to hex encoding

This isn't particularly a bug but it's also not a feature request. Using base64 is not ideal here as base64 will use = to encode padding. = has special meaning in GET data so we should avoid using this scheme here. It seems to work correctly in Chrome but it's possible that another browser may get confused or handle this incorrectly. We might as well get ahead of this and remove any ambiguity of how the data should be handled.

Provide more visibility for server errors and improve logging

Currently it's pretty difficult to identify where an issue is occurring in the case of a server failure. Any condition that is going to result in a 5xx error should provide a stack trace. We should put some thought into logging overall and and ensure that it is both easy to ingest, easy to read, and easy to act on. Current logging is alright and at least traceable due to the request identifiers. Shoving a stack trace into the log event may not be as trivial due to needing to handle escaping the newlines and quotes for the the structured logging used. Let's spend some time reviewing what fields are present and exactly how to handle this.

Admins do not 404 for operations they are not a member of

When a super admin force browses to an operation that they are not a member of they are able to load the page with a timeline though the media and left rail fails to load. From here they are able to interact with the operation and read content or force browse to the operation settings view where they can perform any action including adding themselves as a member with whatever permission is desired.

Docker images tagged with SHA even in PRs

It looks like we're tagging images on docker hub for all builds, even those that are part of PRs, rather than just out of master. This might just be a misunderstanding of how tag_with_sha works. Tagging of images should follow the following rules:

• short commit (master)
• latest (master)
• version (tag)
• pr-### (pr)

Default Operation Tags

Server administrators should be able to manage a list of default tags that are copied into new operations. This will help teams reduce tag duplication.

In contrast to custom findings categories, we do not want to offer any default tags within the product.

Unable to select tags with cursor

When editing a finding in the web ui a user can press the backspace key to remove the rightmost finding only. The cursor in the edit window does not allow selection of any preceding tags.

Add self service account recovery

Currently account recovery requires an admin to manually generate a recovery code for the user. It probably makes sense to provide a self service way to handle this as well. One of the reasons this wasn't an original requirement was that it would need a way to send emails which currently doesn't exist.

Requirements

1. Button the login page to start the account recovery workflow
2. System for sending emails; it probably makes sense to abstract this so we can send others if needed, but for now this is the only use case. Unclear if we'll want to just support SMTP or may want to build an interface where we can build multiple backends (SMTP, SES, etc.)

Remove screenshot client code and restructure repository

With the rewrite and migration to the new client it should be safe to remove this code once the new client is open sourced. We should take this time to re-structure the repo as this one shifts to becoming just the server side components and not a monorepo for the full project.

Update docker-push and rewrite tagging behavior

A major release of the docker-push action has been released and is incompatible with our current setup. Most specifically the tagging options have changed and we can no longer get the exact tagging behavior we want out of the box. We can either redefine one of the steps for the action to add the correct logic or switch our tagging behavior.

Make deployment easier

Currently unless you're using k8s with our internal helm charts to throwing up the environment on a single host using docker-compose and reverse proxying deploying ashirt-server is actually pretty hard. There are containers available publicly but there's not really good resources for orchestration and there's a lot of magic that happens in the containers to make them communicate with each other. We should make this simpler.

This should probably lead a milestone and a series of tickets, not all of which necessarily need to be the same priority but will get us to a place where other teams can easily use ashirt as well.

Some questions we might want to answer:

1. What deployment scenarios are officially supported (different container orchestration, raw executables and files, etc.)
2. What new artifacts need to be produced to support these?
3. What documentation needs to be written?
4. Can we make any of the reverse proxying, hostname logic, etc. simpler and less hard coded?
5. Does a production deployment need to be tied to aws?

Disable Registration Flag

When the service is deployed publicly or semi-publicly there is no way to disable the register functionality. This means that people can register on the site and while they cannot view other operations they can still create new operations and upload data.

It would be great to have a way to disable registration once the users have been onboarded. Or make users disabled by default so that they must be approved by an admin.

Leading and trailing whitespace not trimmed from filter bar GET request

This doesn't appear to affect the filter showing results but whitespace is included in GET request and ends up urlencoded in the URL.

eg hxxps://ashirt-server/operations/sneakyop/evidence?q=tag%3A%22first%20name%22%20

Add button to copy evidence to clipboard

Not sure if this is something that will work cross os, cross browser, or make sense for all evidence types but it something that would be nice would be to have a button that copies at least images directly to the clipboard. When writing reports it's annoying to have to download each image and then drag it into program one at a time.

Not sure what makes the most sense in terms of UI. Maybe adding another option to the dropdown that already exists for options?