Mostrando entradas con la etiqueta sql. Mostrar todas las entradas
Mostrando entradas con la etiqueta sql. Mostrar todas las entradas

miércoles, 3 de septiembre de 2014

CONCATENAR USANDO FOR XML PATH Y STUFF

 En el foro de SQL SERVER se cuestiona mucho como concatenar varias filas en una sola, sobre todo esto se utiliza para evitar el uso de los cursores y es mucho más rápido, para comenzar es necesario la tabla AdventureWorks2012.
?
1
2
SELECT TOP 10 FirstName
FROM AdventureWorks2012.Person.Person

Hasta aquí no hay nada, digámoslo de cierta forma, nuevo, pero para poder hacer la concatenación requerimos de la función STUFF y la clausula FOR XML utilizando el modo PATH.
La función STUFF sirve para ingresar una cadena en otra a partir de los parámetros de posición y longitud. Siendo de esta manera, el siguiente ejemplo:
?
1
2
SELECT TOP 10 FirstName, STUFF( FirstName, 3,2,'CADENA') as resultado
FROM AdventureWorks2012.Person.Person
Lo que nos arroja como resultado:
Y para que funciona FOR XML PATH, para devolver una consulta en formato XML, este es el resultado de una consulta a la base de datos AdventureWorks2012:
?
1
2
3
SELECT TOP 3 FirstName, MiddleName, LastName LastName
FROM AdventureWorks2012.Person.Person
FOR XML PATH
Y si damos click al resultado, nos muestra esto:
Si agregamos el parámetro, reemplazara el atributo de fila:
?
1
2
3
SELECT TOP 3 FirstName, MiddleName, LastName LastName
FROM AdventureWorks2012.Person.Person
FOR XML PATH('FILA')
Y que pasa si establecemos un valor vacío?:
Combinando STUFF y FOR XML PATH, podemos lograr concatenar las filas.
?
1
2
3
4
5
SELECT STUFF((
       SELECT TOP 10 ','+FirstName
       FROM AdventureWorks2012.Person.Person
       FOR XML PATH('')
),1,1, '')
Y de esta manera es posible agrupar a un nivel superior:
?
1
2
3
4
5
6
7
8
9
SELECT
       PC.Name
       ,STUFF((
             SELECT ','+name
             FROM Production.ProductSubcategory PSC
             WHERE PSC.ProductCategoryID = PC.ProductCategoryID
             FOR XML PATH('')
       ),1,1,'')
FROM Production.ProductCategory PC
Algo más complejo, observemos las tablas Sales.SpecialOffer, Sales.SpecialOfferProduct,Production.Product, la primera contiene las ofertas especiales( como su nombre lo indica), la segunda tabla contiene el detallado de los productos que por cada oferta especial y la tercera el detallado de los productos. Lo que queremos obtener es todos los productos de cada oferta especial:

Sales.SpecialOffer:
Sales.SpecialOfferProduct:
Production.Product
La consulta quedaría así:
?
1
2
3
4
5
6
7
8
9
10
SELECT SO.SpecialOfferID, SO.Description
, STUFF((
       SELECT ','+p.Name
       FROM sales.SpecialOfferProduct SOP
       INNER JOIN Production.Product P
       ON SOP.ProductID = p.ProductID
       AND SOP.SpecialOfferID = SO.SpecialOfferID
       FOR XML PATH('')
),1,1,'' ) as productos
FROM Sales.SpecialOffer SO
Una forma muy practica y mucho mejor para concatenar valores en comparación que si utilizaramos un cursor.

Espero que les sirva.

Fuente: http://chancrovsky.blogspot.com/2013/04/concatenar-usando-for-xml-path-y-stuff.html

miércoles, 6 de agosto de 2014

SQL server setup media does not support the language of the

Buenas.
Resulta que el instalador de SQL Server algunas veces arroja errores, entre ellos el que hoy venimos a ver, para solucionarlo solo basta con ir a configuración regional y cambiar el idioma a "español-españa".
Aquí un vídeo tutorial que nos ahorrar un dolor de cabeza todos aquellos que nos hemos encontrado con el mensaje de error de "SQL server setup media does not support the language of the OS or does not have ENU localized files. Use the matching language-specific SQL Server media or change the OS locale through Control Panel" al querer instalar SQL Server 2008,SQL Server 2008 R2 o SQL Server 2012 en nuestra PC.


