• HiJacking login sessions (covered in this article)
• Inserting malicious code
• Using resources of your visitors/website
• Inserting links to undesirable websites
• Stealing sensitive information

XSS? It’s just a popup!

The common misconception of XSS attacks is that they are benign and of no real significance. Injecting HTML and JavaScript into a page was, once upon-a-time, fairly pointless and meant little more than funky stuff happening to the user inputting the malicious data. The power of JavaScript and now HTML, with offline storage and heavy inbuilt DOM manipulation, has grown exponentially over the past few years.

There are many notable instances of malicious JavaScript deployment being used for exploitation very effectively. Cross Site Scripting attacks have been used against the majority of big social media websites, among others, with notable mentions including…

Twitter suffered an account hijacking exploit, which snared well over 100,000 Twitter accounts. A recent Yahoo XSS exploit lead to many comprimised accounts but the true number is unknown.

FaceBook has been plagued by vulnerabilities, mostly due to it’s popularity. A notable FaceBook XSS flaw was recently discovered in it’s insant messaging JavaScipt handling which could lead to full access to the target’s private messages. Gmail has been susceptible to several stored and reflected Cross Site Scripting attacks over the past few years. A vulnerability was introduced when Google+ integration was rolled out and lead to complete account takeover.

Anonymous recently used very simple JavaScript deployment in a very effective manner by inserting a script called “The Hive”, which is a JavaScript based Ddos tool. The aim was simple: take down a well known, and possibly highest value target of all; the Department of Justic. They were successful and it required very little resources compared to previous Ddos attacks.

There are many more examples, but that should be enough to scare even the laziest developers.

An XSS Cookie Stealer In Action

The process of hijacking a user’s session is fairly straight forward but the required code usually takes a little tweaking, depending on the target. The idea is simple: find a point to inject JavaScript, get someone with escalated permissions to visit the page, log their information and replace your current login with theirs.

The attackflow is simple:

1. Find a vulnerability
2. Create a payload
3. Entice an admin/staff/user to visit the desired URL
4. Clone their session or cookie
5. Login as victim (Admin?)
6. ???
7. Profit!!!

Ok so jokes of profit aside, the code required to be deployed on the target site is usually minimal as most of the work happens in a small script used to capture the data. Only two files are required – one to process the data and one to store the logged information (it could be combined into one file, but this is an example on protection… Not skiddie copy/pasta material!).

Introducing “Teh Cookie Monster!”

I spent some time creating a simple cookie logger to demonstrate how this attack could take place. The main script — “cookie-monster.php” — will handle the data collected and “cookie-jar.txt” will simply log the cookies and other information we grab.

The aim of the script was to log all cookies from our target site to a file and allow them to be viewed. The code below is a modified working example that we use internally to help with penetration testing and script hardening.

File: cookie-monster.php

In order for the above code to work we need to embed some pretty simple JavaScript into our target website…

The line of code above will load our script as a blank image and appear to do nothing to the user. The cookie-monster.php script will grab the visitors cookie along with other data, then save it to cookie-jar.txt for later viewing. This could be expanded to return a valid image.

We have our code and we know what to do, so let’s use Damn Vulnerable Web Application as an example. I have it installed on my localhost and have two accounts – “admin” and “abeon”. I login as “abeon” and create a malicious URL to send to “admin”. This is where the uber-l337 hacking skillz come in handy… We have to make the page attract the admins attention without causing alarm. There are many tactics but an effective one seems to be pretending to report an issue, so kind of break the page but leave it intact enough so as to not arouse suspicion.

Something like this should do…

Yup, that’s right. A long and ugly URL which is only partially encoded and not very well. This is intentional as the user will see the “I BROKE IT” message clearly but will probably miss the script tags. There are many ways to obfuscate the payload such as mixed encoding, internal redirect, URL shortening services, external retrieval and more.

cookie-monster.php will log the information when someone clicks the link and display the saved data. View the cookies by visiting the script’s URL with the mode set as 1 and password as defined at the top of the script:

http://example.com/cookie-monster.php?mode=1&pswd=123-derpy_skid-321

There are many ways to edit cookies but browser plugins are the most popular. Edit this cookie is a useful cookie editor plugin for Chrome. Cookies Quick Manager is very similar, but for FireFox.

Protecting Against XSS Attacks

Defending against Cross Site Scripting attacks is handled in a similar way to most other forms of exploitation: validation and sanitization of all data is a must!

