Leaderboard

Daca prostii nostri o tin in ritmul asta, pana in iulie ne curatam dracu cu totii.

We found 6 critical PayPal vulnerabilities – and PayPal punished us for it by Bernard Meyer February 17, 2020 in Security 6 19 SHARES Share on FacebookShare on Twitter In the news, it seems that PayPal gives a lot of money to ethical hackers that find bugs in their tools and services. In March 2018, PayPal announced that they’re increasing their maximum bug bounty payment to $30,000 – a pretty nice sum for hackers. On the other hand, ever since PayPal moved its bug bounty program to HackerOne, its entire system for supporting bug bounty hunters who identify and report bugs has become more opaque, mired in illogical delays, vague responses, and suspicious behavior. When our analysts discovered six vulnerabilities in PayPal – ranging from dangerous exploits that can allow anyone to bypass their two-factor authentication (2FA), to being able to send malicious code through their SmartChat system – we were met with non-stop delays, unresponsive staff, and lack of appreciation. Below, we go over each vulnerability in detail and why we believe they’re so dangerous. When we pushed the HackerOne staff for clarification on these issues, they removed points from our Reputation scores, relegating our profiles to a suspicious, spammy level. This happened even when the issue was eventually patched, although we received no bounty, credit, or even a thanks. Instead, we got our Reputation scores (which start out at 100) negatively impacted, leaving us worse off than if we’d reported nothing at all. It’s unclear where the majority of the problem lies. Before going through HackerOne, we attempted to communicate directly with PayPal, but we received only copy-paste Customer Support responses and humdrum, say-nothing responses from human representatives. There also seems to be a larger issue of HackerOne’s triage system, in which they employ Security Analysts to check the submitted issues before passing them onto PayPal. The only problem – these Security Analysts are hackers themselves, and they have clear motivation for delaying an issue in order to collect the bounty themselves. Since there is a lot more money to be made from using or selling these exploits on the black market, we believe the PayPal/HackerOne system is flawed and will lead to fewer ethical hackers providing the necessary help in finding and patching PayPal’s tools. Vulnerabilities we discovered In our analysis of PayPal’s mobile apps and website UI, we were able to uncover a series of significant issues. We’ll explain these vulnerabilities from the most severe to least severe, as well as how each vulnerability can lead to serious issues for the end user. #1 Bypassing PayPal’s two-factor authentication (2FA) Using the current version of PayPal for Android (v. 7.16.1), the CyberNews research team was able to bypass PayPal’s phone or email verification, which for ease of terminology we can call two-factor authentication (2FA). Their 2FA, which is called “Authflow” on PayPal, is normally triggered when a user logs into their account from a new device, location or IP address. How we did it In order to bypass PayPal’s 2FA, our researcher used the PayPal mobile app and a MITM proxy, like Charles proxy. Then, through a series of steps, the researcher was able to get an elevated token to enter the account. (Since the vulnerability hasn’t been patched yet, we can’t go into detail of how it was done.) The process is very simple, and only takes seconds or minutes. This means that attackers can gain easy access to accounts, rendering PayPal’s lauded security system useless. What’s the worst case scenario here? Stolen PayPal credentials can go for just $1.50 on the black market. Essentially, it’s exactly because it’s so difficult to get into people’s PayPal accounts with stolen credentials that these stolen credentials are so cheap. PayPal’s authflow is set up to detect and block suspicious login attempts, usually related to a new device or IP, besides other suspicious actions. But with our 2FA bypass, that security measure is null and void. Hackers can buy stolen credentials in bulk, log in with those credentials, bypass 2FA in minutes, and have complete access to those accounts. With many known and unknown stolen credentials on the market, this is potentially a huge loss for many PayPal customers. PayPal’s response We’ll assume that HackerOne’s response is representative of PayPal’s response. For this issue, PayPal decided that, since the user’s account must already be compromised for this attack to work, “there does not appear to be any security implications as a direct result of this behavior.” Based on that, they closed the issue as Not Applicable, costing us 5 reputation points in the process. #2 Phone verification without OTP Our analysts discovered that it’s pretty easy to confirm a new phone without an OTP (One-Time Pin). PayPal recently introduced a new system where it checks whether a phone number is registered under the same name as the account holder. If not, it rejects the phone number. How we did it When a user registers a new phone number, an onboard call is made to api-m.paypal.com, which sends the status of the phone confirmation. We can easily change this call, and PayPal will then register the phone as confirmed. The call can be repeated on already registered accounts to verify the phone. What’s the worst case scenario here? Scammers can find lots of uses for this vulnerability, but the major implication is unmissable. By bypassing this phone verification, it will make it much easier for scammers to create fraudulent accounts, especially since there’s no need to receive an SMS verification code. PayPal’s response Initially, the PayPal team via HackerOne took this issue more seriously. However, after a few exchanges, they stopped responding to our queries, and recently PayPal itself (not the HackerOne staff) locked this report, meaning that we aren’t able to comment any longer. #3 Sending money security bypass PayPal has set up certain security measures in order to help avoid fraud and other malicious actions on the tool. One of these is a security measure that’s triggered when one of the following conditions, or a combination of these, is met: You’re using a new device You’re trying to send payments from a different location or IP address There’s a change in your usual sending pattern The owning account is not “aged” well (meaning that it’s pretty new) When these conditions are met, PayPal may throw up a few types of errors to the users, including: “You’ll need to link a new payment method to send the money” “Your payment was denied, please try again later” How we did it Our analysts found that PayPal’s sending money security block is vulnerable to brute force attacks. What’s the worst case scenario here? This is similar in impact to Vulnerability #1 mentioned above. An attacker with access to stolen PayPal credentials can access these accounts after easily bypassing PayPal’s security measure. PayPal’s response When we submitted this to HackerOne, they responded that this is an “out-of-scope” issue since it requires stolen PayPal accounts. As such, they closed the issue as Not Applicable, costing us 5 reputation points in the process. #4 Full name change By default, PayPal allows users to only change 1-2 letters of their name once (usually because of typos). After that, the option to update your name disappears. However, using the current version of PayPal.com, the CyberNews research team was able to change a test account’s name from “Tester IAmTester” to “christin christina”. How we did it We discovered that if we capture the requests and repeat it every time by changing 1-2 letters at a time, we are able to fully change account names to something completely different, without any verification. We also discovered that we can use any unicode symbols, including emojis, in the name field. What’s the worst case scenario here? An attacker, armed with stolen PayPal credentials, can change the account holder’s name. Once they’ve completely taken over an account, the real account holder wouldn’t be able to claim that account, since the name has been changed and their official documents would be of no assistance. PayPal’s response This issue was deemed a Duplicate by PayPal, since it had been apparently discovered by another researcher. #5 The self-help SmartChat stored XSS vulnerability PayPal’s self-help chat, which it calls SmartChat, lets users find answers to the most common questions. Our research discovered that this SmartChat integration is missing crucial form validation that checks the text that a person writes. How we did it Because the validation is done at the front end, we were able to use a man in the middle (MITM) proxy to capture the traffic that was going to Paypal servers and attach our malicious payload. What’s the worst case scenario here? Anyone can write malicious code into the chatbox and PayPal’s system would execute it. Using the right payload, a scammer can capture customer support agent session cookies and access their account. With that, the scammer can log into their account, pretend to be a customer support agent, and get sensitive information from PayPal users. PayPal’s response The same day that we informed PayPal of this issue, they replied that since it isn’t “exploitable externally,” it is a non-issue. However, while we planned to send them a full POC (proof of concept), PayPal seems to have removed the file on which the exploit was based. This indicates that they were not honest with us and patched the problem quietly themselves, providing us with no credit, thanks, or bounty. Instead, they closed this as Not Applicable, costing us another 5 points in the process. #6 Security questions persistent XSS This vulnerability is similar to the one above (#5), since PayPal does not sanitize its Security Questions input. How we did it Because PayPal’s Security Questions input box is not validated properly, we were able to use the MITM method described above. Here is a screenshot that shows our test code being injected to the account after refresh, resulting in a massive clickable link: What’s the worst case scenario here? Attackers can inject scripts to other people’s accounts to grab sensitive data. By using Vulnerability #1 and logging in to a user’s account, a scammer can inject code that can later run on any computer once a victim logs into their account. This includes: Showing a fake pop up that could say “Download the new PayPal app” which could actually be malware. Changing the text user is adding. For example, the scammer can alter the email where the money is being sent. Keylogging credit card information when the user inputs it. There are many more ways to use this vulnerability and, like all of these exploits, it’s only limited by the scammer’s imagination. PayPal’s response The same day we reported this issue, PayPal responded that it had already been reported. Also on the same day, the vulnerability seems to have been patched on PayPal’s side. They deemed this issue a Duplicate, and we lost another 5 points. PayPal’s reputation for dishonesty PayPal has been on the receiving end of criticism for not honoring its own bug bounty program. Most ethical hackers will remember the 2013 case of Robert Kugler, the 17-year old German student who was shafted out of a huge bounty after he discovered a critical bug on PayPal’s site. Kugler notified PayPal of the vulnerability on May 19, but apparently PayPal told him that because he was under 18, he was ineligible for the Bug Bounty Program. But according to PayPal, the bug had already been discovered by someone else, but they also admitted that the young hacker was just too young. Another researcher earlier discovered that attempting to communicate serious vulnerabilities in PayPal’s software led to long delays. At the end, and frustrated, the researcher promises to never waste his time with PayPal again. There’s also the case of another teenager, Joshua Rogers, also 17 at the time, who said that he was able to easily bypass PayPal’s 2FA. He went on to state, however, that PayPal didn’t respond after multiple attempts at communicating the issue with them. PayPal acknowledged and downplayed the vulnerability, later patching it, without offering any thanks to Rogers. The big problem with HackerOne HackerOne is often hailed as a godsend for ethical hackers, allowing companies to get novel ways to patch up their tools, and allowing hackers to get paid for finding those vulnerabilities. It’s certainly the most popular, especially since big names like PayPal work exclusively with the platform. There have been issues with HackerOne’s response, including the huge scandal involving Valve, when a researcher was banned from HackerOne after trying to report a Steam zero-day. However, its Triage system, which is often seen as an innovation, actually has a serious problem. The way that HackerOne’s triage system works is simple: instead of bothering the vendor (HackerOne’s customer) with each reported vulnerability, they’ve set up a system where HackerOne Security Analysts will quickly check and categorize each reported issue and escalate or close the issues as needed. This is similar to the triage system in hospitals. These Security Analysts are able to identify the problem, try to replicate it, and communicate with the vendor to work on a fix. However, there’s one big flaw here: these Security Analysts are also active Bug Bounty Hackers. Essentially, these Security Analysts get first dibs on reported vulnerabilities. They have full discretion on the type of severity of the issue, and they have the power to escalate, delay or close the issue. That presents a huge opportunity for them, if they act in bad faith. Other criticisms have pointed out that Security Analysts can first delay the reported vulnerability, report it themselves on a different bug bounty platform, collect the bounty (without disclosing it of course), and then closing the reported issue as Not Applicable, or perhaps Duplicate. As such, the system is ripe for abuse, especially since Security Analysts on HackerOne use generic usernames, meaning that there’s no real way of knowing what they are doing on other bug bounty platforms. What it all means All in all, the exact “Who is to blame” question is left unanswered at this point, because it is overshadowed by another bigger question: why are these services so irresponsible? Let’s point out a simple combination of vulnerabilities that any malicious actor can use: Buy PayPal accounts on the black market for pennies on the dollar. (On this .onion website, you can buy a $5,000 PayPal account for just $150, giving you a 3,333% ROI.) Use Vulnerability #1 to bypass the two-factor authentication easily. Use Vulnerability #3 to bypass the sending money security and easily send money from the linked bank accounts and cards. Alternatively, the scammer can use Vulnerability #1 to bypass 2FA and then use Vulnerability #4 to change the account holder’s name. That way, the scammer can lock the original owner out of their own account. While these are just two simple ways to use our discovered vulnerabilities, scammers – who have much more motivation and creativity for maliciousness (as well as a penchant for scalable attacks) – will most likely have many more ways to use these exploits. And yet, to PayPal and HackerOne, these are non-issues. Even worse, it seems that you’ll just get punished for reporting it. Share19TweetShare Bernard Meyer Bernard Meyer is a security researcher at CyberNews. He has a strong passion for security in popular software, maximizing privacy online, and keeping an eye on governments and corporations. You can usually find him on Twitter arguing with someone about something moderately important. Sursa: https://cybernews.com/security/we-found-6-critical-paypal-vulnerabilities-and-paypal-punished-us/