link: http://www.youtube.com/watch?v=6ulmj-CaHXE

Para otros errores como el de requisitos mínimos para instalación se recomienda habilitar desde las características del servidor el .net framework 3.5 y luego hacer un update para instalar el SP y las actualizaciones de .net.
Saludos jadcodianos.
Fuente: http://www.taringa.net/posts/hazlo-tu-mismo/14699884/SQL-server-setup-media-does-not-support-the-language-of-the.html

Configurar SQL SERVER para acceso remoto.

Buenos días.

El día de hoy me comentaron el siguiente problema "no puedo conectarme al servidor de base de datos SQL SERVER desde otro equipo usando SQL Mannager?".

La respuesta es sencilla, Obviamente se puede conectar.

El porque no conecta después de instalado?:

Para mejorar la seguridad, no se puede obtener acceso a Motor de base de datos de las ediciones de SQL Server Developer, Express y Evaluation desde otro equipo cuando se instala inicialmente. Se debe habilitar los protocolos, configurar los puertos y configurar el Firewall de Windows para conectarse desde otros equipos.

Para mejorar la seguridad, SQL Server Express Developer y Evaluation se instalan con conectividad de red limitada. Las conexiones a Motor de base de datos se pueden realizar desde herramientas que se ejecuten en el mismo equipo, no desde otros equipos. Si tiene previsto realizar las tareas de desarrollo en el mismo equipo que Motor de base de datos, no necesita habilitar otros protocolos.

Management Studio se conectará a Motor de base de datos mediante el protocolo de memoria compartida. Este protocolo ya está habilitado.
Si tiene previsto conectarse a Motor de base de datos desde otro equipo, debe habilitar un protocolo, como TCP/IP.

Cómo habilitar conexiones TCP/IP desde otro equipo:


  1. En el menú Inicio, elija Todos los programas, Microsoft SQL Server 2012 , Herramientas de configuración y, por último, Administrador de configuración de SQL Server.
    Nota Nota
    Es posible que estén disponibles las opciones de 32 y 64 bits.
  2. En Administrador de configuración de SQL Server, expanda Configuración de red de SQL Server y, a continuación, haga clic en Protocolos de .
    La instancia predeterminada (una instancia sin nombre) aparece como MSSQLSERVER. Si ha instalado una instancia con nombre, el nombre proporcionado aparece en la lista. SQL Server 2012 Express se instala como SQLEXPRESS, a menos que se haya cambiado el nombre durante la instalación.
  3. En la lista de protocolos, haga clic con el botón secundario en el protocolo que desee habilitar (TCP/IP) y, a continuación, haga clic en Habilitar.
    Nota Nota
    Debe reiniciar el servicio SQL Server después de realizar los cambios en los protocolos de red; sin embargo, esto se completa en la siguiente tarea.
 Una captura para ayudar:


Con solo hacer esto ya tenemos acceso remoto y usando la dirección ip.

Esto también soluciona el problema de usar el nombre del equipo para acceder, ya que es posible conectar usando la dirección ip al servidor sql server.

Pruebas realizadas sobre SQL SERVER 2014.

Fuentes:
http://technet.microsoft.com/es-es/library/ms345343%28v=sql.110%29.aspx 


martes, 22 de julio de 2014

Pen Testing SQL Servers With Nmap (ingles)

The Nmap Scripting Engine has transform Nmap from a regular port scanner to a penetration testing machine.With the variety of the scripts that exists so far we can even perform a full penetration test to an SQL database without the need of any other tool.In this tutorial we will have a look in these scripts,what kind of information these extract from the database and how we can exploit the SQL server and execute system commands through Nmap.

Most SQL databases run on port 1433 so in order to discover information regarding the database we need to execute the following script:
Obtain SQL Information - Nmap
Obtain SQL Information – Nmap

So we already have the database version and the instance name.The next step is to check whether there is a weak password for authentication with the database.In order to achieve that we need to run the following nmap script which it will perform a brute force attack.
Brute Force Weak MS-SQL Accounts - Nmap
Brute Force Weak MS-SQL Accounts – Nmap