The best way to defend against malicious user input is to validate any data that could cause harm, such as checking for a valid email address or phone number, and sanitize any data that is displayed back to the user by converting to benign code.

PHP’s inbuilt htmlentities and htmlspecialchars functions handle both tasks in a very similar fashion. htmlspecialchars converts only 5 characters while htmlentities will convert any HTML characters into their representative counterparts. For this reason, it’s advisable to use htmlentities with both ENT_QUOTES and UTF-8 flags set as below.

Setting ENT_QUOTES will convert both single and double quotes which is essential as both can cause serious problems for security. Using the UTF-8 encoding flag is also very important when using ENT_QUOTES as it defines the encoding used and can help to prevent bypassing using obfuscated code.

A final word of warning:
This example focuses on reflected XSS attacks. A stored XSS vulnerability can be far more damaging as any visitor to the site can be affected – not just those visiting malicious links.

The biggest offender for XSS attacks is without a doubt search forms. Any data a user can alter should be considered a potential risk. Creating validation and sanitization functions through which data can be passed is always easier and more reliable than adhoc coding. There are frameworks and pre-built classes specifically for validation but altering or further developing these can be difficult.

The post An XSS attack in action appeared first on Abeon Tech.

My computing hobby developed into a career in internet marketing as services moved online. Converting knowledge from my hobby to improve the efficacy of marketing campaigns was easier than hacking banks… Or so I thought. I was recently employed by the leading marketing agency located in Brighton.

They are owned by a large multinational conglomerate which reported an anual revenue of $10 billion in 2014…

For Lulz – And To Protect My Mortgage

Legal disclaimer: I believe in following the laws of both the UK and host country when conducting security research. As the UK is one of the most oppressive regimes for a white hat hacker, it’s a good starting point from which I must restrict my activities. Jail isn’t fun. Been there. done that, got the t-shirt. The t-shirts itch.

Most white hat hackers publicise posts to show weaknesses in big institutions, demonstrate skill and/or gloat. If I’m being honest, I mocked the military more because I could than I wanted them to fix the issue.

I looked into security risks with Barclays for two reasons; I have a mortgage with them and I worked on their marketing campaign. A security breach would have been both professionally and personally inconvenient. I also assumed banking security had moved on from the days of sa:blank.

The “SSL = Secure” Myth

My initial research into the Barclays websites was fairly brief and in preperation for a job interview. It was obvious that the SSL implementation was very insecure and could easily allow MiTM attacks. Until patched, all it would have taken was a malicious access point setup in a busy branch (London, Brighton, etc) and one could easily exfiltrate account data for malicious purposes.

The first issue I reported was a redundant SSL cert installed on m.barclays.co.uk. The combination of a weak certificate and poorly configured server meant that customer data was at serious risk. The attack vector is somewhat esoteric, so I’ll omit it for brevity. I looked for further problems when I had a little more time…

XSS (Cross-Site Scripting)

I ran domains I suspected to be controlled by Barclays through a semi-automated XSS scanner I developed about a ago. I got a hit on barclaycardcentre.es. The hit was confirmed as McAfee had marked the website as being used as a phishing site. I reported the PoC and moved on…

barclaycardcentre.es/busqueda?criterio=1'autofocus/onfocus='prompt(String.fromCharCode(88,83,83))

After starting work on their marketing campaign I took another look at their network. I ran another list of Barclays domains through my XSS script. This time I spotted a similar XSS issue in barx.com, a website dedicated to stock trading…

barx.com/search-results.html?to=1451624400000&q=barclays "><svg/onload=prompt(/XSS/)>&from=1420088400000

I was a little concerned about how insecure my mortgage providers where by this point. I just decided to focus on the marketing campaign and try to get the security issues fixed when I could. Then I found a winning fail…

Public Application Connection Details

I discovered the most painful security issue in the Barclays network while looking for content related issues during an SEO audit. Two pages on the apps.barclays.mobi domain were showing PHP code as HTML, which seemed odd…

Both pages where saved in Google’s cache, so have been visible to the public for a while…

Checking the page source code showed connection details for the application…

$login = new MDG_ApplicationLogin('*snip*', '*snip*', '*snip*');

Enumerating a database once you have the application login details is fairly rudimentary. Having an admin username / password publicly available on a world leading bank is definitely a winning fail. The best case scenario is exfiltrated data. A proficient hacker will root the box and move through the network.

