Talk is no longer enough for IT security pros, keynote speakers say at ISSA-LA conference(author unknown)

OAuth 1.0 emerged from the large social providers like Facebook, Yahoo!, AOL, and Google. Each had developed its own alternative to the password anti-pattern. OAuth 1.0 reflected their agreement on a single community standard. Preview Text:  OAuth was created to solve the problem of sharing two-legged credentials in three-legged situations. ...prabath

If you’ve been following along with the previous set of posts about the BDD-Security framework, you’ll know that it relies on Selenium scripts to navigate the application. Wouldn’t it be great if you could use that existing navigation code to populate Burp scanner, then perform the security scan and have the results integrated in the BDD reporting? Read on to find out how :)

BDD-Security makes use of the resty-burp tool to communicate programmatically with Burp. You’ll need to have resty-burp downloaded and installed, together with a licensed commercial version of Burp scanner in order to perform the automated scanning. Resty-burp is a maven project so is started with the usual:
mvn exec:java

If you prefer you can even run Burp and resty-burp on a different host than BDD-Security, just update the IP address in the burp section of the config.xml file.

With that out the way, we can get on with configuring the BDD-Security side of things. In the previous post we added 3 short methods to the TeamMentorWSApplication class:
- listUsers()
- createArticle()
- and createUser()

They were created to perform the authorisation tests, but we can re-use them for burp scanning. Since the admin user is permitted to call all of those methods we’ll wrap them all into a single method and annotate it with the @SecurityScan annotation:
@SecurityScan public void adminWorkflow() { login(Config.instance().getUsers().getDefaultCredentials("admin")); listUsers(); createArticle(); createUser(); }

You can annotate any number of methods with @SecurityScan, and they’ll also be used for burp scanning- the only requirement is that they don’t have parameters.

We can now run the automated_scanning.story and inspect the results.

Most of the tests pass, but Burp reports two potential XML injection vulnerabilities.