As we can see in this case we didn’t discover any credentials.If we want we can use this script with our own username and password lists in order to discover a valid database account with this command:

nmap -p1433 –script ms-sql-brute –script-args userdb=/var/usernames.txt,passdb=/var/passwords.txt

However we can always try another script which can check for the existence of null passwords on Microsoft SQL Servers.

Check For Null passwords on SA accounts - Nmap
Check For Null passwords on SA accounts – Nmap

Now we know that the sa account has not a password.We can use this information in order to connect with the database directly or to continue to execute further Nmap scripts that require valid credentials.If we want to know in which databases the sa account has access to or any other account that we have discovered we can run the ms-sql-hasdbaccess script with the following arguments:

Discover which user has access to which db - Nmap
Discover which user has access to which db – Nmap

We can even query the Microsoft SQL Server via Nmap in order to obtain the database tables.
List Tables - Nmap
List Tables – Nmap

In 2000 version of SQL Server xp_cmdshell is enabled by default so we can even execute operating system commands through Nmap scripts as it can be seen in the image below:

Run OS command via xp_cmdshell - Nmap
Run OS command via xp_cmdshell – Nmap

Run net users via xp_cmdshell - Nmap
Run net users via xp_cmdshell – Nmap

Last but not least we can run a script to extract the database password hashes for cracking with tools like john the ripper.

Dump MS-SQL hashes - Nmap
Dump MS-SQL hashes – Nmap


In this case we didn’t have any hashes because there was only one account on the database the sa which has null password.

Fuente: http://pentestlab.wordpress.com/2013/04/21/pen-testing-sql-servers-with-nmap/

Penetration Testing SQL Servers (ingles)

It is quite common to discover a Microsoft SQL server in a penetration testing engagement as many companies are having Windows environments. SQL servers are generally running on port 1433 but it can be found and in other ports as well.Since it’s a very popular database we have to know all the step and methods in order to conduct the database assessment efficiently.In this article we will examine step by step how we can perform penetration tests against SQL Servers.

Recon

As we have already mentioned SQL servers are running by default on port 1433.However in some cases they can be found on a different port.So how can we identify the existence of an SQL server on a system?The answer is through the SQL server browser service which runs on UDP port 1434.This service can provide us with the instance name,the version number and the exact port that the database is running.A UDP Nmap scan must be performed in order to discover these information as it can be seen from the next image:
SQL Server Discovery - Nmap
SQL Server Discovery – Nmap

Another tool that can help us to discover SQL servers on remote hosts is the metasploit module mssql_ping.The information that we can obtain from this module is actually the same as the Nmap UDP scan that we executed before but it will also returns and the pipe name.
Metasploit - mssql ping
Metasploit – mssql ping

From the version we can understand also that the database is SQL 2000.If it was the 9th version then the database would be 2005 etc.

Credentials

This is the most important part as if we manage to obtain somehow valid credentials we can connect directly through the database and we can start to extract data.Some common locations that we can discover database credentials are the following:
  • XML files (looking for connection strings)
  • SQL Injection (requires an application vulnerable to SQL injection that is running with high privileges)
  • Windows Shares
  • Developer Workstations (in case that we compromise them)
If we don’t have already discovered an account on some of the above locations then we can try a brute force attack.Metasploit Framework contains a module specifically for this task that can assist us.
auxiliary/scanner/mssql/mssql_login
Brute Forcing MS SQL Passwords with Metasploit
Brute Forcing MS SQL Passwords with Metasploit

As we have seen from the results above we have discovered that the SQL Server doesn’t contain a password for the sa account.It is also very common for database administrators to use as a password the username or any other simple passwords like company’s name etc.

Post Exploitation

Now that we have the credentials we can use a variety of other metasploit modules that will allow us to discover more information about the database.The first module is the mssql_enum which it will perform multiple security checks against the SQL Server.These checks can assist us to conduct further post exploitation activities against the database.The next three images are showing what kind of information we can harvest from this module:
MS-SQL Enumeration
MS-SQL Enumeration

MS-SQL Enum 2
MS-SQL Enumeration 2

MS-SQL Enumeration 3
MS-SQL Enumeration 3