Stating The Obvious

It should go without saying but unfortunatly doesn’t; a global bank with total assets in the region of £1.12 trillion, and an entire team of security specialists, shouldn’t suffer from such basic security issues.

During my brief employment for the McDonald’s of marketing, I was allotted 1 hour 30 minutes to penetration test their portfolio of well known clients. I managed to find exploits on all of them. Which is just sad.

As always, the issues were fixed within days when I got in touch with the right person. The problem is that it can take months to get the right contact.

Ethical hackers are often given free swag as a way of saying thanks. It helps promote the companies we hack and they get secured in the process. All I received were legal threats from my previous employer.

Disclosure Timeline

• June 2015 – Initial report made over the phone. (first few days of the month).
• 13 July 2015 – SEO report conducted on Barclays for job interview. Weak SSL cert reported.
• 01 April 2016 – Started work on Barclays marketing. Reported 2x XSS and weak SSL again.
• 31 March 2016 – Issues escalated to Barclays IT security team. Then ignored.
• 04 April 2016 – Reported publicly available application login details.
• 13 June 2016 – Initial contact with Director of Cyber Response.
• 21 June 2016 – All issues fixed.
• 12 July 2016 – Post made public.

The post Hacking My Bank. For teh lulz. appeared first on Abeon Tech.

This article covers a few basic cross site scripting bugs in Department of Defence and Ghost Security websites. The idea is to highlight how even the most security conscience among us can forget to check for the most basic exploits.

I love Einstein. I have always had a passion for physics, relativity, and politics. A little cited quote from the aforementioned scientific genius is…

Mocking the military

As much as I hate murder, the recent escalation of terrorism has been far worse. Another idol of mine – Bill Hicks – famously said: “I was in the unenviable position of being for the war, but against the troops. And ah… Not the most popular stance I’ve ever taken on an issue”.

War is bad, m’kay. Terrorism is worse, m’kaaay… Getting on with it.

Cross site scripting is one of the easiest exploits to protect against, yet is one of the most prolific. The example below is a perfect example of an easily overlooked bug in a website that could cause a lot of damage. Simply altering a URL on the Department of Defence website allowed any HTML to get shown in the PDF document:

The vulnerable page was:

http://www.militaryinstallations.dod.mil/mcfp-web/newsletter.jsp?url=http://www.militaryinstallations.dod.mil/MOS/f?p=MI:PRINT:0::::P11_INST_ID,P11_CONTENT_TITLE,P11_CONTENT_EKMT_ID,P11_CONTENT_DIRECTORY:1930,[HTML_INJECTION] ....

The Department of Defence responded quickly and a fix was rolled out within 24 hours. They confirmed the logic issue was fixed as there were several affected pages. I imagine the reply was sent through gritted teeth, but it got fixed and everyone is happy. Mostly.

I always email the site owner, wait 12 weeks, then try additional contact to get the issue resolved. Certain religious extremist groups may not be as helpful.

My sardonic proof of concept was intended to get a reaction. The vast majority of vulnerabilities go unfixed for months, even in government websites. I have reported hundreds of exploits on websites ranging from a plumber’s personal blog to wikileaks.

Hacking hackers

So we’ve mocked the military. Why not hack the hackers? I tried to use the same simple technique on a group I’ve morally supported for a while. Ghost Security are a splinter-group of Anonymous which specialise in combating the spread of religious extremism on the internet.

Surely, the uber-1337 hax0rz can protect against a simple XSS vector? Sadly not.

Even hackers make mistakes.

GhostSec are great guys and fighting for the right team by taking down extremists. I decided to check their website because T.V kills brain cells.

Within about 30 seconds I found a validation error in their hostchecker tool:

I notified them about this on Twitter. They added some basic input validation, replying with: “just feeding our XSS database ty”.

The proof of concept code used was, as always, basic:

derp.com/?pwn=1&"><img src=x onerror=prompt(/XSS/)>

They eventually put some XSS security in place. I thought I’d test the hacker’s anti-hacker protection. Only a basic filter had been put in place:

A common XSS WAF bypass technique worked. It took about 2 minutes:

derp.com/?pwn="><marquee loop=1 width=0 onfinish=1/prompt`/XSSPOSED/`>derp</marquee>

