Search the Community

GitHub's new service will help developers clean up vulnerable project dependencies. Devlopers can view the security alerts in the repository's dependency graph, which can be accessed from 'Insights'. Image: GitHub Development platform GitHub has launched a new service that searches project dependencies in JavaScript and Ruby for known vulnerabilities and then alerts project owners if it finds any. The new service aims to help developers update project dependencies as soon as GitHub becomes aware of a newly announced vulnerability. GitHub will identify all public repositories that use the affected version of the dependency. Projects under private repositories will need to opt into the vulnerability-detection service. The alerts should have a big impact on security, given that GitHub now hosts nearly 70 million repositories, with projects that rely on dependent software packages or software libraries that frequently do not get updated when new flaws are disclosed. The alerts form part of GitHub's so-called 'dependency graph', which helps developers monitor projects that their code depends on, and lists a project's various Ruby and JavaScript dependencies. Developers can view the security alerts in the repository's dependency graph, which can be accessed from 'Insights'. The alerts are only sent to project owners and others with admin access to repositories. The company promises never to publicly disclose vulnerabilities for a specific repository. Users can choose to receive the alerts by email, web notifications or the GitHub interface. GitHub's is also using machine learning to suggest fixes from the GitHub community. The alerts are based on public vulnerabilities in Ruby gems and NPM, the package manager for Node.js, on MITRE's Common Vulnerabilities and Exposures (CVE) List. GitHub will add Python to its vulnerability alert service in 2018. Python, Ruby, and JavaScript are among the top five languages on GitHub, along with Java and PHP. It appears the alerts will be limited to flaws with CVE IDs initially. However, as GitHub notes many publicly disclosed flaws don't have CVE IDs. It suggests future improvements will help it identify more vulnerabilities as it collects more data about them. Source: zdnet.com

GitHub has revoked an unknown number of cryptographic keys used to access accounts after a developer found they contained a catastrophic weakness that came to light some seven years ago. The keys, which allow authorized users to log into public repository accounts belonging to the likes of Spotify, Yandex, and UK government developers, were generated using a buggy pseudo random number generator originally contained in the Debian distribution of Linux. During a 20-month span from 2006 to 2008, the pool of numbers available was so small that it made cracking the secret keys trivial. Almost seven years after Debian maintainers patched the bug and implored users to revoke old keys and regenerate new ones, London-based developer Ben Cartwright-Cox said he discovered the weakness still resided in a statistically significant number of keys used to gain secure shell (SSH) access to GitHub accounts. "If you have just/as of late gotten an email about your keys being revoked, this is because of me, and if you have, you should really go through and make sure that no one has done anything terrible to you, since you have opened yourself to people doing very mean things to you for what is most likely a very long time," Cartwright-Cox wrote in a blog post published Monday. "It would be safe to assume that due to the low barrier of entry for this, that the users that have bad keys in their accounts should be assumed to be compromised and anything that allowed that key entry may have been hit by an attacker." Cartwright-Cox told Ars that he found about 94 keys on GitHub that contained the Debian-derived weakness. He said that after he reported his finding to GitHub officials in March he learned the actual number of site users was much higher. GitHub revoked the keys early last month, he said. GitHub officials didn't respond to a request to comment. Separately, the UK developer said he found nine GitHub SSH keys that contained woefully insufficient numbers of bits. Two of them had only 256 bits, making it possible for him to factor them and clone the private key in less than an hour. The remaining seven had only have 512 bits. During the time the Debian bug was active, the pool of bits available when generating OpenSSH keys was so limited that there were only 32,767 possible outcomes for a given architecture, key size, and key type. Cartwright-Cox said attackers could have used the same methods he employed to find weak keys and then used several techniques to gain unauthorized access to the accounts the keys protected. The task would have been aided by obtaining the list of insecure Debian SSH keys off one or more public sites, such as this one. In an e-mail, he elaborated: If I wanted to be more noisy I could have just done what I said [in the blog post] and looped though the keys, that may or may not have set off alarms at Github itself (I'd give it a 25% chance that it would). So the breakdown of how this could have been done is the following: Grab the bad key list. It contains the public and private parts of all the SSH keys that would have been made if the user had a version of OpenSSH that had Debian RNG bug, then get each private key on the list, and try to log into GitHub's ssh with them. Depending on what key you succeed with it will tell you what user name it matches up with, in the example I provided since my key is loaded it tells me "Hi benjojo! You've successfully authenticated, but GitHub does not provide shell access." but if I was to try with a weak key that matched up with another user it would say "Hi {user}! You've successfully authenticated, but GitHub does not provide shell access." and then I know what user I can compromise with that. Technically, attackers don't even need the private key to see if a site accepts authentication from a user, HD Moore, chief research officer at Rapid7 and co-founder of the Metasploit hacking framework, told Ars. Just the public key and this Metasploit module will do. "This trick can also be used to see what internet-facing servers allow logins from what public keys, even if the private key is not available, which is a neat reconnaissance/opsec technique," Moore said. The randomness bug was introduced in late 2006, when Debian maintainers removed two lines of code in the OpenSSL code base in an attempt to fix warnings received by some users. In the process, the maintainers wiped out almost all of the entropy that OpenSSL relied on for its randomness engine. The epic mistake, which eventually migrated to the Ubuntu distribution of Linux as well, wasn't diagnosed for 20 months, and by that time an untold number of cryptographic keys had been generated. The bug was unusual in that installing a patch was only the beginning of the healing process. To fully recover, users had to revoke any keys made during that 20-month period and generate new ones using the updated OS. The discovery that GitHub users continued to rely on these hopelessly weak keys eight years after they came to light is testament to just how monumental the Debian debacle was and how hard it is for users to mop up after the mess it created. Source

