Jump to content

Search the Community

Showing results for tags 'exploiting'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Site Related
    • News & Updates
    • Site / Forum Feedback
    • Member Introduction
  • News
    • General News
    • FileSharing News
    • Mobile News
    • Software News
    • Security & Privacy News
    • Technology News
  • Downloads
    • nsane.down
  • General Discussions & Support
    • Filesharing Chat
    • Security & Privacy Center
    • Software Chat
    • Mobile Mania
    • Technology Talk
    • Entertainment Exchange
    • Guides & Tutorials
  • Off-Topic Chat
    • The Chat Bar
    • Jokes & Funny Stuff
    • Polling Station

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Found 3 results

  1. Attackers love exploiting the naivety of users because it’s so easy. All it takes is one successful phishing email to persuade just one user to hand over their organizations login details. Once that hacker gains entry to your systems, you’re not going to find out until it’s too late — your anti-virus and perimeter systems aren’t programmed to pick up on access using legitimate login details, giving snoopers all the time in the world to, well, snoop. And if it’s not exploiting them, well then we can always rely on good old fashion ‘careless’. It was only recently that UK political leaders were publicly (and almost proudly) proclaiming their own particularly poor password habits on Twitter. MP Nadine Dorries admits she regularly shouts the question “What is my password?” across the office, and after her being criticized on Twitter, MP Nick Boles defended her by agreeing with a journalist that password sharing is rife among MPs. As much as it’s easy to poke holes in politicians’ hapless knowledge of IT security, the truth is that most employees within the business world share passwords too. So while users remain the biggest threat to a company’s security, blaming employees is never the right route to take. Employers are (usually) human. They are careless, flawed and often exploited. So, how are you supposed to spot inappropriate user access when it’s already been defined as appropriate? Spotting the threat Security must be there to protect users from both careless and malicious behavior and to protect the business from outsiders trying to gain access by pretending to be employees. When you boil it down, the only way to really tell if someone is a malicious insider or an intent external threat actor is by allowing them to perform actions (such as launching applications, authenticating to systems, accessing data, etc.) and determine whether the actions are inappropriate. But given the majority of your user population doesn’t act the same way everyday – let alone the next week or month – it makes more sense to spot the threat actor by looking at leading indicators of threat activity, rather than waiting for the threat activity itself. One of the most accurate leading indicators is one no malicious insider or external threat actor can get around – the logon (local, remote, via SMB, via RPC, etc.). Endpoints require logons for access, lateral movement of any type requires authentication to access a target endpoint, and access to data first requires an authenticated connection. The leveraging of Logon Management solutions provides organizations with not only the ability to monitor logons and identify suspicious logon activity, but to also craft logon policies to limit the scope of account use and automatically shut down access based on inappropriate logon behavior. By using the contextual information around a user’s logon (origin, time, session type, number of access points, etc.) genuine logins become useless to would-be attackers. So, while there might not be a patch for the user quite yet, keep in mind that you do have a foolproof way to make sure authenticated users are who they say they are, identify any ‘risky’ user behavior and put a stop to it before it ends up costing you capital, customers and your company’s reputation. To read more about external attacks and how to detect and stop them, read our latest whitepaper “Stopping the External Attack Horizontal Kill Chain”. Source
  2. The way Facebook Notes handles HTML image tags could could give an attacker the ability to launch distributed denial of service attacks against external sources, using the power of the massive network to amplify the attack. Facebook Notes is a sort of Tumblr-like internal blogging feature built into the world’s largest social network. It lets users write, edit, and publish content in excess of Facebook’s 63,206 character limit imposed on status updates. Facebook lets users embed various HTML tags into their notes. However, the way that Facebook processes <img> tags could present serious problems for the sources and hosts of those images. Independent researcher Chaman Thapa wrote onhis personal blog earlier this week that whenever an <img> tag is used in Facebook Notes, the social network crawls the image from the external server where it is stored and caches the image. He explains that Facebook only caches each image once, but the cached version can be bypassed using random get parameters – essentially tricking Facebook into thinking that one image is multiple images and causing the service to crawl the source of that single image as many times as there are random get parameters targeting it. Thapa claims that bigger files, like PDFs or videos, could amplify the attack. Given enough get requests, this could create a denial-of-service condition for the server hosting the image file being crawled. With limited computing resources, Thapa managed to generate 900 Mbps of outgoing traffic by compelling Facebook to crawl a 13 MB PDF file. Thapa claims that 12 of Facebook’s servers attempted to fetch the PDF file some 180,000 times. Thapa reported the bug to Facebook. At first, he said, the company misunderstood the vulnerability, thinking it could only cause a 404 error, and that such an error did not constitute a high-impact bug. After some back and forth between Thapa and Facebook’s security team, the social network eventually conceded that the bug does in fact exist. They also told Thapa that his bug did not qualify for a bug bounty payment because they had no intention of fixing it: “In the end, the conclusion is that there’s no real way to fix this that would stop ‘attacks’ against small consumer grade sites without also significantly degrading the overall functionality,” Thapa cites Facebook as having said. “Unfortunately, so-called ‘won’t fix’ items aren’t eligible under the bug bounty program, so there won’t be a reward for this issue.” The representative did however offer the following consolation to Thapa: “I want to acknowledge, however, both that I think your proposed attack is interesting/creative and that you clearly put a lot of work into researching and reporting the issue last month. That IS appreciated and we do hope that you’ll continue to submit any future security issues you find to the Facebook bug bounty program.” Thapa says he reported the bug to Facebook on March 3. The above correspondence took place on April 11. A Facebook spokesperson confirmed Thapa’s account of events to Threatpost. “We appreciated this report and discussed it at some length. Ultimately, we decided against making changes to avoid disrupting intended and desirable functions,” the spokesperson said. Thapa wrote that he is unsure about why Facebook is choosing not to fix his bug. A source with technical understanding of bugs like this one explained to Threatpost that if a site were to receive large amounts of traffic in this manner, rate-limiting or disabling based on the user agent would be an effective defense. “I’m not sure why they are not fixing this,” Thapa wrote. “Supporting dynamic links in image tags could be a problem and I’m not a big fan of it. I think a manual upload would satisfy the need of users if they want to have dynamically generated image on the notes.” Source
  3. A teenager has been arrested by the Canadian police in relation to the infamous malicious breach on the country's taxpayer system using one of the most critical internet flaws, Heartbleed. Heartbleed bug, that made headlines over past two weeks and every websites around the world flooded with its articles. Every informational website, Media and Security researchers are talking about Heartbleed, probably the biggest Internet vulnerability in recent history. According to the Royal Canadian Mounted Police (RCMP), a 19-year-old 'Stephen Arthuro Solis-Reyes' of London, Ontario, is charged with the unauthorized access of the computer and criminal mischief in relation to the data breach of taxpayer’s private information from the Canada Revenue Agency (CRA) website. “The RCMP treated this breach of security as a high priority case and mobilized the necessary resources to resolve the matter as quickly as possible,” Assistant Commissioner Gilles Michaud said in a statement. “Investigators from National Division, along with our counterparts in ‘Ontario’ Division have been working tirelessly over the last four days analyzing data, following leads, conducting interviews, obtaining and executing legal authorizations and liaising with our partners,” he added. After the public disclosure of Heartbleed bug on April 9, Solis-Reyes allegedly exploited this most critical security vulnerability, present in the OpenSSL of the CRA servers, to extract the private and sensitive information, including the social insurance numbers from the company’s system, before the computers were patched. Heartbleed is a critical bug in the OpenSSL's implementation of the TLS/DTLS heartbeat extension that allows attackers to read portions of the affected server’s memory, potentially revealing users data, that the server did not intend to reveal. Though there were allegations on the U.S. intelligence agency NSA of using the Heartbleed vulnerabilities from years to gather confidential information. But, this is the first known incident of hacker exploiting the critical internet Heartbleed bug to steal and compromise the data from the servers which are running on an affected OpenSSL version. Exploiting the Heartbleed bug itself rarely leaves any traces, unless the attacker is not sending millions of heartbeats continuously from his own IP addresses. "The fact that they were able to trace it back to someone implies that it is not the work of organized crime or a professional hacker. It would be someone of very low skill." said Mark Nunnikhoven, Trend Micro. Solis-Reyes was arrested at his residence without incident on April 15 and is scheduled to appear in court in Ottawa on July 17, 2014, RCMP reported. The police also seized computer equipment from his residence, while the investigation is ongoing. Source
×
×
  • Create New...