The rest of the site seemed fairly secure so I moved on, after the obligatory bragging on social media. I read another story about them around 4 months later, so decided to check the once secure site. XSS number 3…

Trash or treasure?

The point of this rant is that even the the experts make simple mistakes. The only real difference is scale of impact. If I had been trying to recruit bad people to do silly things, it would be a very different conversation. From making websites dance, to hijacking accounts or stealing bank data…

If I can make your website dance, what are the bad guys doing? The code isn’t that different.

Update

I have been informed that Ghost Sec and Ghost Security are different entities. One apparently riding the fame of the other. The source is reliable and respected, so I trust it. The group split and skidz formed GhostSec. The story holds true as, initially, they didn’t seem to think XSS was an issue. According to press-releases, the original Ghost Security have beem known to use XSS and phishing techniques to hijack accounts. So, check out ghostsecuritygroup.com for comparison.

Feedback

The most frustrating thing is that cross site scripting attacks are the easiest to test for, most basic to protect against, indicative of weak security, and a risk on many levels. I’ve used similar techniques to circumvent world leading Web Application Firewalls, then helping to get patched, obviously.

I am genuinely curious as to why such basic exploits are still on such high priority websites. Could it be the budget is too small? Maybe the training isn’t good enough?

I’d really like to read comments from professionals and hackers alike, but hey, this is the internet – try to XSS my comment form if you must

The post Mocking the Military; Hacking Hackers appeared first on Abeon Tech.

XSS Is Bad

Cross-Site Scripting attacks (often abbreviated to XSS) are bad. They use to be nothing more than annoying popups or adverts inserted into target websites. Technology has since moved on and now the same security flaw can lead to colaborative resource management, full data exfiltration, and more. JavaScript using a simple Java extension means hackers are limited by their imagination, nothing less! If a bad guy can inject arbitrary HTML, CSS, and JavaScript into your website they can embed a Java Applet and bypass all sorts of restrictions which would otherwise be in place.

A recent example of effective XSS leverage “in the wild” was Anonymous using a JavaScript version of LOIC to sucessfully Ddos government targets. Simply asking supporters to visit unrelated but infected sites conducted the attack. The end-user was still culpable but focus shifted from the initial, very small scale hack. XSS cookie stealers are another popular method of implementing XSS as an attack vector and their use is increasing, due to the popularity of JavaScript.

XSS in Scoot.co.uk

There are multiple vulnerabilities in dashboard.scoot.co.uk subdomain. Scoot then passes this easily exploited information onto many other website, some of which include the most popular UK news services. This data passes, unvalidated, through sites to which they offer an intergrated business directory.

Arbitrary code including HTML, CSS, JavaScript and Java is stored in the database without any validation.

What is the problem?

The implementation is simple and lasting. The attack vector is classed as a “persistent XSS” or “stored XSS” exploit and is found in many input fields of the dashboard.scoot.co.uk subdodomain. The website contains many vulnerabilities but this article focuses on the stored XSS problem. The attack flow is simple: create a free business listing, add a gallery image, insert your malicious code, wait 2-3 minutes and it’s live.

An easy way to obfuscate the code is to use the second gallery image as the exploit will be hidden from initial view is present in the page source, being executed as a result.

The main culprit is an unvalidated title attribute for the gallery images. The input field allows arbitrary code to be inserted. Below is a proof of concept code:

"></a>XSS HERE<a title="

For reporting purposes I used the following:

"></a><img src=x onerror=prompt(/XSSPOSED/)> <a title="

The image below shows the entry point.

Several Newspapers Hacked!

Below are examples of the Scoot XSS vulnerability passing the insecure data onto….

The Fix using Responsible disclosure

Preventing XSS exploits is simple and can be done in one line of code. Using htmlentities with ENT_QUOTES to encode quotes and UTF-8 to convert text.

This was a stored XSS vulnerability on one site, which then passed the exploit on to several large UK newspaper websites. Getting it fixed was important to me!

I have emailed, called, and begged Scoot to fix this issue as I use thier services. Each time I was told “we will look into it”, or “it’s a feature” from confused sales staff. Several attempts to contact the relevant person about this situation have gone unresolved. It appears they care more about up-sales than security.

Disclosure Timeline

• 14 December 2012. Initial email ignored.
• 01 June 2013. Confused but lengthy phone call. Ignored.
• 01 December 2014. Two phone calls ignored. Reply was “we will look into it”
• 17 April 2015. Final email to Scoot. Public disclosure.
• 19 April 2015. Reply from developer. Issue being worked on.
• 23 April. Fix implemented by developer. Bounty received.

