An issue was discovered in Dalmann OCPP.Core before 1.3.0 for OCPP (Open Charge Point Protocol) for electric vehicles. It permits multiple transactions with the same connectorId and idTag, contrary to the expected ConcurrentTx status. This could result in critical transaction management and billing errors. NOTE: the vendor's perspective is "Imagine you've got two cars in your family and want to charge both in parallel on the same account/token? Why should that be rejected?"

**Issue Description**:  
The current implementation of the OCPP server does not adhere to the specified behavior in the OCPP documentation regarding concurrent transactions. The documentation states that if an idTag is already involved in an active transaction, any attempt to initiate a new transaction with the same idTag should result in an AuthorizationStatus of ConcurrentTx. However, I've observed two issues:

1.  The server allows initiation of multiple transactions using the same idTag without the ConcurrentTx status.
2.  A StopTransaction message with a random transactionId can stop the current transaction.

**Steps to Reproduce**:

1.  Send a StartTransaction message using a specific idTag.
2.  While the transaction is active, send another StartTransaction message with the same idTag.
3.  Observe that the server does not return an AuthorizationStatus of ConcurrentTx.
4.  Send a StopTransaction message with a random transactionId.
5.  Note that the server stops the most recent transaction.

**Expected Behavior**:  
In compliance with the OCPP specification, the server should not allow a new transaction to start with an idTag that is already in use for an ongoing transaction. The server should issue an AuthorizationStatus of ConcurrentTx.

**Actual Behavior**:  
Multiple transactions are allowed for the same idTag without returning a ConcurrentTx status, and transactions can be stopped using random transactionIds.

**Potential Impact**:  
This could cause a critical error in transaction management and billing processes, affecting operational integrity.

**Suggested Solution**:

*   Update the server logic to return an AuthorizationStatus of ConcurrentTx for StartTransaction requests that involve an idTag in an ongoing transaction.
*   Validate transactionId in StopTransaction requests to ensure the correct transaction is being stopped.

Best regards,  
Gaetano Coppoletta

CVE-2023-49957: Multiple Transactions Allowed with Same connectorId and idTag · Issue #35 · dallmann-consulting/OCPP.Core

In Simple Food Website 1.0, a moderation can put the Cross Site Scripting Payload in any of the fields on http://127.0.0.1:1234/food/admin/all_users.php like Full Username, etc .This causes stored xss.

Submitted by ayoyemi on Thursday, April 1, 2021 - 00:22.

This is a simple **PHP Project** entitle **Simple Food Website**. This project was developed using **PHP** and **MySQL databases**. This system is a sort of **CMS (Content Management System)** in which the system or company management can provide their clients a simple website to know more about them. This system can be helpful to the IT/CS students or newbies to understand how to create a CMS Web App using PHP Language. The website containing an **About, Innovation**, and **Our Market Contents**. Since this project is a sort of **CMS** type of **web app**, the contents in the website can be managed or modified through the front-end in the admin panel or admin side/module of the project. This project also allows the admin to modify the site settings which are the site name, meta keywords, and meta description that can help your website improve its visibility for relevant searches in search Engines, in short, managing the website's basic information for **(SEO)**.

The system was developed using **PHP/PDO**, **MySQL Database**, **HTML**, **CSS**, **Javascript**, and **Bootstrap** for the design. The system has a pleasant user interface and user-friendly functionalities.

****Features****

**Website**

*   **Home Page**
*   **About Us Page/Content**
*   **Innovation Page/Content**
*   **Our Market Page/Content**
*   **Pleasant user interface**
*   **Contact Us Page**
*   **Footer containing system's other info and navigation**

**Admin Panel**

*   **Login Page**
*   **Manage Pages Contents**
*   **Manage System Information and Details**
*   **Manage User Accounts**

****How to Run****

**Requirements**

*   **Download** and **Install** any **local web server such as XAMPP/WAMP**.
*   **Download** the provided source code **zip** file. (_download button is located below._)

**Setup/Installation**

1.  **Extract** the downloaded source code **zip** file.
2.  **Open** your **XAMPP/WAMP's Control Panel** and start the **"Apache"** and **"MySQL"**.
3.  If you are using **XAMPP**, **copy** the extracted source code folder and paste it into the XAMPP's **"htdocs"** folder. And if you are using **WAMP**, paste it into the **"www"** folder.
4.  **Open** a new tab in your **browser** and browse the **PHPMyAdmin**. i.e. http://localhost/phpmyadmin
5.  **Create** a **new database** naming **"food"**.
6.  **Import** the provided **SQL** file in your newly created database. The file is known as **"INSTALL ME.sql"** and located inside the **"INSTALLER"** folder.
7.  **Open** a new tab in your **browser** and **browse** the **Web Application**. i.e. http://localhost/food for the website and http://localhost/food/admin for the admin side