From the above output we can spot the following:
  • xp_cmdshell is enabled
  • sa account doesn’t contain a password
  • System and Windows Logins
  • Privilege that the database server is running
  • Databases that exist
The fact that the xp_cmdshell is enabled means that we can execute commands on the remote system through the SQL Server.Of course the first thing that comes to our minds is to add another account and to put it on the local administrator group in order to have permanent access to the box.Metasploit framework has an appropriate module for this work.Below is a sample of the usage of this module.
xp_cmdshell - Metasploit
xp_cmdshell – Metasploit

In case that we want to connect to the database directly and to execute SQL commands we can use either a client like osql or another metasploit module the mssql_sql.
Executing Database Commands
Executing Database Commands

With this module we can extract more information about the database tables and records.

Conclusion

The purpose of this article is to provide an overview to the penetration tester about common tools and methods when he has to assess Microsoft SQL servers.It is also very important to know the structure of an SQL server and what we have to look for as a penetration tester so it is recommended to create our own SQL database in our lab in order to understand better how it works and what these modules are doing exactly when interacting with the database.

Fuente: http://pentestlab.wordpress.com/2013/03/18/penetration-testing-sql-servers/

viernes, 13 de junio de 2014

SQLi utilizando método POST con SQLMap

En esta entrada breve y simple, se detallaran los pasos que realizaremos cuando necesitemos explotar una vulnerabilidad de Sql Injection, que mayormente se encuentran en algunos servidores basados en SQL Server y Oracle. Estas vulnerabilidades son típicas en los LOGIN'S Administrativos, ya que como debemos de saber,  que cuando ingresamos el usuario y password estos datos se envían a través del método POST, por lo tanto puede existir la posibilidad de que al ingresar datos falsos o algunos bypasses, esta nos pueda mostrar algún error que nos permita identificar la vulnerabilidad, por tanto se puede explotar automatizadamente utilizando SQLMAP ejecutando comandos para enviar la petición en POST y no en GET como se "acostumbra".
Si no me explique bien, pues al buen entendedor pocas palabras!!! entonces sin mas rodeos, vamos a la acción!
Tenemos un LOGIN en ASP, en la cual no tenemos los datos correctos ni nada por el estilo, ya que no hemos encontrado ningún tipo de vulnerabilidad en el servidor que nos brinde estos datos, por tanto como somos curiosos e inteligentes empezamos a probar datos falsos y algunos bypasses como el famosillo ' or '1'='1 como se muestra en la imagen siguiente:
Después de haber colocado este bypass, tenemos la posibilidad de que el servidor nos muestre algún tipo de vulnerabilidad o el error que nos permita identificar si es vulnerable a SQL Injection, tanto así que si el servidor se encuentra bajo ASP esta nos puede mostrar el error "Microsoft OLE DB Provider for ODBC Drivers error '80040e14'", si esto llega a suceder, corremos la suerte de poder explotar esta vulnerabilidad. En este caso después de haber colocado dicho bypass, el servidor nos devuelve el siguiente error:

Al visualizar esta vulnerabilidad, somos consciente que se puede explotar manualmente o automatizadamente, para así obtener los datos que nos permita logearnos de una manera correcta al servidor.
Ahora, para seguir probando si el LOGIN tiene algún otro tipo de vulnerabilidad, regresamos al form y dejamos en blanco el usuario y clave y le cliqueamos en Conectar, la cual el servidor nos muestra lo siguiente:





¿Algo raro cierto? ¿Por que? ... Este LOGIN nos demuestra que las peticiones no están validadas, quiere decir que si colocamos algún bypass, esta nos muestra una vulnerabilidad, como también si dejamos los form en blanco y cliqueamos en conectar, esta nos permite saltarnos del login. 
Bien, después de haber llegado a unas pequeñas conclusiones sobre que el servidor tiene una vulnerabilidad en el login y que las peticiones no están validadas, procederemos a utilizar el Live HTTP Headers para así ver las cabeceras del login al momento que cliqueemos en Conectar.
En este caso después de haber colocado el Live HTTP Headers a la escucha de lo que pasa por el servidor mientras cliqueamos en Conectar dejando todo el blanco, esta nos devuelve lo siguiente:




