BERKE1337 Cyber Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Project Scope ======
The OCF (through Kinn) has contacted us to provide Web Hosting Security. This project consists of 2 parts (projected).

====== Software Tool ======
  * Create a software tool to scan Wordpress sites for malicious plugins
  * Protect student orgs and the OCF from malware
  * ...

====== Project Report ======
  * Provide policy / soft guidelines for OCF Staff
  * Write / research policies for student org website hosting
  * ...

====== Meeting Notes - 9/30 ======
Thanks Nia!

https://wiki.1337.berkeley.edu/
  
 - Use gpg username & password to sign in to Wiki

===== What is OCF (the Open Computing Facility)? =====
  
They run a lot of the student-run hosted infrastructure

======= What is Our Job? =======
  * Figure out a way to prevent and detect insecure information that makes its way to the OCF through ill informed student orgs
  *  Supply OCF with the tools to do so
  *  People make changes to the Word Press site, save their work, and download files with potential vulnerabilities, which end up negatively impacting OCF's websites (they've been 
  *   hacked several times in the past)
  *  Probably should do mini write-ups along the way in order to supply the major write-up at the end
  *  Consider those who might be editing the work in the future
  *  Also consider those who might be using the tools in the future
  *  What info might be useful for these groups to know? (leave comments & include info in write-ups)
  *  Goal: Have something working by the end of the semester
  * 
===== OUR FIRST TASK =====

  
 * Create a development environment that mimics the OCF structure as much as possible
 * Using DOCKER
 * Should include an Apache server with a bunch of different users on it, each of whom has their own home directory on the server (each user has their own website files)
 * Correction: User data is its own container
 * Apache container is separate
 * BY NEXT WEEK → Need a working development environment

======= Brainstorming for How to Solve "The Problem" (Detection Options) =======
  
* Whitelist / Blacklist
* Must be up-to-date
* WPS-Scan
* DVWN
* Number of downloads? Ratings?
* Flag plugins
* Need to know which plugins
* Signature-based
* Idea: Check for suspicious files, IPs, URLs with VirusTotal.com
* Version?
* Last update?
* Logging Aggregation
 
ASSIGNMENTS FOR NEXT WEEK:
  
Everyone knows what they need to do


Questions to have answers to:
  * Is this solution viable?
  * Where would we actually implement it so that it's most useful? (Apache? User data? Somewhere in the middle?)
  * Ask questions if unsure
  * Extra info that could be useful to know?
  * Should we use this tool? Yes or no?

====== Meeting Notes - 10/14 =======

===== Agenda =====
  * Docker updates
  * Project/issue updates

===== Action Items =====

===== Meeting Notes - 10/07 ======

Setting up Docker:

Follow the instructions on the README

  - Install Docker
  - Create a directory and clone the repo
  - run ''docker compose up -d''
  - check that ''http://localhost8080/~studentorg1'' works

To rebuild:

''docker compose down && docker compose up -d''


==== Assignments ====

Scanning through Wordpress sites ()

   * WP-Scan - make an API request and it just scans through **recommended**
  *  WP Pro (i think that's what it's called) - API request that goes through directory and scans for files associated with malicious plugins

Metrics ()

  * Public API for gathering info for plugins
  * 59,000 plugins there
  * Python script written to scrape plugins!
     * Calculate mean, median, std for values
     * if above / below percentile should flag
  * Rating system? - feed in factors to create a threat / vulnerability score

Whitelist / Blacklist ()
  * Wordfence - known blacklist database
  * Patchsack - blacklist database
  * Can combine with WP-Scan, basically aggregating databases

Docker Stuff (Pratham)
  * Need to make it more robust, more like the actual project
  * Probably continuous

Logging Aggregation (Nia)
  * Format and Structure
  * Ease / Velocity
  * Cost / Maintenance Burden - definitely selfhosted
  * Elkstack, Fluentd Gragana, Loki, rsyslog, Greylog, Logalize, ELSA
  * Chat's recs: Grafana, Loki
  * Needs to be a separate container

Signature Based Detection (Nia)
  * Yara, ClamAV, other stuff that I didn't catch :(
===== Agenda =====
  - Docker setup
  - Go through assignments from last week
  - Gitea Issues
  - Assign to Groups

===== Action Items =====
  - [ ] {{person}} to {{task_description}} by {{deadline}}
  - [ ] {{person}} to {{task_description}} by {{deadline}}

===== Next Steps =====
  * {{next_step_1}}
  * {{next_step_2}}
  * {{next_step_3}}


===== Meeting Notes - 10/21 ======

Userdata volumes exist now, there's an open issue to add data to them. Current plan with 3 volumes:

  - userdata1 is default - no plugins
  - userdata2 is good - plugins that are legit
  - userdata3 is malicious - as many plugins as we can find that are bad bad bad

==== Assignments ====

Whitelist Blacklist - big json file pushed of vulnerabilities

Signature Detection - YARA
  * Some preset YARA Rules for detecting wordpress added

Logging Aggregation
  * Alloy (replace Promtail)
  * apparently harder to teach than Promtail
  * need to write documentation for the tool
  * GrafanaLoki + Fluent Bit are current stack, may not even need alloy / promtail
  * infosession 10/22 9 am for GrafanaLoki (I would go but I have class :/ - JQ)

Wordpress Site Scanning
  * probably not feasible: you only get 25 requests per API key
  * 

===== Agenda =====
  - Infra changes
  - Issues

===== Action Items =====
  - [ ] {{person}} to {{task_description}} by {{deadline}}
  - [ ] {{person}} to {{task_description}} by {{deadline}}

===== Next Steps =====
  * {{next_step_1}}
  * {{next_step_2}}
  * {{next_step_3}}