Ideas for Boefjes

[Darwinkel]

I spent some time going through the open issue list at the Boefjes closed source repository. Many issues did not contain meaningful details beyond the title. We should probably re-evaluate the status of below issues/ideas.

Suggested for implementation

• IPv6 reachability for hostnames
• Security options to boefje/bit
• Google Lighthouse (https://github.com/GoogleChrome/lighthouse)
• RDAP
• HTTP header boefje should couple hostnames if they exist in header
• snyk.io frontend vurls, and License info on JS libs
• ssh-audit (https://github.com/arthepsy/ssh-audit)
• Reverse DNS
• Add DV/OV/EV to certs
• https://endoflife.date/ (with difference between software that is about to lose support, and software that is no longer supported)
• Atomist integration for found Docker images (https://dso.docker.com/explore)
• DNSSEC
• Log4j
• Is the website green? (https://admin.thegreenwebfoundation.org/api-docs/)

Actually in-progress

• Eisen Rijk (https://github.com/minvws/nl-rt-tim-abang-boefjes/projects/3)

Internet.nl

• DANE
• Certificates
• TLS
• HTTP compression headers

Ideas

• Cookie parsing (https://cookiedatabase.org/)
  We should start creating cookie objects from HttpHeaders, in this step we should be carefull to normalize values and expiration dates to repeatable values instead of the actual times / values seen in the HttpHeaders. From there we can use the site https://cookiedatabase.org/ for added information via the knowledge base about various cookies.
  A simple bit could be created which looks for httpheader ooi's, and then finds cookie headers in them allowing us to create cookie OOI's.
  On these cookie ooi's a list of optional arguments is possible:
  Set-Cookie: =
  Set-Cookie: =; Expires=
  Set-Cookie: =; Max-Age=
  Set-Cookie: =; Domain=
  Set-Cookie: =; Path=
  Set-Cookie: =; Secure
  Set-Cookie: =; HttpOnly
  Set-Cookie: =; SameSite=Strict
  Set-Cookie: =; SameSite=Lax
  Set-Cookie: =; SameSite=None; Secure
  https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cookie
  Other arguments might raise a finding as being incorrect.
  In a second bit we might want to evaluate various of these flags as 'unwanted', eg, cookies that are not ' Secure, HttpOnly, SameSite', could be flagged.
  Also, once cookies are properly modeled we can create bits who flag various tracking cookies, or even detect some used software.
  Also, cookies who are allowed to persist for a very long time might be flagged.

• Create finding on any A/AAAA/CNAME dns record that points to a private IP-range on a public domain
  (When a public Domain contains any record pointing to a private IP, its possible for a local network to offer up a webserver on this IP for the domain affected, and by doing to get access to the browser's security domain for the affected domain. Eg: bank.com is secure. internal.bank.com resolves to 10.0.0.5. victim with bank.com cookies connects to malicious (Wifi) network. malicious network directs victim to visit internal.bank.com which is now routable to server hosted by malicious network. malicious network's javascript code, served in bank.com's security domain now has access to cookies (etc) for bank.com on victims browser. We should create a finding for any record that makes this possible. Once the DNS records have been collected, this can be ran as a Bit on any record matching the criteria.)

• Resource hash to software details (https://circl.lu/services/hashlookup/)
  find the md5sum for a file: (normally we would already have the contents in the resource's proof, or we would maybe have the hash stored already.
  sum=$(wget -O- https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.0/jquery.min.js | md5sum | awk '{print $1}')
  Match the hash against the api: curl -X 'GET' "https://hashlookup.circl.lu/lookup/md5/$sum" -H 'accept: application/json'

• Create deny-list for world-writable domains in CSP headers
  Some domains allow anyone to create an account, and publish code / files. These domains would be unwise to add in your CSPheaders, since they would allow attackers to simply create an account, and start publishing malicious files who would pass the CSP headers. Once parsed, a BIT could hold the CSP headers against this Deny-list and flag those domains that are not secure.
  Examples are github gists, static pages, package indexes that allow third parties to upload packages, pastebin like domains, mail servers where attachments are hosted (eg, googlecontent.com)

• Warn about similar sites not redirecting to one domain
  Dutch Government policy states that the least possible amount of hostnames should be running a website. This means that next to checking the similarity of ipv4/ipv6 on the same hostname, similarity on non-redirecting domains (eg, www. non www, or typo domains) should raise an issue as there should be just 1 active hostname, and the others should redirect to it.

Marked for investigation

• WhatWeb (https://github.com/urbanadventurer/WhatWeb)
• Qualys
• Nessus
• Acunetix
• Burp Suite
• https://github.com/thegreenwebfoundation/carbon.txt discovery
• GDPR privacy policy scanning (like https://github.com/mammuth/gdpr-scanner)
• Source code finder (https://shahrukhiqbal24.medium.com/your-source-code-might-be-giting-exposed-hacking-publicly-exposed-git-repositories-43c79650949b) (https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis-of-alexas-1m-28-07-2015/)
• Nuclei (https://github.com/projectdiscovery/nuclei-templates/tree/master)
• Manifest finder (https://github.com/avilum/smart-url-fuzzer/tree/master/words_lists)
• OpenVAS (Input: IP address; Output: Ports, Hostnames, CVE finding, KAT finding, Software) (We need to setup an OpenVAS server and connect to that server with the OpenVAS API.)
• See if domains without mailservers are properly clamped down against phishing (https://www.gov.uk/guidance/protect-domains-that-dont-send-email)
• Foutief geconfigureerde localhost-records leveren veiligheidsproblemen op (https://www.sidn.nl/nieuws-en-blogs/foutief-geconfigureerde-localhost-records-leveren-veiligheidsproblemen-op)

[underdarknl]

https://www.fingerbank.org/cloudapi/ could also be interesting

[stephanie0x00]

Some interesting tools for reconnaissance and exploitation on a network:

• snmpwalk | for getting snmp data from router/switch
• enum4linux | for getting smb info
• dirb | for hidden files on webserver, very dependant on the wordlists that are used.
• nbtscan | for getting netbios information
• nmap-scripts | for additional information, these are more intrusive and could break things.
• Responder | Responder an LLMNR, NBT-NS and MDNS poisoner. It will answer to specific NBT-NS (NetBIOS Name Service) queries based on their name suffix. By default, the tool will only answer to File Server Service request, which is for SMB. | https://github.com/lgandx/Responder
• Gitleaks | Gitleaks is a SAST tool for detecting and preventing hardcoded secrets like passwords, api keys, and tokens in git repos. | https://github.com/zricethezav/gitleaks
• S3Scanner | Scan for open S3 buckets and dump the contents | https://github.com/sa7mon/S3Scanner
• cloud_enum | Multi-cloud OSINT tool. Enumerate public resources in AWS, Azure, and Google Cloud. | https://github.com/initstring/cloud_enum
• Recon-AD | An AD recon tool based on ADSI and reflective DLL’s | https://github.com/outflanknl/Recon-AD
• BloodHound | BloodHound uses graph theory to reveal the hidden and often unintended relationships within an Active Directory or Azure environment. Attackers can use BloodHound to easily identify highly complex attack paths that would otherwise be impossible to quickly identify. | https://github.com/BloodHoundAD/BloodHound
• Rubeus | Rubeus is a C# toolset for raw Kerberos interaction and abuses. | https://github.com/GhostPack/Rubeus
• PingCastle | Ping Castle is a tool designed to assess quickly the Active Directory security level with a methodology based on risk assessment and a maturity framework. It does not aim at a perfect evaluation but rather as an efficiency compromise. | https://github.com/vletoux/pingcastle

Getting insights on whether or not your systems are up to date:

• Use the OVAL lists (XML lists) from distributions with vulnerabilities to determine which pieces of software are outdated on the server (Pakiti has this as a nice feature, though their parsing is sometimes broken.)

Overview of other nice redteaming tools - https://github.com/infosecn1nja/Red-Teaming-Toolkit

[underdarknl]

many more tools:
https://offsec.tools/