Dau la schimb cutie 10,000 masti medicale pe garsoniera in Ferentari 😃

Survival of the fittest 💪 https://www.paginademedia.ro/2020/02/emag-masti-specula Imi place cand se smardoieste prostia cu isteria. La mai mult! #ThanosCleanup

Exploiting SSRFs And how I got your company secrets. Vickie Li Jun 3, 2019 · 7 min read Now that we got the basics of SSRFs down, let’s learn to exploit them! If you aren’t familiar with SSRFs or need a refresher, here’s the first part of the series about SSRF: Intro to SSRF And how your firewall failed you. medium.com So what exactly can a hacker do with an SSRF vulnerability? Well, that usually depends on the internal services found on the network. Today, we’ll talk about a few common ways to exploit the vulnerability once you’ve found one. Let’s dive right in! I found an SSRF! What now? SSRF vulnerabilities can be used to: Scan the network for hosts, Port scan internal machines and fingerprint internal services, collect instance metadata, bypass access controls, leak confidential data, and even execute code on reachable machines. Network Scanning First, SSRFs can be used to scan the network for other reachable machines. This is done by feeding the vulnerable endpoint with a range of internal IP addresses and see if the server responds differently for each address. Using the differences in server behavior, we can gather info about the network structure. For example, when you request: https://public.example.com/upload_profile_from_url.php?url=10.0.0.1 The server responds with: Error: cannot upload image: http-server-header: Apache/2.2.8 (Ubuntu) DAV/2 And when you request: https://public.example.com/upload_profile_from_url.php?url=10.0.0.2 The server responds with: Error: cannot upload image: Connection Failed We can deduce that 10.0.0.1 is the address of a valid host on the network, while 10.0.0.2 is not. Port Scanning and Service Fingerprinting SSRF can also be used to port scan network machines and reveal services running on these machines. Open ports provide a pretty good indicator of services running on the machine, as services have default ports that they run on, and port scan results point you to ports to inspect manually. This will help you plan further attacks tailored to the services found. Provide the vulnerable endpoint with different ports of identified internal machines and determine if there is a difference in server behavior between ports. It’s the same process as scanning for hosts, except this time, you’re switching out port numbers. (Port numbers range from 0 to 65535.) For example, when you send a request to port 80 on an internal server (eg. 10.0.0.1:80), the server responds with: Error: cannot upload image: http-server-header: Apache/2.2.8 (Ubuntu) DAV/2 And when you send a request to port 11 on the same server (eg. 10.0.0.1:11), the server responds with this: Error: cannot upload image: Connection Failed We can deduce that port 80 is open on the server, while port 11 is not. Pulling Instance Metadata Amazon Elastic Compute Cloud (Amazon EC2) is a service that allows businesses to run applications in the public cloud. It has a service called “Instance Metadata”. This enables EC2 instances to access an API that returns data about the instance itself (on the address 169.254.169.254). An instance metadata API service similar to that of EC2’s is also available on Google Cloud. These API endpoints are accessible by default unless they are specifically blocked or disabled by network admins. The information these services reveal is often extremely sensitive and could potentially allow attackers to escalate SSRFs to serious info leaks and RCE (Remote Code Execution). Querying AWS EC2 Metadata If a company is hosting its infrastructure on Amazon EC2, you can query various instance metadata about the host using the endpoints at http://169.254.169.254/latest/meta-data/ These endpoints reveal information such as API keys, AWS S3 tokens, and passwords. Here is the complete documentation from Amazon. Here are a few especially useful ones to go after first: http://169.254.169.254/latest/meta-data/ returns the list of available metadata that you can query. http://169.254.169.254/latest/meta-data/local-hostname/ returns the internal hostname used by the host. http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME returns the security credentials of that role. http://169.254.169.254/latest/dynamic/instance-identity/document reveals the private IP address of the current instance. http://169.254.169.254/latest/user-data/ returns user data on the current instance. Querying Google Cloud Metadata If the company uses Google Cloud, you could try to query Google Instance Metadata API instead. Google implements some additional security measures for their API endpoints — Querying Google Cloud Metadata APIv1 requires special headers: “Metadata-Flavor: Google” or “X-Google-Metadata-Request: True” But this protection can be easily bypassed because most endpoints accessible through APIv1 can be accessed via the API v1beta1 endpoints instead. And API v1beta1 does not have the same header requirements. Here’s the full documentation of the API from Google. Here are a few critical pieces of information to go after first: http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token returns the access token of the default account on the instance. http://metadata.google.internal/computeMetadata/v1beta1/project/attributes/ssh-key returns public SSH keys that can connect to other instances in this project. Amazon and Google aren’t the only web services that provide metadata APIs. However, these two have quite a large market share so chances are the company that you are testing is on one of these platforms. If not, here’s a list of other cloud metadata services and things you can try. Using What You’ve Got Now using what you’ve found by scanning the network, identifying services and pulling instance metadata, you can try to pull these off: Bypass access controls: Some internal services might only control access based on IP addresses or internal headers. It might be possible to bypass access controls to sensitive functionalities just by sending the request from a trusted machine. Leak confidential information: If you’re able to find credentials using the SSRF, you can then use those credentials to access confidential information stored on the network. For example, if you were able to find AWS S3 keys, go through the company’s private S3 buckets and see if you have access to those. Execute code: You can use the info you gathered to turn SSRF into RCE. For example, if you found admin credentials that give you write privileges, try uploading a shell. Or if you found an unsecured admin panel, are there any features that allow the execution of scripts? Better yet, maybe you can log in as root? Blind SSRFs Blind SSRFs are SSRFs where you don’t get a response or error message back from the target server. The exploitation of blind SSRFs is often limited to network mapping, port scanning, and service discovery. Since you can’t extract information directly from the target server, exploitation of blind SSRFs relies heavily on deduction. Utilizing HTTP status codes and server response times, we can achieve similar results as regular SSRF. Network and Port Scanning using HTTP status codes For example, when you feed the following request results in an HTTP status code of 200 (Status code for “OK”). https://public.example.com/webhook?url=10.0.0.1 While the following request results in an HTTP status code of 500 (Status code for “Internal Server Error”). https://public.example.com/webhook?url=10.0.0.2 We can deduce that 10.0.0.1 is the address of a valid host on the network, while 10.0.0.2 is not. Port scanning with blind SSRF works the same way. If the server returns a 200 status code for some ports and 500 for others, the ports that yield a 200 status code might be the open ports on the machine. Network and Port Scanning using Server response times If the server is not returning any useful information in the form of status codes, all is not lost. You might still be able to figure out the network structure by examining how long the server is taking to respond to your request. If the server is taking much longer to respond for some addresses, it might indicate that those network addresses are unrouted, or are hidden behind a firewall. On the other hand, unusually short response times may also indicate unrouted address, if the request is dropped by the router immediately. If the server is taking much longer to respond for some ports, it might indicate that those ports are closed. Check out this graph published by @jobert on the Hackerone Blog. It provides a good overview of how a network would behave. When performing any kind of network or port scanning, it is important to remember that vulnerable machines behave differently, and the key is to look for differences in behavior instead of the specific signatures described above. Leaking Info to External Servers The target machine might also leak sensitive information in outbound requests, such as internal IPs, headers, and version numbers of the software used. Try to provide the vulnerable endpoint with the address of a server you own and see what you can extract from the incoming request! Conclusion SSRF is a vulnerability that is full of potential. Here’s a link to the SSRF Bible. It discusses many more methods of exploiting SSRFs. In future posts, we will discuss real-life examples of how master hackers have utilized SSRF to own company networks! Happy Hacking! Next time, we’ll talk about how to bypass common SSRF protection mechanisms used by companies. Hi there, thanks for reading. Please help make this a better resource for new hackers: feel free to point out any mistakes or let me know if there is anything I should add! Disclaimer: Trying this on systems where you don’t have permission to test is illegal. If you’ve found a vulnerability, please disclose it responsibly to the vendor. Help make our Internet a safer place Thanks to Jennifer Li. Web Security AWS Penetration Testing Bug Bounty Hacking Written by Vickie Li Professional investigator of nerdy stuff. Hacks and secures. Creates god awful infographics. https://twitter.com/vickieli7 Sursa: https://medium.com/@vickieli/exploiting-ssrfs-b3a29dd7437

[video=dailymotion]https://youtu.be/qeQZXYKSFeQhttp://[/video] Virustotal: https://www.virustotal.com/gui/file/829e9c7d17ecc5d20164dd966a1b240ecab45b45e184be90850da270538a0448/detection Download: // Removed Password RAR: 1 http://blackhat.forumotion.asia https://blackhat8.blogspot.com