Until yesterday, a popular networking library for iOS and OS X used in apps such as Pinterest and Simple was susceptible to SSL man-in-the-middle (MiTM) attacks. The developer behind the framework AFNetworking on Thursday pushed a fix for the issue, a logic flaw. The flaw had lingered in the wild for more than two months but it took some repeated poking from Github users and two researchers, Simone Bovi and Mauro Gentile at the software security firm Minded Security, for the developer to finally address it. Bovi and Gentile stumbled upon the issue while doing mobile application security analysis for one of their clients in early March. After combing through the application’s source code the researchers found that the library’s SSL certification validation and its trust evaluation had been disabled, something that could have allowed any SSL traffic to be intercepted via a proxy service such as Burp Suite. “After a few minutes, we figured out that there was a logical bug while evaluating trust for SSL certificates, whose consequence was to completely disable SSL certificate validation,” Bovi wrote in a blog post yesterday, shortly before the issue was fixed. Bovi and Gentile found the issue had previously been brought up in a Github forum post in early February and that the flaw appeared to stem from a problem with version 2.5.1 of the library, introduced in late January. An additional, and more thorough post on Github 15 days ago helped the issue gain some visibility as well. “I have verified that a malicious proxy server can sniff all the contents of HTTPS communication in this case,” Github user duttski, who created a patch as a temporary workaround until the issue was fixed, warned at the time. iOS developer Mattt Thompson, who created and maintains AFNetworking, pushed Version 2.5.1 of the project live yesterday and fixed the issue by adding test and implementation of strict default validation, according to the library’s release notes. The library is a key part of popular social media applications like Vine and Pinterest on OS X and iOS. The framework also figures into apps and services primarily used by app and UX developers like Heroku and Parse. Source

GitHub has been ordered to hand over records on some of its users to taxi-booking app Uber after unsuccessfully challenging a subpoena. Last month, Uber announced its driver database had been hacked in May 2014, but it had only noticed in September of that year. Uber discovered that a supposedly secret database access key had somehow ended up in a couple of Gists in a public area of GitHub. It's alleged this key was spotted by miscreants who used the key to delve into Uber's internal database of driver names and license plates. Uber asked GitHub to hand over the web access logs for the two Gist pages for the May-September period. GitHub refused, and so on 27 February this year, Uber created a John Doe lawsuit in order to subpoena GitHub to hand over the logs. Earlier this month, GitHub challenged the subpoena in a San Francisco court but lost, with the judge late last week giving GitHub 30 days to comply. Uber argued during the hearing that the two Gist posts (both of which have been offline since the lawsuit was filed) should have had very little traffic, and the data on who visited them "should generally reveal people, who were affiliated with Uber and who worked on the Uber code near the time of the unauthorized download." The judge also found that Uber had "shown that its need for early discovery outweighs the prejudice to GitHub, as GitHub is an established provider who routinely deals with discovery requests and would suffer little burden from producing the requested information." In other words: hand it over, GitHub. We asked GitHub and Uber to comment on the case; both companies are based around the corner from our office in San Francisco. GitHub told us: "We don't have any additional info to share." Uber's lawyer has yet to return our call or email. Source

Era ?i timpul. Au f?cut tool de migrare automat? spre GitHub, ceea ce e mi?to. Google Open Source Blog: Bidding farewell to Google Code