PS3 HDMI fix

Well it takes suffering to learn things. I just hope this one was worth it. I've just spent the best part of an hour trying to fix my PS3 after installing a bf3 update. The screen went blank and there was no sound or video.

"Oh God it's broken my PS3!"

Well close but no cigar. It actually broke the HDMI connection between the PS3 and my television. So to fix it turn off (i.e. unplug) both the PS3 AND the television. Restart and fixed.

CMS exploits

A path to experience

CMS exploit development has been running rampant around places like exploit-db for ages. I took to doing a few of my own with positive results a few months back. But why is it so popular? And is it really worth doing?

CMS sploiting for fun '; -- and profit

Content Management Systems (CMS), are used to make developing and running web sites simple. They come fully loaded with useful tools and db plugins, giving a quick, professional look. No wonder they are used in their droves to produce many of the web sites we visit. There are many to choose from and range from the strictly amateur to the professional/expensive.
Exploit development has been a serious past-time for the following reasons:
    - Many of them are open source
    - They can be set up offline, speeding up/legalising the hacking process
    - They are used in real life, so the results of finding vulns are more rewarding

CMSs are therefore a cheap, easy way to get into web exploit development and source code review. No wonder juniors everywhere are using them to cut their teeth on web app pen testing and exploit development.

But surely they have been done to death. Is it still worth it? Are their vulnerabilities out there?

CMS 2012

Certainly finding straight SQL injection on the home page is only going to be the case if you're looking at an old, poorly maintained or infrequently used CMS. Not really rewarding and unless you are just starting out, not very educational. You therefore have two options:
 #1 - Find low risk vulns (reflected XSS, CSRF)
 #2 - Dive into source code

I'm not going to talk about #1 aside from the fact that I'm not a fan. Instead I wanted to run through a better CMS analysis method. I'm afraid you will need to look at the source. This may take the fun out of it for most, but if you want to find a worthwhile vuln that is actually respectable, then you need to broaden your game.
    1. Start by grepping
        You need to know key functions that will give you the big wins. Things like exec(), sql_query() and fopen() are gold. If you can find these in the files, then you have a starting point.
    2. Find out their variables
        Do they take variables? If so start following the breadcrumbs. There are some basic tools for this but they aren't particularly good and may lead to false negatives. In any case, this is a learning process so take the time to do it by hand, at least at first. Are they in functions or classes? Are these functions or classes called anywhere?
    3. Edit the script to make life easier
        The joy of offline analysis is that you can change the code. Add in a few extra echos to help follow through the code as it gets executed. It won't be like that in the end, but then you will have the exploit ready and no longer need them.

That's really it. I wanted to write this because there is so much good development in the CMS community and they're getting stronger and stronger for it. It's also infinitely more rewarding to get code execution from a CMS that is really out there and being used. Far better than dull little unrealistic test sites. Just be ethical with your disclosure!

CSRF - improving the basic attack

CSRF is a low risk vuln for script kiddies

