Finally my name got published on twitter! I reported 2 issues. A logical issue in tweet cards with Fraph and a old vulnerable server hosted by twitter. For reporting them my name got published 🙂
https://about.twitter.com/company/security
Found 2 major reflected XSS vulnerabilities in the login page and the signup page. The risk was very high because attackers can use a remote keylogger to capture keystrokes. This can be easily achieved by JavaScript. For reporting them my name got published in the Thanks section.
https://compilr.com/forum/security-thanks
This is how Microsoft describes it
When an application dynamically loads a dynamic-link library without specifying a fully qualified path name, Windows attempts to locate the DLL by searching a well-defined set of directories in a particular order, as described in Dynamic-Link Library Search Order. If an attacker gains control of one of the directories on the DLL search path, it can place a malicious copy of the DLL in that directory. This is sometimes called a DLL preloading attack or a binary planting attack. If the system does not find a legitimate copy of the DLL before it searches the compromised directory, it loads the malicious DLL. If the application is running with administrator privileges, the attacker may succeed in local privilege elevation.
Basically when an application tries to load a DLL without specifying a fully qualified path name Windows tries to load the DLL in a order of directories. If the application attempts to load a DLL by it’s name it should go in this order of directories (x86).
Last time for reporting a double query SQL injection I got acknowledged. This time for reporting a XSS issue bypassing filters I got acknowledged 🙂
http://www.oracle.com/ocom/groups/public/@otn/documents/webcontent/1932653.xml
Also mentioned in On-Line Presence Security Contributors in this document:
http://www.oracle.com/technetwork/topics/security/cpujan2014-1972949.html
Happy to disclose responsibly 😉
This issue is already patched by LinkedIn House Security and disclosed after a responsible disclosure.
It was an early morning and I was in the middle of a submission of an assignment at my college. I got an email from LinkedIn displaying the people who viewed my profile. This made me log into LinkedIn for a while to have a look what’s new. I saw a random profile who was a 3rd-degree relation. I really wanted to view the profile for some reason. At the very same time I was viewing Olivia Maree’s LinkedIn profile. Well, she is a manager at Bugcrowd and a good friend of mine. I always keep an eye on the URLs 😉 so after viewing both profiles and analyzing the web application carefully that morning I got some tricky ideas in my head. I will explain from the beginning so that you can understand the process well. Let’s start fuzzing 🙂
GET /profile/view?id=31594124&authType=name&authToken=HM8p&trk=prof-sb-browse_map-name HTTP/1.1
As she is already connected in my profile so after having a look at the GET request the “authType” parameter has a value of “name” and the token parameter is “authToken”, it has a value of “HM8p”. This is her profile.
This post is about my random vulnerabilities which I discovered some time ago on some sites in which I did not at least get a “Thanks” message.
Hello ????? 🙂
??????????flash xss
Anyway bug hunting is not all about getting thanks, at least I can be happy that they patched them secretly without notifying me. Good.