****Admin Credentials****

Username: **admin**  
Password: **admin**

****DEMO****

That's it! I hope this **Simple Food Website** a **CMS Project** in **PHP** and **MySQL Database** will help you with what you are looking for and enhance your programming capabilities and knowledge.

**Thanks for downloading this software!**

Please don't forget to like us on www.facebook.com/hillsoftsnetwork

Check out my network www.lykup.com

You can contact me @  
WhatsApp number: +2348138652645  
Email: \[email protected\]  
Facebook account: www.facebook.com/faithyemi

_**GET CHEAPEST PROJECTS from $10**_

_MLM multilevel, Business directory, Crypto investment platform, school management system, hospital management system, music portal, POS, Blog/Magazine, Dating site, Charity donation platform, Exam system, Advertising website (like adtall.com), real estate listing, Car listing and a whole lot more._

*   5495 views

CVE-2022-30015: Simple Food Website (CMS) in PHP with Source Code

An issue was discovered in elfutils 0.175. A segmentation fault can occur in the function elf64_xlatetom in libelf/elf32_xlatetom.c, due to dwfl_segment_report_module not checking whether the dyn data read from a core file is truncated. A crafted input can cause a program crash, leading to denial-of-service, as demonstrated by eu-stack.

CVE-2019-7150: Mark Wielaard - [PATCH] libdwfl: Sanity check partial core file dyn data read.

An issue was discovered in the Linux kernel before 6.3.3. There is an out-of-bounds read in crc16 in lib/crc16.c when called from fs/ext4/super.c because ext4_group_desc_csum does not properly check an offset.

CVE-2023-34256

SQL injection vulnerability in Login.php in sourcecodester Online Learning System v2 by oretnom23, allows attackers to execute arbitrary SQL commands via the faculty_id parameter.

