Lopikamuna

vBulletin 4 2 3 ForumRunner SQL Injection ################################################################################################## #Exploit Title : vBulletin <= 4.2.3 SQL Injection (CVE-2016-6195) #Author        : Manish Kishan Tanwar AKA error1046 (https://twitter.com/IndiShell1046) #Date          : 25/08/2015 #Love to       : zero cool,Team indishell,Mannu,Viki,Hardeep Singh,Jagriti,Kishan Singh and ritu rathi #Tested At  : Indishell Lab(originally developed by Dantalion) ##################################################################################################     //////////////////////// /// Overview: ////////////////////////     VBulletin version 3.6.0 through 4.2.3 are vulnerable to SQL injection vulnerability in vBulletin core forumrunner addon. Vulnerability was analized and documented by Dantalion (https://enumerated.wordpre...

vCenter SQL maintenance plan As vCenter becomes more integrated with a number of products and services, the need to keep it protected from failure becomes greater. Often times I am asked on ways to protect vCenter, but in my opinion there are two pieces to this question: the application (vCenter Server) and the database. Protecting the application isn�t all that difficult � just using periodic clones can often be enough to solve this problem, or even a quick deployment of the application onto a blank template. To me, the more essential piece is the database. It contains a lot of information on the environment (including object annotations, which are often used by administrators to record important values). There are many solutions available to protect SQL databases, but often require additional 3rd party software (Red Gate, Veeam) or licensing (SQL Mirroring / Clustering). In my recent SQL database protection posts, I�m mostly focusing on the �free� methods to protect vCenter using wh...

Using conditionals before adding columns to a table in SQL server Working with databases is not as easy as it looks like, specially if you are working with production databases. When a database is production you need to be very careful with the changes you make, adding, removing tables, columns, changing data, etc. Once a database is in production you use incremental scripts in order to push new updates into it. These incremental scripts need to handle everything and they do not have to have any errors and must be able to run multiple times if it is needed. One thing I keep seeing in lots of incremental scripts are the lack of verification before they are executed. The other day I asked one of my developers to add one column to a table and also to write the respective incremental script and UI controller. This is what I got: ALTER TABLE [table]   ADD [column_name] VARCHAR ( 10 ) DEFAULT [defaultvalue] ; There are a couple of things i do not like about this script but one of them wa...