Hemos obtenido 3 datos muy importantes! las cuales son:

  • http://www.uap.edu.pe/intranet/logon2.asp
  • POST /intranet/logon2.asp HTTP/1.1
  • usuario=&pw=&user=07&B7=++Conectar++

La primera es posiblemente la URL Vulnerable, la segunda nos indica que la variable es POST y el ultimo, los parámetros que posiblemente son vulnerables.

Entonces procederemos a explotar la vulnerabilidad automatizadamente que se encuentra en el LOGIN, utilizando SQLMAP y ejecutando el siguiente comando basándonos en los datos obtenidos por el Live HTTP Headers.
  • ./sqlmap.py -u "http://www.uap.edu.pe/intranet/logon2.asp" --data="usuario=&pw=&user=07&B7=++Conectar++" -p "usuario" --level=5 --risk=5 --dbs
Después de que la herramienta termine de auditar el servidor, esta detectara que el parámetro POST "usuario" es vulnerable, tal cual se muestra en la siguiente imagen:
A partir de allí, ya sabemos que dicho LOGIN es realmente vulnerable y lo hemos explotado con total satisfacción obteniendo así toda la base de datos del servidor.

Ahora si! con esta DB obtendremos los respectivos datos reales para poder logearnos satisfactoriamente en el LOGIN que tanto deseamos ;)
Espero les sirva.
Saludos. 

Fuente: http://www.blackploit.com/2013/03/sqli-utilizando-metodo-post-con-sqlmap.html

jueves, 29 de mayo de 2014

Backups y su restauración en SQL Server

Un requerimiento y una tarea administrativa frecuente, es tener la posibilidad de crear backups para una eventual restauración a un estado anterior del proyecto Bizagi.

Los backups en este tipo de tareas se crean principalmente como una medida de contingencia, o también para mover o copiar un proyecto en etapa de desarrollo.
Todo esto es muy sencillo para la solución Bizagi dado que es orientado al modelo.

Cuando se usa una Base de datos SQL Server, las tareas de crear backups y restaurarlos, se realizan a través de SQL Server Management Studio.

note_pin
La restauración de backups debe usarse sólo para migrar una base de datos o como medida de contingencia para restaurar el estado anterior de un mismo ambiente. Es decir que un backup del ambiente de desarrollo sólo debe ser restaurado en el ambiente de desarrollo. Para crear ambientes, se debe usar la funcionalidad del Deployment de Bizagi.

En esta sección ilustramos cómo realizar backups y cómo restaurarlos para proyectos de Bizagi que usen Microsoft SQL Server.
Si su proyecto utiliza Oracle, consulte Export e Import de Oracle.


Prerrequisitos

Para crear un backup o restaurarlo, se requiere:

1. Tener instalado Microsoft SQL Server Management Studio para la conexión a la instancia de Base de datos (2005, 2008, 2008 R2).
Mas información en enlaces externos de Microsoft: http://www.microsoft.com/en-us/download/details.aspx?id=22985.

2. Tener instalada una misma versión e intercalación (collation) de SQL en los Servidores involucrados (donde se va a restaurar el backup y de donde se obtuvo el backup).

SQLServer00_Properties



Consideraciones adicionales

Si usted está migrando un proyecto en ambiente de desarrollo a un servidor diferente y desea conservar las instancias de Proceso (casos), tenga en cuenta que los adjuntos de estos casos no estarán dentro de la información del backup.
Por lo tanto en el hipotético escenario en el que desee trasladar los casos de un ambiente de desarrollo, deberá considerar mover también la ubicación de éstos (sea el Servidor BPM, un Servidor diferente de archivos, o un ECM).

 

Crear un Backup

Para crear un backup de su Base de datos:

1. Autentíquese en su instancia de SQL Server (login) a través de SQL Server Management Studio.

SQLServer01_Login

2. Ubique la Base de datos y de clic derecho sobre ésta. Seleccione la opción Backup...  desde las tareas:

SQLServer02_Backup

3. Especifque que el backup se realice completo (modo FULL).

SQLServer03_BackupSettings

Nótese que debe seleccionar una ruta válidad para almacenar el archivo resultante (.bak).
Si no desea utilizar la ruta por defecto, puede navegar y seleccionar otro directorio. Si utiliza otro directorio, asegúrese de contar con los permisos de escritura sobre él.