The eLearning V2(by: oretnom23) is vulnerable from remote SQL-Injection-Bypass-Authentication in 3 accounts of the system (admin, Faculty & Student) in app /elearning/classes/Login.php. remote SQL-Injection-Bypass-Authentication: https://portswigger.net/support/using-sql-injection-to-bypass-authentication. The parameter (username, faculty\_id, and student\_id) from the login form is not protected correctly and there is no security and escaping from malicious payloads. When the user will sending a malicious query or malicious payload to the MySQL server for those three accounts, he can bypass the login credentials and take control of these accounts.

	public function login(){
		extract($\_POST);

		$qry = $this\->conn\->query("SELECT \* from users where username = '$username' and password = md5('$password') ");
		if($qry\->num\_rows > 0){
			foreach($qry\->fetch\_array() as $k => $v){
				if(!is\_numeric($k) && $k != 'password'){
					$this\->settings\->set\_userdata($k,$v);
				}

			}
			$this\->settings\->set\_userdata('login\_type',1);
		$sy = $this\->conn\->query("SELECT \* FROM academic\_year where status = 1");
		foreach($sy\->fetch\_array() as $k =>$v){
			if(!is\_numeric($k)){
			$this\->settings\->set\_userdata('academic\_'.$k,$v);
			}
		}
		return json\_encode(array('status'\=>'success'));
		}else{
		return json\_encode(array('status'\=>'incorrect','last\_qry'\=>"SELECT \* from users where username = '$username' and password = md5('$password') "));
		}
	}
	public function flogin(){
		extract($\_POST);

		$qry = $this\->conn\->query("SELECT \* from faculty where  faculty\_id = '$faculty\_id' and \`password\` = '".md5($password)."' ");
		if($qry\->num\_rows > 0){
			foreach($qry\->fetch\_array() as $k => $v){
				if(!is\_numeric($k)){
					$this\->settings\->set\_userdata($k,$v);
				}

			}
			$this\->settings\->set\_userdata('login\_type',2);
			$sy = $this\->conn\->query("SELECT \* FROM academic\_year where status = 1");
		foreach($sy\->fetch\_array() as $k =>$v){
			if(!is\_numeric($k)){
			$this\->settings\->set\_userdata('academic\_'.$k,$v);
			}
		}
			return json\_encode(array('status'\=>'success'));
		}else{
		return json\_encode(array('status'\=>'incorrect'));
		}
	}
	public function slogin(){
		extract($\_POST);

		$qry = $this\->conn\->query("SELECT \* from students where  student\_id = '$student\_id' and \`password\` = '".md5($password)."' ");
		if($qry\->num\_rows > 0){
			foreach($qry\->fetch\_array() as $k => $v){
				if(!is\_numeric($k)){
					$this\->settings\->set\_userdata($k,$v);
				}

			}

CVE-2021-40596: CVE-nu11secur1ty/vendors/oretnom23/CVE-nu11-07 at main · nu11secur1ty/CVE-nu11secur1ty

A password link that didn't expire leads to the discovery of exposed personal information at a payments service.

_Editor's Note: Dark Reading was able to verify that the issue Cerrudo found was present as of June 24, when we created an account on Veem and confirmed that the personal information and partial bank account information was visible to anyone else. We also confirmed that even after deleting the account, most of the information remained accessible. We contacted Veem, and they provided this comment:_

_"Veem is committed to safeguarding customer information and funds and has in place a comprehensive security program that includes internal, external and regulatory assessments. We have responded to Mr. Cerrudo, and we continue to evaluate information provided to us by customers or third parties to ensure that any issues raised from those sources are included in our roadmap, as appropriate. As a matter of policy, we do not publicly comment on specifics of our program, other than to reinforce that we take our obligations seriously and devote substantial resources to deliver services in a reliable and secure manner."_

Over the years I have made hundreds of disclosures, and it still amazes me how some companies have such bad security practices and lack of security awareness.

This is a cybersecurity horror story from Veem, a well-funded fintech company that clearly fails badly at security and privacy. What's Veem? From its site: "Easily pay vendors and contractors domestically or internationally in over 100 countries, and get paid faster with one simple, yet powerful digital payments solution. With more payment flexibility and visibility, Veem gives small businesses the power to save time and control cash flow."

This all started when I was using the Veem service. It was pretty good, cheap, and easy to use. I liked it, and I recommended it. But I grew concerned about Veem's approach to security.

First I noticed that it displayed too much information about Veem users who weren't in my contact list. I just ignored it, though, and kept using it. Then one day, I was unable to log in and was forced to change my password via an email with a link to a form. I used the form to change my password, but I noticed something weird in this process, so I left the email marked to take a look at later.

After some days, I remembered about the email I saved and went to take a look. I clicked on the link and was presented again with a form to change my password. That was unusual — the link should have expired because I had already changed my password and because too much time had passed since the link was sent to me. Then, when examining the link, I realized that it was sent using the Mailchimp add-on Mandrill. That meant that this platform, a third-party email marketing and automation service, had access to change my password for many days, since it had the link saved in its systems. This is a really bad security practice that any minimum security check should have identified. I started to believe that Veem's systems hadn't been security tested.

After I found this password change security issue, I got a bit worried about Veem's security overall. It's a fintech solution that allows users to send and get payments, so it deals with a lot of money from its users, including myself. I decided to take a deeper look at some functionality that had looked strange to me but I had ignored earlier. I logged in, accessed this functionality, and, to my surprise, I found out that they were leaking all users' personal information, such as full name, address, city, state, country, email, phone number, date of birth, bank name, account type, and last four digits of bank account number. I couldn't believe what I was seeing — anyone could easily access any Veem user's personal information.  

I had to quickly report these issues — especially the last one, which was very critical. After I got help finding the correct contact email, on March 29, 2022, I emailed \[email protected\] detailing the problems. I was hoping for a quick answer, but no. On April 2, I emailed again, and after two days, still no answer. I was getting worried, since when you report such a critical issue, you should get an instant response. Every day that passes means someone gets another chance to exploit the issue.

Thinking about how to get a response, I got an interesting idea: What about using the security issue to find out information about Veem executives? So I got the Veem CEO's information — all of his information, but I really just needed the email address. I didn't think cold-calling him would be a good idea, and no, I'm not doxing him here. :)

**Initial Outreach**

On April 4 I sent an email to the CEO:

_Hi, I sent this (I forwarded previous email sent to \[email protected\]) almost a week ago and I haven't had any answer._

_There is at least a serious issue that leaks users personal information such as full name, email, date of birth, address, phone number, name of user's Bank, bank account last 4 numbers, etc._

_Please have your security team take a look and answer ASAP._

_Thanks._

_Cesar Cerrudo_

_Chief Research Officer_

_Strike_

Later that day, I got the following from \[email protected\]:

_Hello Cesar,_

_I want to thank you for proactively reaching out to us regarding the vulnerabilities you have found on our web application. Unfortunately, we do not have a bug bounty program or a financial reward at this time and there are no exceptions for one-time rewards either._

_In the meantime, we hope you continue leveraging the Veem network for your payments, and keep us informed on any future feedback you may have that will make it better and safer for all of our customers._

_Thank you for your time and understanding._

_Regards,_

_Cyber Security Team_

As you can see, they clearly didn't realize the criticality of the issue and thought that I was just looking for some reward. I had to explain (cc'ing the CEO just in case):

_Hi_

_I'm not looking for any reward, I just want you to take a look at the issues and fix them ASAP, once they are fixed let your users know about it. Also in the meantime provide feedback._

_For a financial institution it is very serious to leak customers information._

_btw, I'm CCing your CEO so he is aware of this, I got his personal information from Veem platform._

_Cesar Cerrudo_

_Chief Research Officer_

_Strike_

Then, after two days, they replied:

_Hello Cesar,_

_Thanks for following up._

_Apropos your findings, we are already tracking the two information leakage-related gaps in our risk register. These gaps exist to support otherwise desirable features — changing their design to eliminate this avenue for data exfiltration is nonetheless on our product roadmap. However, because this logic exists to support features which our customers expect to work, there is no quick or easy solution available. We recognize that this is a shortcoming and are planning appropriate redesign — prioritizing security and privacy, while also retaining essential parts of our product's user journey and customer experience._

_Regarding password reset links, you raise an entirely valid concern regarding link expiry. We have scheduled a fix for release in an upcoming sprint cycle._

_Once again, thank you for your proactive outreach and for helping us improve the security and privacy of our platform._

_Thanks,_

_Veem security team_

**Please Prioritize Security**

Cool, so they're fixing the password reset issue, but the personal information leakage is a feature they can't easily fix? How are they "prioritizing security and privacy"? Welcome to the 2020s, where fintechs prioritize functionality over security and privacy.

At this point it was clear to me that this was a very immature company in terms of cybersecurity and privacy, so I would have to deal with this in the best possible way and try harder to make them understand the issues, collaborate, and act quickly. I replied:

_Hi_

_Thanks for getting back with more details._

_I completely understand your challenges and point of view. What I would like is to have more visibility on this, so I would like to get some timeline information, like when are you planning to start working on the fixes and when they will be ready. As you may know, when vulnerabilities are reported is called responsible/coordinated disclosure, it requires collaboration from both sides and there is a limited waiting period for the issues to be fixed. We can't wait forever, holding back the vulnerability information we have that affects several thousand of your users, if you don't fix it in a short period of time we need to go public and let people know about the issues. If you are not familiar with responsible/coordinated disclosure, please take a look at it to understand these common practices on cyber security._

_I'm open for a quick call if you like so we can be on same page on this._

_Thanks._

_Cesar Cerrudo_

_Chief Research Officer_

_Strike_

Twelve days after the above email was sent, I still had no answer at all, so I asked for news. The following day they replied:

_Hello Cesar,_

_We are actively addressing these findings._

_Please be assured that we take this seriously and that customer security and privacy are at the top of our priorities._

_Thanks_

_Veem Security Team_

I wasn't happy with the answer. Such a delay and lack of communication doesn't reflect taking security and privacy seriously.

**Sketchy NDA**

Anyway, I waited for a few days to see if they would get back to me again with more updates — but, no, I had to email them again:

_Hi_

_I'm sorry but it seems you are not understanding how severe the issue is and how to manage it. Please let's have a call urgently and have some decision maker attend. I'm available most days from 1:30pm to 3pm ET_

_Thanks._

_Cesar Cerrudo_

_Chief Research Officer_

_Strike_

The same day, they replied:

_Hi Cesar,_

_We would like to send you our SOC2 report and set up a discussion but need to put an NDA in place to do so. Our CSO proposes that we connect at 2:15 pm EST on 5 May 2022 to address questions you may have. Here is the link for our eNDA http://bit.ly/VeemNDA_

_Veem Security team_

That was weird — why did they mention the SOC2 report? They wanted to show me they were in compliance? But were they? Also, that was on April 25, and they wanted to have a call in two weeks — more than a month since I sent the initial report — so clearly they didn't feel any urgency.

Plus they wanted me to sign a nondisclosure agreement (NDA). That was an indication of suspect cooperation, in my experience; when a company dealing with a disclosure brings an NDA, it's highly probable they want to keep everything hidden. I discussed this with my team at Strike and got back to Veem the next day:

_Hi_

_Ok, let's confirm the call for 2:15 pm EST on 5 May 2022. We don't usually sign NDA for this so I have to consult our lawyer and will get back to you ASAP._

_Cesar Cerrudo_

_Chief Research Officer_

_Strike_

After taking a look at the NDA with our lawyer, we identified that it said: _"evaluate the potential for, or the expansion of, a business relationship between the parties..."_

Why would they want us to sign an NDA that mentions business relationships?

**Avoiding the Problem**

On April 28 I replied:

_Hi_

_After evaluating the NDA, it says: "evaluate the potential for, or the expansion of, a business relationship between the parties" which doesn't make sense since we aren't talking about any business here._

_Also the NDA should explicitly exclude the vulnerability information I already shared with you and any previous communication before the NDA is signed. I see two options, we don't sign the NDA or the NDA is modified with my requests. Anyway, I think we can have the call next week without NDA, what's important is to talk about current situation and plans to fix it._

_Thanks._

_Cesar Cerrudo_

_Chief Research Officer_

_Strike_

Unsurprisingly I got no answer. Then on May 4, one day before the call was supposed to take place, I asked for updates:

_Hi, are we having the call tomorrow? please send an invite._

_Thanks._

_Cesar Cerrudo_

_Chief Research Officer_

_Strike_

and later the same day I got the following:

_Hello Cesar,_

_We are pleased to convey that your concerns have been addressed and our platform has been updated. As such, a meeting will not be required._

_Thank you for being our valued customer._

_Sincerely_

_Veem Cybersecurity Team_

Whoa, that was really a surprise. I didn't like the answer, but I thought, "OK, at least they fixed the issues." Of course I have to check, though, so I took a look at the issues again.

The password reset issue was partially fixed but only partially because they continue to use the same mailing/marketing service. And surprise, surprise, surprise — the main issue was not really fixed :(

For the personal information leakage, they only removed the date of birth and the last four digits of the bank account number. But the last four digits of the bank account number were still displayed in another field in same HTTP response, so they were still leaking everything except the date of birth. Really bad fixes.

**In Short: Terrible**

After many efforts and goodwill from our side, Veem proceeded in a very unprofessional and noncollaborative way, demonstrating lack of security and privacy awareness. We decided we needed to go ahead and publish this in order to let people know.

The personal information leakage can allow cybercriminals to easily perform several attacks, such as phishing, SIM swapping, etc., resulting in possible huge money losses.

Veem didn't notify its customers about the issues. Instead it tried to silently fix them — and failed.

Veem users should contact Veem directly and ask for an explanation. In the meantime, we recommend Veem users to set the "List my Information" or "List my business" (depending on account type) user account setting to "NO" — it is set to "YES" by default. Setting it to "NO" doesn't prevent the personal information leakage, but it does make it a bit difficult.

It's hard to understand how a company that has $100 million in investments doesn't allocate proper resources to cybersecurity and privacy, especially when dealing with users' money. Also, I wonder if they are violating any regulations.

Sadly, bad security and privacy practices are not exclusive to Veem. Many fintech companies choose feature release speed and great user experience over security and privacy. From one side, they want to get more customers and delight them, but from the other side, they don't properly protect their customers' data and privacy. Security and privacy should always be top priority, especially in fintech.

A Fintech Horror Story: How One Company Prioritizes Cybersecurity

We take a look at a large-scale Facebook phishing operation, reputedly generating millions in ill-gotten gains.
The post Facebook users targeted in massive phishing campaign appeared first on Malwarebytes Labs.

Facebook is once again the launchpad for a large-scale phishing campaign, according to researchers at PIXM. The campaign, which first shows signs of life back in September 2021, has generated millions of page views and ad referral revenue “estimated to be millions of USD at this scale of operation”.

**Credential harvesting on a grand scale**

Researchers claim the threat actors stole one million credentials in four months to help achieve the above potential level of revenue. Aspects of the phish campaign are fairly typical of what you can expect to see from a Facebook phish, and the tactics used to spread bogus links are not particularly original. What matters most of all is that it _works_. When basic phishing tactics pull in so many accounts and clicks, there’s no need to overcomplicate things.

One of the scam pages from 2021 attracted no fewer than 2.7 million users, with the number rising to about 8.5 million in 2022. This is a huge ramp-up of already significant numbers, and also perhaps a little surprising that the site avoided being taken down for abuse.

This is one phishing campaign that isn’t messing around.

**How the phish worked**

Unfortunately specifics are absent in a few areas, but it works as follows.

A Facebook user receives a notification in Messenger. This is, at its most basic, a rogue link. There’s no information around whether a message accompanies it, and if so, what it says. However, something as simple as the below messages are routinely used in Facebook scams:

*   Seen this?
*   Is this you in the photo?
*   Guess who died?
*   Check this out!

The link is shortened to help bypass any Facebook spam filters. The shortening services used are commonplace, popular and entirely legitimate. This makes it trickier for Facebook to figure out if the link is potentially good or bad.

The link takes potential victims to a variety of sites but a phishing page will be the primary destination. Once phished, the victim is sent elsewhere. It could be a promotion, a survey scam, or pretty much anything else that’s ad-centric. There’s also the mention of potential malvertising pages, on top of the threat of being phished. All these links have ad trackers and other ad-related forms of revenue generation buzzing away in the background.

**Current state of play**

According to PIXM, the campaign is still alive and kicking. Many of the sites involved have been taken down, and one website listed in the landing page code has been “seized” in relation to an investigation. What that investigation is, and who is doing it, isn’t clear.

What is clear, is that without dedicated resources and probable law enforcement involvement, something like this will never fully go away. It’s simply too easy to keep creating spam domains, signing up as an affiliate, and generating endless shortened URLs. The (potentially exaggerated) claims of $150 for every thousand visits from the US alone from the threat actor is all the incentive they need to keep doing it. As researchers note, this figure would result in a theoretical revenue of $59M from the end of 2021 to now.

**Tips to avoid Facebook phishing**

*   Be wary of messages which don’t follow the natural flow of a conversation. Messages sent at unusual hours or out of the blue with a link should be treated with caution.
*   If you’re presented with a “Login to view content” box, take a deep breath before going any further. If you’re already logged in, there should be no reason why you’d be asked to login again. Check the URL. Are you on Facebook.com, or an unrelated website?
*   If you’re able to, ask the sender about their message away from Facebook. Their Facebook account may have be compromised, but you probably don’t have to worry about sending them a text.
*   Enable 2-factor authentication (2FA). If you hand over your password to a phishing page, the phisher can’t do much with it while you’re protected with 2FA. Keep in mind that some phishing sites will also try to steal your 2FA codes.
*   Add login alerts to your Facebook account. If someone does compromise your login credentials and access your account, you’ll be notified by Facebook as soon as this happens.

Facebook users targeted in massive phishing campaign

By Waqas
Gustaffo Digital Service GmbH has been leaking personal and contact details of its customers since last month.
This is a post from HackRead.com Read the original post: Austrian ‘mobile concierge’ app Gustaffo leaking 100k customers’ data

Gustaffo was alerted about the data leak last week, but the company did not respond. Meanwhile, the misconfigured database is being updated with new and fresh customer data each day.

Austria, Vienna-based digital hospitality company Gustaffo has been caught in a data leak which saw over 100,000 customer records exposed. The cause of the data leak is its misconfigured database which is publically available without any password or security authentication.

What’s worse, the server is still live, and at the time of writing, new details of customers were being uploaded, including the following information:

1.  Full name
2.  Mobile numbers
3.  Email Addresses
4.  Booking Details
5.  Booking Links and information

Data that is being currently leaked and increasing

**So What is Gustaffo?**

According to this **press release**, Gustaffo was launched in 2016 and had 30 hotels in eight countries using the service. Its first customer was Austria’s largest hotel management company, Vienna House.

A look at Gustaffo’s **LinkedIn page** explains how the company functions and what services it offers. The company states it provides a “secure” and contactless Digital Guest Journey to Hotels and Hotel Groups.

“From the Check-In online to services during the stay including elevator and room access via the mobile app, and furthermore with Payment and Check-Out never having to go to the reception Via a white-labelled mobile app integrated with all major Property Management Systems your guests can directly access their assigned room via the mobile app instead of the usual key card,” says the About Us section of the company’s LinkedIn page.

Gustaffo was alerted to the security incident last week; however, there has been no response whatsoever, risking the personal details of unsuspecting customers at risk. This was revealed to Hackread.com by independent security researcher **Anurag Sen** working along with Hieu Minh, a Vietnamese researcher from **Chongluadao**.

It is worth noting that the researchers discovered the misconfigured cloud database on Shodan while searching for misconfigured cloud databases. For your information, **Shodan is an OSINT tool** and a specialized search engine used by cybersecurity researchers to locate vulnerable Internet of Things (IoT) devices, including servers and misconfigured databases on the internet.

Since Gustaffo has not responded to researchers nor have they secured the data, chances are that the company is completely unaware of the issue. Not only is it bad news for customers, but for Gustaffo itself, as the General Data Protection Regulation **(GDPR) is directly effective** in every country that is part of the European Union, including Austria.

In September 2021, the Austrian Data Protection Authority Österreichische Datenschutzbehörde **issued** a €9 million ($9.6 million) fine to the Austrian Post for violations of GDPR. This fine was among the largest fines ever imposed under the GDPR and served as an example of how seriously the law takes data privacy.

However, the fine was overturned by the Federal Administrative Court on December 2nd, 2020. Nevertheless, this fine was among the largest fines ever imposed under **the GDPR** and served as an example of how seriously the law takes data privacy.

While it’s unclear whether any malicious actors accessed the data or not, researchers are warning customers of Gustaffo to be on their guard against potential **phishing attempts** or identity theft scams.

**Misconfigured Databases – Threat to Privacy**

As we know, misconfigured or unsecured databases have become a major privacy threat to companies and unsuspecting users. **In 2020**, researchers identified over 10,000 unsecured databases that exposed more than 10 billion (10,463,315,645) records to public access without any security authentication.

**In 2021**, the number of exposed databases increased to 399,200. The top 10 countries with the most database leaks due to misconfiguration in 2021 included the following:

*   USA – 93,685 databases
*   China – 54,764 databases
*   Germany – 11,177 databases
*   France – 9,723 databases
*   India – 6,545 databases
*   Singapore – 5,882 databases
*   Hong Kong – 5,563 databases
*   Russia – 5,493 databases
*   Japan – 4,427 databases
*   Italy – 4,242 databases

1.  **579 GB of users website activity leaked in server messup**
2.  **Misconfigured AWS bucket leaked 350m email addresses**
3.  **Misconfigured baby monitors exposing video stream online**
4.  **Microsoft Power apps misconfiguration leaked 38m records**
5.  **Misconfigured backup leaked 50.5m GOMO Mobile user data**

****

I am a UK-based cybersecurity journalist with a passion for covering the latest happenings in cyber security and tech world. I am also into gaming, reading and investigative journalism

Austrian ‘mobile concierge’ app Gustaffo leaking 100k customers’ data

Improper Information in Cybersecurity Guidebook in Bosch Building Integration System (BIS) 5.0 may lead to wrong configuration which allows local users to access data via network

**Advisory Information**

*   **Advisory ID:** BOSCH-SA-988400-BT
*   **CVE Numbers and CVSS v3.1 Scores:**
    *   CVE-2023-29241
        *   Base Score: 8.1 (High)
*   **Published:** 28 Jun 2023
*   **Last Updated:** 28 Jun 2023

**Summary**

In a recent survey of BIS installations worldwide Bosch identified that for some installations the security settings may not meet our recommended security standards. For this reason, we have updated our "Cybersecurity Guidebook".

Section 4.5 of the Cybersecurity Guidebook describes how to configure access permissions for a shared folder of the BIS installation. In an older version of the Cybersecurity Guidebook, one of the recommended access permissions is wrongly stated as "Network" group instead of "Network Service" group. This information is updated in the new version of the documentation, because executing the earlier instructions may unintentionally grant access permission to potentially unauthorized users.

This is not a software bug, just an update of the documentation targeted at installers. This document is included in BIS installation folder since version BIS 5.0. Previous BIS version do not contain the document, but validating the security setting is generally advised.

**Affected Products**

*   Bosch BIS
    *   CVE-2023-29241
        *   Version(s): 5.0

**Solution and Mitigations****Software Updates**

For BIS 5.0 please apply patch BIS\_5\_0\_21100\_0\_Patch1.zip. Follow the instructions in the Readme of the patch. The patch will install an updated Cybersecurity Guidebook in folder "Platform" under the installation folder. Then follow the configuration steps in section 4.5 as described.

For any previous BIS version we recommend to double-check the security settings. Please follow the mitigation section below.

**Mitigation**

Installation of BIS automatically creates the "MgtS" shared folder, which is accessible to the "Everyone" group. It is recommended to restrict the access and provide the following users and groups with full access to the "\\MgtS" shared folder:

*   MgtS-Service user
    
*   IIS-USR user
    
*   System group
    
*   Network Service group
    
*   Administrators group
    
*   BIS Users group (add all users of BIS to the group)
    

Double-check that the "Network" group is not part of the access groups. Following that, proceed to remove the access for "Everyone" group.

**Vulnerability Details****CVE-2023-29241**

CVE description: Improper Information in Cybersecurity Guidebook in Bosch Building Integration System (BIS) 5.0 may lead to wrong configuration which allows local users to access data via network

*   Problem Type:
    *   CWE-1112 Incomplete Documentation of Program Execution
*   CVSS Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N
    *   Base Score: 8.1 (High)

**Remarks****Security Update Information**

With respect to Directive (EU) 2019/770 and Directive (EU) 2019/771 and their national transposition laws, please note:

It is your responsibility to download and/or install any security updates provided by us, for example to maintain product or data security. If you fail to install a security update provided to you within a reasonable period of time, we will not be liable for any product defect solely due to the absence of such security update.

Alternatively, we are entitled to directly download and/or install security updates regardless of your settings. In these cases, we will provide you with the relevant information, e.g. in this security advisory.

**CVSS Scoring**

Vulnerability classification has been performed using the CVSS v3.1 scoring system . The CVSS environmental score is specific to each customer’s environment and should be defined by the customer to attain a final scoring.

**Additional Resources**

*   \[1\] BIS Download Area: https://downloadstore.boschsecurity.com/?type=BIS
*   \[2\] CVE-2023-29241: https://nvd.nist.gov/vuln/detail/CVE-CVE-2023-29241

Please contact the Bosch PSIRT if you have feedback, comments, or additional information about this vulnerability at: psirt@bosch.com .

**Revision History**

*   28 Jun 2023: Initial Publication

**Appendix****Fixes for the Affected Products****Building Integration System (BIS)**

 

Affected BIS versions

Version or patch that fixes the vulnerability

5.0

Apply patch BIS\_5\_0\_21100\_0\_Patch1.zip,  
then follow section 4.5 in the Cybersecurity Guidebook

**Affected material****Building Integration System (BIS)**

Family Name

CTN

SAP#

Material Description

BIS-BGEN-B50

F.01U.415.267

BIS 5.0

Basic license

BIS-BGEN-CESB50

F.01U.415.269

BIS 5.0

Central enterprise server (bundle)

BIS-BGEN-BAS50

F.01U.415.268

BIS 5.0

Basic license without alarm documents

BIS-BGEN-LSSB50

F.01U.415.270

BIS 5.0

Local site server (bundle)

BIS-BGEN-CSSB50

F.01U.415.271

BIS 5.0

Central single server (bundle)

BIS-BASE-PLUS50

F.01U.415.272

BIS 5.0

Plus license (bundle)

CVE-2023-29241: Update in Cybersecurity Guidebook of BIS on Permission Settings for Network Share

Forgejo before 1.20.5-1 allows remote attackers to test for the existence of private user accounts by appending .rss (or another extension) to a URL.

Forgejo v1.20.5-1 was released 25 November 2023.

This release contains _critical security fixes_ related to permissions enforcement of API endpoints.

This release also contains bug fixes, as detailed in the release notes.

**Recommended Action**

We _strongly recommend_ that all Forgejo installations are upgraded to the latest version as soon as possible.

**API and web endpoint vulnerable to manually crafted identifiers**

Some API endpoints, such as adding a reaction to a comment, rely on an identifier unique to an object (a comment in this example). There are similar cases for web endpoints which are used by the Forgejo web interface.

The permissions required for the user performing the action on the repository are properly enforced. But a check was missing to ensure that the object (a comment in the example) also belongs to the repository the permissions are checked against. Without this check it is possible both to perform destructive actions and to access information in repositories unrelated to the request, including private ones.

API and web endpoints have been analysed, and those that were missing such a verification can be exploited by a malicious actor to:

*   delete releases and tags
*   delete and modify issues or pull requests comments
*   reveal the content of issues or pull requests comments from private repositories
*   perform other non-destructive actions such as creating issues, moving pinned issues, or obtaining deploy public keys

The vulnerable endpoints were fixed and tests written to verify the fix is effective.

**docker login and 2FA**

When using docker login to authenticate against a Forgejo instance using basic authentication, there needs to be an additional verification if 2FA is activated for the user. That verification was missing for the API endpoint used by docker login, thus bypassing 2FA.

**Responsible disclosure to Gitea**

On 25 October 2023 the Forgejo security team identified that multiple API and web endpoints were not protected against manually crafted identifiers, and the Gitea security team was notified. A 30-day embargo was requested, after which a patch to the v1.20 point release could be published. Further research from both Gitea and Forgejo teams in the following days revealed more vulnerabilities. Initial fixes and tests verifying they are effective were exchanged, but after their last email on 31 October 2023 the Gitea security team stopped responding. Given the severity of the vulnerability, the Forgejo security team asked again for feedback on 16 November 2023, but did not get any reply. Having exhausted all options for cooperation, the Forgejo security team completed the security fix on its own. The resulting fix which is published in this release was sent to the Gitea security team encrypted in its final version on 24 November 2023. At the time of publication, there was still no response from the Gitea security team.

**Responsible disclosure to Gogs**

The Gogs developer was notified of the vulnerability on 25 October 2023. There is no encrypted channel and only a terse but unambiguous message was sent. There has been no response.

**Forgejo will give advance warning of security releases**

Similar to what is done when a Go release contains a security fix, Forgejo will now publish advance warning of security releases. They will not reveal the details of the vulnerability but will allow Forgejo admins to plan ahead and better secure their instance. Anyone can watch to the dedicated tracker or subscribe to the RSS feed.

**Gogs and Gitea upgrades to Forgejo**

Gitea admins are reminded that Forgejo is a 100% compatible drop-in replacement for Gitea. It is enough to replace the Gitea binary or the container image with Forgejo and restart. No configuration modification is necessary. They are encouraged to choose that option to get this security fix as soon as possible.

In the absence of a security fix for Gogs, it is also possible to try and upgrade Gogs to Forgejo. Note however that such an upgrade will require manual intervention and configuration changes because the upgrade path has not been tested.

**Contribute to Forgejo**

If you have any feedback or suggestions for Forgejo, we’d love to hear from you! Open an issue on our issue tracker for feature requests or bug reports. You can also find us on the Fediverse, or drop by our Matrix space (main chat room) to say hi!

Search

lenovo warranty check/lookup | check warranty status | lenovo support us