At this point, we would manually inspect these issues to see whether they’re real or false positives. In this case, they’re false positives so we can add exceptions so that they don’t show up in future test runs by modifying the filterIssue method in net.continuumsecurity.reporting.BurpAnalyser:
public ScanIssueBean filterIssue(ScanIssueBean issue) { log.info("Start Burp Issue filtering:"); if ("Session token in URL".equalsIgnoreCase(issue.getIssueName())) { //If the session ID is not in the URL, then this is a false positive if (Utils.extractSessionIDName(issue.getIssueDetail()) == null) { log.info("session IDs not found in the burp detail, filterIssue() returning null. "+issue.getIssueDetail()); return null; } } if ("Cookie without HttpOnly flag set".equalsIgnoreCase(issue.getIssueName())) { //This test is already defined in the session management scenario log.info("HttpOnly issue found, ignoring as it's already defined in a BDD test"); return null; } if (issue.getIssueDetail().contains("xmlns XML attribute appears to be vulnerable to XML injection")) { log.info("Ignoring xmlns XML attribute false positive"); return null; } if (issue.getIssueDetail().contains("The xmlns:soap XML attribute appears to be vulnerable to XML injection")) { log.info("Ignoring xmlns:soap attribute xml inj false positive"); return null; } log.info("Stop Burp Issue filtering."); return issue; }

The last 2 “if” statements are used to ignore these XML issues. Re-running the scan will show that all the scenarios in the automated_scanning.story pass.

There is a remote exploit in the wild for PHP 5.4 ...(more)...(author unknown)

Two interesting papers from Microsoft Research, both from June 2011. Interesting because they seem to go against the prevailing trend that we are all doomed as a result of poor security.

"Sex, Lies and Cyber-crime Surveys" argues that cyber crime surveys are in general pretty rubbish. It discusses the difficult of performing surveys properly, especially on relatively rare phenomena. From section 4.3:

• "Our assessment of the quality of cyber-crime surveys is harsh: they are so compromised and biased that no faith whatever can be placed in their findings."

Of particular interest to application security people is the following from the conclusion:

• "The importance of input validation has long been recognized in security. Code injection and buffer overflow attacks account for an enormous range of vulnerabilities. You should never trust user input" says one standard text on writing secure code. It is ironic then that our cyber-crime survey estimates rely almost exclusively on unverified user input. A practice that is regarded as unacceptable in writing code is ubiquitous in forming the estimates that drive policy. A single exaggerated answer adds spurious billions to an estimate, just as a buffer overflow can allow arbitrary code to execute."

The second paper, "Where Do All The Attacks Go?" tries to answer the question "Why isn't everyone hacked everyday?" Here's the abstract:

• "The fact that a majority of Internet users appear unharmed each year is diffcult to reconcile with a weakest-link analysis. We seek to explain this enormous gap between potential and actual harm. The answer, we find, lies in the fact that an Internet attacker, who attacks en masse, faces a sum-of-effort rather than a weakest-link defense. Large-scale attacks must be profitable in expectation, not merely in particular scenarios. For example, knowing the dog's name may open an occasional bank account, but the cost of determining one million users' dogs' names is far greater than that information is worth. The strategy that appears simple in isolation leads to bankruptcy in expectation. Many attacks cannot be made profitable, even when many profitable targets exist. We give several examples of insecure practices which should be exploited by a weakest-link attacker but are extremely difficult to turn into profitable attacks."

The main conclusion is that it is difficult to calculate risk accurately if you are basing your calculations on cyber-crime surveys. It is more useful just to concentrate on the impact of a threat.

Useful Links:

• Microsoft Research: Sex, Lies and Cyber-crime Surveys
• Micrososft Research: Where Do All the Attacks Go?

The continuing increase in visitors to the Pinterest site may be a primary cause why it’s becoming a hit for cybercriminals’ scams and schemes. In March, we spotted scammers using popular brands to lure users into “pinning” fake posts that led to surveys scams. This new wave of survey scams I found came from my search using “pinterest” as keyword.

Users who re-pin the posts from the sample above will most likely spread the post.

In addition, I also spotted posts using URL shorteners such as bit.ly and goo.gl. When clicked, the shortened URLs/the fake posts lead to any of the following URLs:

• http://pinterest.co{BLOCKED}t.info/?419
• http://pinterest.com-{BLOCKED}key.info/Thank-You/fb/
• http://pinterest.co{BLOCKED}s.info
• http://pinterest.{BLOCKED}one.info
• http://pinterestgift.{BLOCKED}hing.info
• http://pinterests.{BLOCKED}onus.info

Upon clicking the link, users are redirected to a Pinterest-like webpage offering prizes, vouchers, gift cards and others:

Made to resemble like a typical Pinterest webpage, the fake site features a search field, add+, an about. However, these are mere images and are not clickable. The clickable links are those that redirect to survey scams such as Body Age Quiz.

After a user fills out the fields required in the scam page, users are also required to enter their mobile numbers. Users who do provide their numbers will receive a code on their mobile phones and will continue to receive unwanted messages, charges and other scams via text message.

And Via Email, Too

Another thing I’ve noticed is that the fake site requires an email address:

Users entering their email addresses are brought to complete several steps to get the supposed offer. Users receive an email claiming to be from Pinterest. The email urges the user to click on the link found in the message body to confirm the subscription. Clicking on the link redirects the user to a Pinterest-like scam page. Again, all the clickable links lead to the same scam pages.

Upon closer investigation of these attacks, I noticed that before users are redirected to the fake Pinterest sites, the connection passes through ad-tracking sites. This way, the number of visitors are tracked, determining the supposed earnings of the scammers. Based on our data, the fake Pinterest URLs are being visited since May 2. Fake Pinterest posts hosting scams are likely to spread within Pinterest via users who re-pin the posts. The “offers” in these fake Pinterest posts look enticing after all. Plus, some users would want to ask the rest of the Pinterest community to verify such offers, like this user.

Pinterest has since removed some of the fake Pinterest posts. Trend Micro users are also protected from these scams by the web reputation technology in our Smart Protection Network™.

Post from: TrendLabs | Malware Blog - by Trend Micro

Bogus Pinterest Pins Lead to Survey Scams

Today's ever-changing threat landscape requires proactive security efforts to identify threats and adapt defenses quickly.(author unknown)

Post [9] Apple Filing Protocol (AFP)

The Apple Filing Protocol (AFP) is a network protocol that offers file services for Mac OS X and original Mac OS. In Mac OS X, AFP is one of several file services supported including Server Message Block (SMB), Network File System (NFS), File Transfer Protocol (FTP), and WebDAV.http://en.wikipedia.org/wiki/Apple_Filing_Protocol

Lives on TCP port 548

LOW?




What can I do with it?

• Read access to files/folders (always fun)
• Write access (sometimes)

Discovery?

• Vuln scanners (duh)
• Nmap scripts
• afp-showmount
• afp-serverinfo
• afp-ls
• afp-brute
• afp-path-vuln (directory traversal exploit)

Nmap examples

Connecting to AFP servers
Super easy if you have a MacLinux you can use Afpfs-ng




Window? dunno. Don't think so...

The ZTE Score M phone, apparently available via Metro PCS in the US, comes with a special suid backd ...(more)...(author unknown)

Recently, Trend Micro researchers encountered a potential vulnerability that affected users of Yahoo! Mail. We discovered several emails used in targeted attacks that contained JavaScript in the “From” field that attempted to launch a Document Object Model (DOM)-based cross-site scripting attack against the recipients of the email. However, we were not able to replicate the attack successfully. We have been in touch with Yahoo! about this problem.They, too, were unable to replicate this attack successfully at that time. However, to protect users against any such problems Yahoo! has strengthened their filters that sanitize user emails in order to protect against these kinds of attacks.

This is not the first time that vulnerabilities have been found in popular webmail providers. We discussed almost a year ago that some of the major webmail providers – Gmail, Hotmail, and Yahoo! Mail – were all found to have some sort of vulnerability that compromised either the user’s email account or their system. It shouldn’t be a surprise that they’ve become targets as well: just about everyone uses these free services, and users don’t expect these services to have security problems of their own.

As we’ve highlighted before, vulnerabilities like these are used in targeted attacks. Whether it’s vulnerabilities in user software or cloud-based services like free webmail, vulnerabilities allow attackers to compromise systems without the target being aware that anything has happened. This is extremely useful to attackers as the content compromised email accounts can be stolen by attackers and the account can be used to launch further attacks against the victim’s contacts.

Post from: TrendLabs | Malware Blog - by Trend Micro

Cloud-based Services Vulnerabilities Also Used in Targeted Attacks

Client-side, or local, storage is an area of concern for privacy and security. Therefore I was keen to attend the latest meeting of the London Web Performance Group titled HTML5 and Localstorage - Storage in the Browser at the Lamb Tavern (building c1780, but on the same site since 1309) in Leadenhall Market on Wednesday evening.

I almost changed my mind as I was also tempted to attend another local event on the same evening about NoSQL for Java Developers. Anyway I was very pleased I went to the client-side storage event, but it was so well-attended I almost did not have a seat. As usual, Stephen Thair (@TheOpsMgr) had done a great job organising the event.

Andrew Betts (@triblondon) described his experiences developing HTML5 applications for mobile devices, avoiding native code whenever possible, so that content could be available when the device is offline or in poor signal areas by using client-side storage. He described the pros and cons of using HTTP cookies, Indexed Database API (IndexedDB), Web SQL Database (WebSQL), local storage (key/value store) and Application Cache (or AppCache). Well the answer of which to use is "all of them". Andrew described how the FT.com application makes use of each type's advantages, to combine together into a responsive and network-robust application suitable for the most frequent and demanding of users. Therefore cookies are used for session management, AppCache for a default fallback page, local storage for static content such as HTML scaffolding, JavaScript and style sheets, and IndexedDB/WebSQL for the HTML content of pages. Thus they manage to fit the application into the HTML5 constraints imposed by different operating systems.

He explained many of the techniques used to circumvent mobile network and device-specific issues, but also explained how they managed to squeeze extra storage by compressing content as ASCII or base64 encoded data into JavaScript's UTF-16 double-byte encoding. It is a very clever piece of optimisation, which could also be used for code obfuscation. Details in the presentation slides.

I think users of client storage will have to be careful if it might be determined to be tracking technology. In the FT.com application case, this client storage is not offered to casual web site users, but only to those who have installed the app, are registered and log in. Thus there are opportunities to obtain consent, over and above any warning the device may offer. We are expecting to hear more about the ICO's plans for enforcement of the new regulations at a press conference this morning. Other HTML5 security issues are of course still a concern here. I was slightly troubled by one feature mentioned.

The presenter's slides are now available.

Client-Side Storage in HTML5

Clerkendweller

(author unknown)

...(more)...(author unknown)

Overview One of the sections on the ISC Tools page is Information Gathering at https://isc.sans ...(more)...(author unknown)

...(more)...(author unknown)

PayPal among organizations invited to help shape security protocol for .secure that also can be used in existing domains(author unknown)

Once in a while, someone comes up with the idea that firewalls are really not all that necessary. Mo ...(more)...(author unknown)

Compliance alone should never be the only goal(author unknown)

The massive botnet of Mac computers left millions of dollars in potential profits on the table, researchers at Symantec say(author unknown)

The massive botnet of Mac computers left millions of dollars in potentially profits on the table, researchers say(author unknown)

Howard A. Schmidt, the first-ever U.S. cybersecurity coordinator, has resigned and will retire later this month to enter academia(author unknown)