SQLServer04_BackupPath

4.  Haga clic en OK cuando la operación se haya completado:

SQLServer05_BackupOK

Importante

Nótese que podrá crear 2 tipos básicos de Backups:
Full Backup: Esta opción crea un backup completo (de toda la Base de datos). Con esta opción se limpian las transacciones almacenadas en el log de transacciones.
Differential Backup: Es un backup diferencial, donde se almacena la parte que ha cambiado con respecto al último backup completo (Full Backup). El log de transacciones también es truncado.

Para restaurar un proyecto de Bizagi a su último estado por medio de un backup, se recomienda crear y utilizar los backups en modo Full backup.
Por ejemplo, los backups automáticos que toma Bizagi los realiza de esta manera.

RecommendationsforA1

Si desea programar Backups, de manera que se generen de manera automática, puede revisar otros enlaces externos como http://support.microsoft.com/kb/930615.


Restaurar un Backup


Antes de comenzar

Antes de restaurar un backup en una base de datos en uso, asegúrese que no hayan conexiones activas (requisito de la restauración).

Si su proyecto está en Bizagi Enterprise .NET o Bizagi Xpress, tenga en cuenta que el servicio del Programador (Scheduler) muy probablemente tendrá una conexión a la base de datos.
Por lo tanto, deberá previamente detener este servicio.
Puede detener el Programador por medio de Bizagi Management Console:

SQLServer06_RestoreScheduler

Si su proyecto está en Bizagi Enterprise JEE, el Programdor debe detenerse desde el Servidor de aplicaciones JEE.


Restauración

Una vez que garantice que no hay conexiones activas (la Base de datos donde se va a restaurar un backup no está en uso), restaure un backup con los siguientes pasos:

1. Autentíquese en su instancia de SQL Server (login) a través de SQL Server Management Studio.

SQLServer01_Login

2. Ubique la Base de datos y de clic derecho sobre ésta. Seleccione la opción de Restaurar -> Base de datos:

SQLServer07_Restore

3.  Especifique que la Base de datos será restaurada desde un dispositivo.
Navegue hasta seleccionar el archivo .bak de origen:

SQLServer08_RestoreDevice


SQLServer09_RestoreDeviceBak


note_pin
Tenga en cuenta que SQL Server mantiene la compatibilidad hacia atrás. Esto significa que un backup de SQL 2005 o SQL 2008 puede restaurarse dentro de una instancia SQL 2008 R2, pero no en sentido contrario (un backup generado no podrá restaurarse en una instancia con una versión menos reciente).

4. Marque el archivo con la opción de Restaurar:

SQLServer10_RestoreCheck

5. Vaya al tab de Opciones, y marque la opción de Sobrescritura (Overwrite the existing database).

SQLServer11_Options

Asegúrese de seleccionar el destino de los archivos usados por la Base de datos (.dat y .log).

SQLServer12_dat

Nótese que estos archivos se ubican por defecto en la siguiente ruta:
"C:\Bizagi\[edición_bizagi]\Projects\[su_proyecto]\Database\", si el Servidor de Base de datos es el mismo Servidor BPM (el proyecto usa una Base de datos local).
En la ruta de la instancia SQL Server (por defecto "C:\Program Files (x86)\Microsoft SQL Server\[instancia]\MSSQL\Data\"), si el Servidor de Base de datos no es el mismo Servidor BPM.

6. Haga clic en OK cuando la operación de restauración se haya completado.

SQLServer13_RestoreOK


note_pin
Después de restaurar un backup en un proyecto de Bizagi que utilice IIS (Bizagi Enterprise .NET o Bizagi Xpress), se debe refrescar la memoria caché del servidor Web.
Para ello, se recomienda ejecutar un IISReset.


7. Asegúrese de iniciar de nuevo los servicios que haya detenido antes (más específicamente, el servicio del Programador).
Este paso aplica para Bizagi Enterprise .NET y Bizagi Xpress.

Si su proyecto utiliza Bizagi Enterprise JEE, entonces al iniciar el Servidor de aplicaciones JEE, se iniciará automáticamente el Programador.

Fuente: http://help.bizagi.com/bpmsuite/es/index.html?backups_restaurar_sql_server.htm