I think Cross site request forgery (CSRF, which I've always been alone in calling see-surf) gets a pretty bad rap, not least because script kiddies are flooding exploitdb with boring CSRF attacks against CMSs that no-one uses. But let's not write off CSRF as a bland client-side attack just because people are using it poorly. CSRF actually has very viable and useful applications that takes a little longer to create, but the results are totally worth it.

It all revolves around how we are trusted when we log in. Normally this means C-surfers go looking for all the functions that doesn't require creds or authentication to complete. Most half decent apps will therefore check and protect against this. But quite often they make a mistake.

A better surf

Lets take an example:
 Joe's email web portal allows users to log in and then allows passwords to be changed. Fearful of CSRFing, they make the user include their old password in the request. Solved! But of course the user is who they say they are, so don't limit them on retries when they get the password wrong....

Yep. We can run dictionary attacks through CSRF.

So is this so great? It's a little slow (maybe a couple of minutes to run through a decent dictionary and ultimately still limited to having people visit your site that have to be logged in to the site you want to hit to be vulnerable. So yes it's still a limited client side attack, but it's one that works on some pretty popular apps.
Just load a dictionary into a JavaScript array and run it in a loop. JavaScript can handle GET and POST.

The only problem is that it's blind. We could change 50 people's passwords with this attack, but how do we know it's worked, and to whom?

Consequences....did it work?

Obviously this is easy if there's other attack vectors, like XSS but then if you've got cross site, then you hardly need CSRFing. The important point here is that other lower vulns can be used alongside this one to build a more valid attack vector.

Enumeration of usernames allows trying the altered password against the list. As you're only trying one password on each account, it shouldn't cause a lockout.

CSRFing multiple points can make the attack victims more visible. Changing a profile value may be pretty lame by itself, but if it is done along side the password change, it would become a flag to compromised accounts.

SQLite Injection

There does seem to be a lack of information regarding SQLite injection. This is probably because SQLite is so limited compared to other SQL databases. However, it does seem that given Android (and iOS?) interest in using them, there is something to be said for writing up some basics and findings that I've had so far.

 I will try to write this from a more general SQLite injection angle rather than OS specific. First enumeration. Getting out the master database is fairly straight forward as long as your injection is early on. If you can get results posted to the screen the enumerating the database structure is easy:

"* FROM SQLITE_MASTER; --"

The SQLITE_MASTER database holds descriptions of all the tables so is a quick win for enumeration. From there, more select statements will get you the rest.

If the injection point is not at the WHERE or SELECT clause then things may get a little more difficult. More particularly interesting when the injection is at the ORDER BY clause. This means that not only can you not add in the table to select from, but you also can't use a UNION statement to join it to a fresh select statement. I've yet to find a good way to solve this one so please, answers on a postcard.

This is just an introductory post. I want to cover effective manual blind SQLite injection but this will have to wait until next time.

The other area that I want to look into is the use of the "." commands. SQLite seems to have many extra functions, which I'm guessing can not be used through API calls. Perhaps the PHP exec() function might? It would certainly be good to know where, if anywhere, these values could be used, as it would allow inclusions of other files.

Finally I want to take a look at whether the values can be overwritten with long/specially formatted strings. The .db file could then be manipulated into becoming something else (okay so this one's a long shot, but worth taking a look at).

Stay tuned

vmware quick fix

Quick solution to the "Taking ownership of this virtual machine failed" Error.

Go to the vmware image's folder and delete the .lck file

Apache, php and dlls

For a while now I've been adding more and more features to Apache and PHP for testing. I want to add things like LDAP and SQL support in PHP but the libraries fail to load when I update the PHP.ini file. I have continually come up against error messages like these:

PHP Warning: PHP Startup: Unable to load dynamic library 'c:/php/php_ldap.dll' - The specified module could not be found.\r\n in Unknown on line 0

and

PHP Warning: PHP Startup: Unable to load dynamic library 'c:/php/php_pdo_mysql.dll' - The specified module could not be found.\r\n in Unknown on line 0

The problem I had was actually nothing to do with PHP trying to find these libraries. Instead it was to do with the other libraries that they needed. The Apache logs make no mention of this. You need to search the internet to find which dlls are needed depending on your web server and the dll you wish to include.

For example, running PHP and Apache, to include LDAP, update the php.ini and then also make sure that libeay32.dll and ssleay32.dll are in the Apache bin folder. Then voila! No more nasty errors.

Movember

So Movember isn't about just being manly, it's also an opportunity to raise any points that might help us men live a little healthier:

As men, we are told that we are genetically more likely to die from various diseases than women. Unfortunately (or should that be fortunately?) this is not the case. Many factors are actually more to do with our attitudes that our dna. I'm sure it's a similar story across the world but in the UK, women in our age group are twice as likely to go see a doctor than us men are. The top 10 reasons for us men not wanting to go are:

1. Sitting around - "they don't like the waiting time involved"
2. Health services are feminised - "the decor and bias of information towards women"
3. Embarassment - "Men are embarrassed to discuss intimate feelings and information"
4. No point unless there is something wrong - "Below 40 years of age, men only view doctors in terms of emergencies"
5. Men aren't socialized into visiting the doctor - "whenever men visit the doctors, they only see women and older people."
6. Suck it up' attitude - "men are socialized into internalizing their emotions and physical discomforts"
7. Defects are signs of weakness - "visiting doctors may signal illness or disability"
8. Fear of being judged - "their problem or physical state is something unique"
9. Men exaggerate the negative qualities of health provision - "men find the health care system inadequate, a waste of time."
10. Doctors aren't equated with preventive health - "at age 40, men generally have to see their doctor regularly. They realize the benefits of screening than waiting to happen."


Sadly, I can not stand up as a role model. I have never discussed cancer with my doctor, I remember something vaguely about checking yourself from school and the notion of a prostate exam is something I connect with the over 50 year olds.

People won't tell you what to do to keep you healthy. We don't stand around the bar discussing the best way to check your testicles for lumps (maybe that's not a bad thing). You need to go and find this out for yourself. Otherwise you are just waiting for something to go wrong, which is a really stupid idea when you think about it.


Links to answer your questions:
http://menshealth.about.com/od/diseases/u/concerns.htm - general concerns list
http://cancer.about.com/od/cancersaffectingmen/tp/menscancersign.htm

A statistic to finish up on. Testicular cancer normally affects men between 20 and 39. The survival rate is over 95%. Look after yourselves men.