The post Scoot.co.uk XSS appeared first on Abeon Tech.

I’ve played and worked with computers for around 17 years. Probably a lot longer if you count my terrible snake clone for the BBC Micro. My hobby developed into a career as the internet… exploded. I have at least looked at, if not tried to code in, the majority of major languages and systems. From C to Zend, Matlab to MySQL.

My esoteric hobby has had several advantages. My obsession with the least interesting parts of computing – the mundane code – has lead to some interesting discoveries. The ability to charge for my hobby being my favourite, learning how to infiltrate most websites on the internet being a close second. I am a devoted white hat developer but not everyone follows the same ethics. My first website was hacked to show nothing but a beheading video… When I was 13. Learning security was an obvious step for me. I was obsessed with how people get hacked.

I will not deny that I’ve had some fun but it’s always been that. Virii intended for their original purpose – as a practical joke for friends. I have worked with hundreds of websites to close exploits which could have been used by people with malicious intent. I would rather get a few angrily defensive emails from developers than see terrorists use these same exploits to perpetuate their chosen brand of insanity.

Make sure your tinfoil hat is comfortable. This post will digress. I will go off on tangents. This is my rant. Feel free to call me out in the comments. Until then…

Am I a target?

A common misconception is that “my computer isn’t worth hacking”. This just isn’t true. Some of the many reasons people get hacked can include: resource abuse, data exfiltration, virus spreading, and last but by no means least… because they can. E-peen is fully extended with coders trying to develop a reputation in the hacking scene. The majority of websites and services are exploited simply because they can be. Often with a fitting excuse being created after the fact.

If your device is connected to the internet it will, at some point, be the target of an attack. Successful or not. Computers are constantly scanning the internet on the lookout for vulnerabilities. Finding exploitable websites is usually just a case of firing up your chosen scanner with a target domain, I.P. and/or I.P. range. Anyone with even basic knowledge of coding could attack hundreds of thousands of websites, computers and mobile devices using supposed “white hat” tools such as MetaSploit, w3af, sqlmap, and BeEF. Most people don’t, but the few that do can be real dicks. The “internet of things” is close, but worrying.

So we’ve built the tension. The end is nigh. Hack all the things is no longer just a meme. What could I do if I wanted to become less of a target? Well, there are a few simple steps anyone can take that can greatly reduce the risk of becoming yet another hacking statistic.

Secure all the things!

Top 5 lists are for losers. So this is a lenthy top 4 list. Because all hacks fit into 4 categories. Insult me in the comments if you disagree.

Avoiding the vast majority of exploits is actually pretty simple but, as it’s a change of habit, can take some prompting. Most of the tips below offer ways to help prevent you getting hacked, which shouldn’t be ignored. I believe it’s far easier to complete an update than it is to restore files corrupted by CryptoLocker or something similar.

• Awareness
• Updates
• Password management
• Resource abuse (Ddos, FXP, etc)

Awareness

The internet is inherently insecure. It is relativly easy to pretend to be anyone, send emails as another person or pretend to be another website. If you are not careful you could enter your Facebook details into a malicious website. The biggest step required to become less of a target for hackers is simple diligence.

Internet diligence really boils down to one thing: If you click links in emails or on social media, check the website you are visiting is the correct website by confirming the URL is as expected. An extremely long link or shortening services such as bit.ly could be used to cloak malicious data.

It sounds simple but is easy to overlook as the evolution of social media requires clicking on links from unknown sources. Just remember to check the site if it asks you for login details. Recently, I was almost phished by an advert in Google’s Adsense which used a cloaked URL… It happens to the best of us

Updates

The best way to mitigate exploitation is to simply keep your operating system and applications up-to-date. I know it can be time consuming and a bit of a pain, but it is the single best way to pro-actively prevent becoming a victim. Patches for most major software are released pretty quickly after disclosure and updating usually just means clicking a button.

A list of common updates should include:

• Operating system updates (Windows, Mac, Linux, Mobile)
• Server software updates (LAMP, CMSs, libraries)
• System software (Flash, Java, FTP client, etc)

It’s a short list but could include hundreds of updates. If you don’t use software, removal is recommended. Two good examples are Flash and Java. These two are among the most attacked and unused software on the internet. Many websites have abandoned Java due to the constant security issues and HTML5 has all but replaced Flash for most developers. Most modern software will update itself if set to. If it isn’t set to autoupdate, you should do it manually at least once a month.

Password Management

Having a unique password for every website is one of the best ways to prevent account hijacking. Your email password should be the most secure as it truly is the one ring to pwn them all. If someone can gain access to your email account they can easily hack any other associated account. I have recommended LastPass as a means of securely managing passwords for several years. It is free and has been audited several times with very little complaint from the security professionals I respect the most.

Which of the following two passwords is stronger, more secure, and more difficult to crack?

D0g.....................
PrXyc.N(n4k77#L!eVdAfp9

You may expect that this is a trick question and you’d be right. The first of the two passwords is actually stronger. Password cracking works on a binary basis – Is the password correct? Yes / No. So each character added will effectively double the entropy. Password entropy can be counter-intuitive with length being the main factor.

Interested in how passwords really work? I suggest you read Steve Gibson’s Password Haystacks if you are in to really techy stuff… It’s a great read!

The idea is simple: think of a long password that is easy to remember but contains upper and lower case characters with punctuation. Then simply remember how many dots, dollar signs or other symbol you have at the beginning or end for each site. Security through obscurity isn’t a recommended technique but it’s better than nothing!

Aside: an easy way to check if a website is handling passwords properly is to reset it. If your password is sent to you, in an email or text, they probably aren’t hashing the data correctly and your password could be at risk. Any secure database handling of passwords will implement a one way hashing process to ensure the only person that can know your password is you.

Resource Abuse (Ddos, FXP, etc)

A hacked server or device can cause many issues. Resource abuse is usually the result of ignoring the above. Often an affect of using a default password, outdated software, or account compromise. For this reason I’m going to include a typical attack scenario from around 5 years ago. This is an offensive way by which folders can be created to obfuscate their true contents. Inspecting, editing, deleting such folders is difficult unless you know the attack vector. It is now a well known and secured vector making it essentially pointless (no copy/pasta here skidz).

FXP is a very little-known form of hacking. It refers to File Transfer Protocol. FXP, although almost dead, is analogous to many hacking techniques. It leverages exploits to distribute illegal material. Hackers target FTP servers (or websites to setup services such as FTP, Torrents, Usenet, etc) to store illegal warez. And even worse on hacked servers. FXP was incorporated into the wider spectrum of “collaborative resource management” around 5 years ago, but the logic remains true. If you can hack it some one will then find a reason to justify it after the fact.

Assumptions: we have found a public server in which we can create folders, upload, and download.

First we will create a folder called…

/.ÿÿcom1 ÿ%d ÿ  /

This will tell us a lot about the server. The folder created could be shown a number of ways, depending on the server setup. ÿ is a Unix escape character so will try to execute the return command when encountered. This depends on setup. It essentially tells the server to return to the last folder, confusing both server and client as to the folder trying to be entered. %d is one of many command tokens which will try to force a text prompt in some clients/servers. This will usually disrupt further information gathering. There are several other techniques but you get the idea. Forgetting to filter one character can lead to a lot more than you may think. Sneaky people will stuff hacked publci servers with dodgy contents.

Below are variants of the ending folder name with a brief explanation:

/.ÿÿcom1 ÿ%d ÿ  / < Folder name as entered. Not vulnerable.
/.ÿÿcom1ÿ%dÿ/ < Enter by clicking? Not vulnerable.
/com1%d  / < ÿ obfuscates previous character. Vulnerable.
/.ÿÿcom1 ÿ ÿ  / < Command token executed. Vulnerable.
/com1%d  / < Path obfuscated. Vulnerable.
/.ÿcom1    / < Command token executed and path obfuscated. Vulnerable.

This may mean nothing to the average person. To a hacker it means they can distribute any file they choose with little chance it will get discovered. The combination of possible folder names is almost infinite which makes automated detection almost impossible. A single character can often lead to total security failure. Append-Apostrophe-Sec… I mean LulzSec used a simple apostrophe to “pwn” some of the biggest government agencies on the plant. Sabu was only caught because he accessed IRC using his real IP. He also ordered car parts to his home address. Not all hackers are that stupid.

/ Rant

I can understand why people don’t care about security, or getting hacked. I kind of bored myself writing this ~1800 word article. Then and had to considerably reduce it. I can understand why companies don’t spend more on security. It seems pointless until you get hacked and have to recover every email ever sent to/from your company.

The post How to: not get hacked appeared first on Abeon Tech.

The malicious code can be overflown to the homepage fairly easily. Almost XSS code can be used.

I would now consider this as a serious exploit and suggest fixing this bug A.S.A.P (Edit: This exploit was fixed. Keep AV Arcade up-to-date!)

The Fix

• Backup then open yoursite.com/register.php
• Find:
  $info2 = htmlspecialchars($info); 1 $info2 = htmlspecialchars($info);
• Add below:
  $username = htmlspecialchars($username); 1 $username = htmlspecialchars($username);
• Backup then open yoursite.com/admin/manage_users.php
• Find:
  while($row = mysql_fetch_array($sql)){ 1 while($row = mysql_fetch_array($sql)){
• Add below:
  $username = htmlspecialchars($username); 1 $username = htmlspecialchars($username);
• Save and upload all files.
• Search your members list for any user names shown as code and delete (You could also I.P. ban them).

This function could easily be expanded for further validation. Thanks to dan20071 for letting me know about this!

The post AV Arcade XSS Exploit appeared first on Abeon Tech.

It may sound simple, but mistakes can often be made when in a rush or creating multiple accounts.

This post contains common good practice. Why not get into the habit of creating good passwords, before bad habits set in?

Do NOT:

1. Use your account name or any data that appears in your record in the password file.
2. Use any word or name that appears in any dictionary, reference or list regardless of case changes; especially do not use character strings that appear in password cracking tools’ word lists or bad password lists.
3. Phrases and slang with or without white space. Redundant with 2. See below.
4. Use any mythological, legendary, religious or fictional character, object, race, place or event. Redundant with 2.
5. Use acronyms. Redundant with 2.
6. Use alphabetic, numeric or keyboard sequences; many such sequences are included in cracking tools “word” lists. Redundant with 2.
7. Titles of books, movies, poems, essays, songs, CDs or musical compositions. Redundant with 2.
8. Vary the character sequences obtained from any of the foregoing items by any of the following methods:
   • Prepend or append symbols, punctuation marks and / or digits to a word.
   • Use words with some or all the letters reversed.
   • Use conjugations or plurals of words.
   • Use words with the vowels deleted.
   • Replace letters with like looking symbols or digits.
   • Replace digits with like looking letters or symbols

7. Use only the first or the last character in uppercase. Redundant with 2.
8. Use only vowels in uppercase. Redundant with 2.
9. Use only consonants in uppercase. Redundant with 2.
10. Use any personally related information.
11. Use anything you can imagine being collected into a list.
12. Use a publicly shown example good password.
13. Use great vanity license plates. In the future, may be redundant with 2.
14. Transliterate words from other languages.
15. Repeat any character more than once in a row.

DO:

1. Use at least 8 characters.
2. Include a digit or punctuation.
3. Use upper and lower case.
4. Choose a phrase or combination of words to make the password easier to remember.
5. May be two words separated by a non-letter non-digit.
6. May have non printing characters.
7. Use different passwords on different machines.
8. Change password regularly and don’t reuse passwords or make minor variations (incrementing a digit).

The suggestions overlap as they come from different sources. Most users and some systems will have real difficulty with non printing characters.
Personally related information Most people choose passwords that are easy to remember. One way to make passwords easy to remember is to pick passwords or parts of password that are directly related to oneself. Generally these are considered to be poor password choices.

Below is a list of all the personally related information that I have seen in passwords or in lists of what not to use in passwords. It’s listed in the order in which I think this information is most likely to be used in forming passwords:

1. One’s names and initials.
2. One’s account name.
3. Names of immediate family members.
4. Names, breeds or species of pets.
5. One’s birthday.
6. Family member’s birthdays.
7. One’s vehicle make, model, year.
8. Hobbies, interests and related words.
9. One’s job title.
10. Employer’s name.
11. Job related words.
12. Friend’s names.
13. Street numbers or names, city, county, state or zip code for home, work, family or friends.
14. Phone numbers for home, work, family or friends.
15. Social security numbers for self and immediate family.
16. License plate numbers.
17. Birthplace including street address.
18. University or college name.
19. College major.
20. High school name.
21. Student or employee ID numbers.
22. Serial numbers from consumer products.

The post Password Security Tips appeared first on Abeon Tech.