miércoles, 24 de marzo de 2021

Words are not the price for your flag

0 comentarios

 Well, I was fine doing this room (https://tryhackme.com/room/linuxagency) until I faced the challenge for mission25 flag.

 We have a binary file named bribe and the clue says:

mission24@linuxagency: ~$ ./bribe

There is a guy who is smuggling flags

Bribe this guy to get the flag

Put some money in his pocket to get the flag


Words are not the price for your flag

Give Me money Man!!!


It doesn't say too much information at the first glance, so I tried many options to find the flag but nothing worked. The hint says "send money to other country" in the THM room for that mission.


TBH I tried some writeups over there only for that mission but none of them had the right answer, at least this day the answer weren't in the way other found it, so I decided to try harder (these writeups for mission25 password said that it is in .viminfo file).


Then I used the strings command ant tried to understand what is inside, and I saw things like:

AWAVI

AUATL

[]A\A]A^A_

pocket  

money

Here ya go!!!

Don't tell police about the deal man ;)

init    (personal note, look at this)

There is a guy who is smuggling flags

Bribe this guy to get the flag

Put some money in his pocket to get the flag

export init=abc (another personal note, look at this too)

Money

MONEY

Words are not the price for your flag

Give Me money Man!!!

;*3$"

GCC: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0


The "personal notes" are not part of the strings command's output, so I suggest to put attention on that because that is the way how to solve it.

So I tried to change the value of init with export command and when I did that the message changed to something shorter:

Words are not the price for your flag.

Give Me money Man!!!

Look how I beautifully failed... lol


Nothing worked but something told me that I was near of the solution, so after trying many values I read carefully the strings command output and noticed 2 strings: money and pocket.

As it said in the clue originally: Put some money in his pocket to get the flag.

When I did: export (look at image below) that gave me the flag when I ran again the ./bribe binary


Takeways: Try to understand what you have in front before to just copy and paste the answers, in real life scnearios there is no chance to look for flags. In this case, the behavior of bribe binary depended of the value of the existence and value from pocket variable. Suggestion: reading more about GNU/Linux basics like env, set, export commands. Try to get comfortable with the use of the most used Operating System in the world (I bet some people don't realize where a variation of GNU/Linux is used).


Bytes & C ya!




Read more ►

viernes, 5 de marzo de 2021

How to change docker root directory to a new location

0 comentarios

 


Recently had notifications about lower space in / so, that space was used by docker images I've downloaded recently.

Because I have partitioned the disk in /, /home and other partitions, obviously /home has much more space than /.

Searching some information about this I used two solutions I've read. One for save new images in a new location and the other one to move the current downloaded images.

To change the place where new images will be downloaded:

We need to know where currently are saved, we have to run:

docker info


This can be changed editing the /lib/systemd/system/docker.service file.

sudo nano /lib/systemd/system/docker.service

Edit the line starting with ExecStart and add this -g /path/to/your/new/location

For example, if it's something like this:

ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock

Change it to (for example in my personal case):

ExecStart=/usr/bin/dockerd -g /home/gamliel/containers -H fd:// --containerd=/run/containerd/containerd.sock

Save the file and restart the daemon:

sudo service docker restart

When I restarted the service showed me a warning:

Warning: The unit file, source configuration file or drop-ins of docker.service changed on disk. Run 'systemctl daemon-reload' to reload units.

But it provides the solution, so I ran:

sudo systemctl daemon-reload

And everything came fine... I decide restart again the service to confirm zero errors/warnings and was fine.

sudo service docker restart

Now, if I run docker info command this is the output regarding to the location where docker images will be downloaded:


Well, everything is fine changing the Docker Root Dir to a new location, now it's time to move the current images to the new location to give more free space to /.

Step 1. Stop docker daemon: sudo /etc/init.d/docker stop

Step 2. Make sure that there are no docker related processes: ps aux | grep docker

Step 3. Move the contents of /var/lib/docker to your new location: sudo mv /var/lib/docker /home/gamliel/containers

Step 4. Start docker daemon: sudo /etc/init.d/docker start


Where I read about moving the content to the new location says something to create a symlink but I skip that step because previously I changed where the new images will be downloaded.

That's all, thanks for reading my personal notes about what worked for me.

Sources where I found both solutions:
1. https://hsadanuwan.medium.com/how-to-change-docker-default-data-directory-f884dac76c1f
2. https://www.crybit.com/change-default-data-image-directory-docker/

Bai.

UPDATE 20210307: After moving docker root directory to another one and changing the location in order to appear the right one when I run docker info everything was fine, 2 days after when I wanted to download other docker images (CodeIgniter) and listed the images with docker images just the CodeIgniter image appeared in the list, so I searched how to fix this and found another articles but this one https://www.guguweb.com/2019/02/07/how-to-move-docker-data-directory-to-another-location-on-ubuntu/ fixed the issue. Kudos to Augusto. (Si vienes por aqui, Augusto... Gracias compadre! :D)

The solution was:

1. Stop docker service with: sudo service docker stop

2. Create a file named daemon.json inside of /etc/docker with: sudo nano /etc/docker/daemon.json

3. Paste this inside that new added file:

{ 
   "data-root": "/path/to/your/docker" 
}

where /path/to/your/docker is the directory where you will move the content of /var/lib/docker

4. In the cited article says this way how to copy the current data to the desired new location:

sudo rsync -aP /var/lib/docker/ /path/to/your/docker

Despite that in the last cited article (the step that made all work fine again) says that you have to rename the old docker directory, in the below steps I did before I moved the content so it wasn't necessary for me.

5. Restart the docker daemon with: sudo service docker restart

6. Test. I tested trying to list the images with docker images and with docker ps -a and everything is fine.

Hope the update saves time to anyone that could stumble with this blogpost. I've not posted how to install docker on Debian 10 because there are plenty of good articles over there that is easy to follow, but decided to post about this because I faced the issue that no enough space on disk ("/").




Read more ►

martes, 3 de septiembre de 2019

Enlaces simbolicos y VMWare WRKST 15

0 comentarios
Estos enlaces simbolicos son necesarios despues de instalar los linux-headers-$(uname -r) con el proposito de llenar los requisitos para instalar VMware Workstation 15.1 Pro | 14 May 2019 | Build 13591040 (otros paquetes instalados fueron gcc-8, build-essential):

cd /lib/modules/$(uname -r)/build/include/linux
sudo ln -s ../generated/utsrelease.h
sudo ln -s ../generated/autoconf.h
sudo ln -s ../generated/uapi/linux/version.h
Fuente de la informacion: askubuntu.com

Tambien encontre esta imagen, no se que tal :(


Read more ►

miércoles, 15 de febrero de 2017

Códigos de Estado HTTP Requests

0 comentarios

 Gracias a: HTTP Status Codes

Informational 1xx

The 1xx set of status codes indicates a conditional response, containing only the Status-Line and web headers that are optional, and this function is terminated by an empty line of code. However, there are no required site headers for this class of 10 status code. Since HTTP/1.0 did not define any 1xx status codes, servers can not send a 1xx response to an HTTP/1.0 client unless it has preexisting experimental conditions for testing purposes.
A client has to be prepared to accept more than one 1xx status responses ahead of a normal response, even if the client did not expect a 100 (also know as continue) status message. For unexpected 1xx status responses, they might be ignored by a user agent.
Proxies are required to forward 1xx client responses, unless the connection between the applicable proxy and the client has been closed, or unless the proxy itself requested the generation of the 1xx response. (As an example, a proxy may add a "Expect: 100-continue" field when it forwards the request, and then it needs not forward the applicable 100 (Continue) response(s).)

100 Continue

The client should continue on with the request being made. This temporary response is used to alert the client that the beginning part of the request has been considered and has not yet been refused by the server. The client should continue the process by sending the remainder of the request or, if the request has already been fully completed, then it will ignore the response. The server is required to send a final response after the request has been finalized.

101 Switching Protocols

This code means the server understands and is agrees with the received request, by means of the Upgrade message header field, for an alteration in the application protocol being used on the connection. The server will then switch these protocols to those set forth by the response's Upgrade header area directly after the blank line which it ends the 101 response.
This protocol should be switched only when it is favorable to do. As an example, switching to a more recent version of HTTP is favorable over an old version, and switching to a same-time, synchronous protocol might have its advantages when delivering resources that use these options.

Successful 2xx

The 2xx class of status codes means that the client's request was well received, fully understood, and approved.

200 OK

This request has succeeded when receiving this error code. The data returned with this ping-back depends on the method used in the original request.
Here are a few examples that might be used:
GET, which is an entity corresponding to the contacted resource and sent in the response.
HEAD, which is the entity-header fields aligning to the contacted resource and sent in the response without any content in the message's body.
POST, which is an entity detailing or contains the result of the particular action.
TRACE, which is an entity detailing the requested message as received by the end server.

201 Created

When this request is received, it means it has been completed and has produced in a fresh resource being created. This freshly created resource can be referenced by the URI(s) given back in the entity of the response received, with the most specific URI for the resource given by when is known as a Location header area. This response would be best to include an entity containing a list of resource details and applicable locations from which the user or corresponding user agent can choose the closest one. This special entity layout is directed by the media type received in the Content-Type header area. The beginning server needs to always create the resource before returning this 201 status code. If this action can't be executed at that time, then the server would be best to respond with a 202 (or accepted) response instead.
A 201 response can also contain an ETag response header area, meaning the current value of the entity tag for the requested variable just made.

202 Accepted

This code states that the request has been accepted for processing, but the processing has not yet been finalized. This request may or may not be eventually acted upon, as it possibly may be disallowed when the processing actually starts. There is no method for re-sending a status code from an asynchronous option as this.
This 202 response is meaningfully uncommitted. The purpose of the code is to permit a server to accept a request for a different process (such as batch files that run once a day) without demanding that the user's connection to the server remains active until the process is finalized. The entity returned with the response should also include an indicator of the request's current status and either a pointer to a status alert or another quote of when the user can expect the request to be completed.

203 Non-Authoritative Information

The returned meta data in this entity-header is not the final set as available from the beginning server, but rather it is pulled from a local or a third party version. This set presented might be a subset or even a superset of the original copy. As an example, including local annotation details about a resource might result in a superset of the meta data known by the original server. The use of this response code is not a requirement and is suited when the response would otherwise be a 200 (OK) code.

204 No Content

This means the server has completed what has been requested of it, but does not need to return an entity-body, and might want to return updated meta data. Such a response might also include new or updated meta data in the form of entity-headers, which if present should be attached with the requested variable.
However, if the client is a user agent, it shouldn't change the document's view from that which caused the request to be sent. The response is mainly intended to allow input for actions to take place without causing alteration to the user agent's active view, however any new or updated meta data would be best applied to the document currently in the user agent's current window.
The 204 response is not permitted to include a message-body, and the results are always ended by the first empty line after the header fields.

205 Reset Content

This means the server has completed the request and the user agent would be best to reset the document view which caused the request to be sent in the first place. This response is mainly intended to allow input for actions to take place via user input, followed by an emptying of the form in which the input is given so that the user can easily start another input action. The response would be best not to include an entity at this point.

206 Partial Content

This code states that the server has completed the partial GET request for a resource. The request is required to include a Range header area (section 14.35) stating the desired range, and can optionally have included an If-Range header field to make the request conditional.
The response MUST include the following header fields:
- Either a Content-Range header field (section 14.16) indicating the range included with this response, or a multipart/byte-range
  Content-Type including Content-Range fields for each part. If a Content-Length header field is present in the response, its value
  must match the actual number of OCTETs transmitted in the message-body.
- Date
- ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request
- Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant
If this 206 response is the result of an If-Range request that used a strong cache validation system, then the response shouldn't include any other entity-headers. If this response is the result of an If-Range request that used a weak validation system, then the response would be best not to include any other entity-headers; this helps prevent any discrepancies between the cached entity-bodies and the updated headers. The other option is the response is required to include all of the entity-headers that would have been returned with a 200 (OK) response to the same request.
A cache is required not to combine a 206 response with any other previously cached content if the ETag or Last-Modified headers did not match exactly.
A cache that does not support the Range and Content-Range headers is then required not to cache 206 (Partial) responses either.

Redirection 3xx

The 3xx redirection code indicates that further interaction is needed and has to be taken by the user agent in order to complete a request. This action required might be fulfilled by the user agent without any interaction with a user exactly as the method used in the second request is a GET or HEAD. A client is best to detect infinite redirection loops, since such loops generate network traffic for each redirection.
Please Make Note: previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that there might be clients that implement such a fixed limitation in current versions.

300 Multiple Choices

The requested resource corresponds to any one of a complete set of representations, and each with its own unique location, and agent-driven negotiation information is being provided so that the user (or user agent) can select an exact representation and redirect its request to that preferred location.
However, if it was a HEAD request, the response most always includes an entity containing a list of resource characteristics and pertinent locations from which the user or user agent can choose from that is the best fitting. This entity format is specified by the media type given in the Content-Type header area. It is important to note that depending upon the format and the ability of he user agent, the selection of the most appropriate choice can be performed with automation. Yet, this specific method does not define any standard for such automatic determination.
If the server has a preferred choice of being displayed, it most always includes the specific URI for that presentation in the Location are; user agents can use the Location area value for automatic redirection. This response is cacheable unless otherwise stated or indicated.

301 Moved Permanently

This code means the requested resource has been directed to a new permanent URI and any future inquires to this resource is advisable to use one of the returned URIs. Clients with link editing authorization should automatically re-link any references to the Request-URI to one or more of the new references returned by this server, whenever possible. This response is cacheable unless otherwise indicated.
The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response is best to contain a short hypertext note with a hyperlink to the new URI(s).
If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
Please Make Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will falsely change it into a GET request.

302 Found

This codes means the requested resource resides in a temporary location under a different URI. Since the redirection might be modified on occasion, the client for the most part will continue to use the Request-URI for future requests. This type of response is only cacheable if indicated by a Cache-Control or Expires header area.
This temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response usually contains a short hypertext note with a hyperlink to the new URI(s).
If the 302 status code is received in response to a request other than GET or HEAD, the user agent is required not to automatically redirect the request unless it can be confirmed by the user, since this could change the conditions under which the request was originally issued.
Please Make Note: RFC 1945 and RFC 2068 specify that the client is not permitted to change the method on the redirected request. However, most existing user agent installations do treat a 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make it clear without question which kind of reaction is expected of the client.

303 See Other

When receiving a 303 "Other" code, then the response to the request can be found under a different URI and is best received using a GET method on that resource. The method exists as a first source to permit the output of a POST-activated script and redirect the user agent to a predetermined resource. The new URI is not a filler reference for the original requested resource. A 303 response is required not to be cached, but the response to the second (redirected) request can be cacheable.
However, the different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response is best to contain a short hypertext note with a hyperlink to the new URI(s).
Please Make Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.

304 Not Modified

If a client has executed a conditional GET demand and access is permitted, yet the document has not been altered, then the server is best to respond with the 304 error code. This 304 response is not permitted to contain a message-body, and this means it is always terminated by the first empty line after the header fields.
The response is required to include the following in the header area:
- Date, unless its omission is required
If a "clock-less" source server obeys these rules, and proxies and clients add their own Date to any response received without one, then caches will operate correctly as specified.
- ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request
- Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant
However, if the conditional GET happen to use a strong cache validator, then the response usually does not include other entity-headers. Sometimes (for example, the conditional GET used a weak validator), the response is required not to include other entity-headers. This helps prevent errors between cached entity-bodies and updated headers.
If a 304 response determines an entity not currently cached, then the cache is required to disregard the response and repeat the request without the conditional item.
If a cache uses a received 304 response to update a cache entry, the cache is required to update the entry to reflect any new area values given in the response back.

305 Use Prox

The requested resource is required to be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is expected to repeat this single request by means of the proxy. 305 responses are required to only be generated by original servers.
Please Make Note: RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not adhering to these requirements can have large security consequences.

306 (Unused)

The 306 status code was used in a previous version of the specification, is no longer used, and the code is now reserved.

307 Temporary Redirect

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occurrences, the client is recommended to continue to use the Request-URI for future inquiries. This response is only cacheable if determined by the Cache-Control or Expires header field.
This temporary URI is best to be given by the Location area in the response. Unless the request method was HEAD, the entity of the response usually contains a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not comprehend the 307 status. This being the case, the note usually contains the data necessary for a user to repeat the original request on the new URI.
If the 307 status code is received in response to a demand other than GET or HEAD, the user agent is required not to automatically redirect the inquiry unless it can be determined by the user, since this might change the variables under which the inquiry was issued.

Client Error 4xx

The 4xx status codes class is best fitted for cases in which the client comes across as having erred. Unless when responding to a HEAD request, the server is required to posses an entity containing an break down of the error scenario, and whether it is a temporary or permanent issue. These status codes apply to any request method. User agents are required tp display any included entity to the user.
If the client is sending data, a server implementation using TCP is required to be careful to ensure that the client confirms receipt of the packet(s) included in the response, before the server closes the input connection. If the client maintains sending data to the server after the close, the server's TCP stack will send a reset packet to the client, which may delete the client's unconfimed input buffers before they can be read and interpreted by the HTTP application.

400 Bad Request

The request could not be understood by the server due to disembodied syntax. The client usually does not repeat the request without modifications.

401 Unauthorized

The request requires user authentication. The response is required to include a WWW-Authenticate header field containing a challenge applicable to the requested resource. The client can repeat the inquiry with a suitable Authorization header area. If the inquiry already includes the Authorization details, then the 401 reply determines that authorization has been rejected for those credentials. If the 401 inquiry contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user is required to be presented the entity that was given in the response, since that entity might include relevant diagnostic data.

402 Payment Required

This code is not currently in use and is reserved.

403 Forbidden

This 403 Forbidden code means the server processed the request, but is refusing to answer it. Authorization will not help and the request is best not to be repeated. If the inquiry method was not HEAD and the server wishes to make public why the request has not been fulfilled, it most likely will describe the reason for the refusal in the entity. If the server does not wish to make this data available to the client, the status code 404 (Not Found) can be used in lieu of.

404 Not Found

This code states that the server has not discovered anything matching the Request-URI. No indication is given of whether the variable is temporary or permanent. The 410 (Gone) status code most likely will be used if the server knows, through some internally edited mechanism, that an old resource is permanently not available and has no forwarding address. This status code is mostly used when the server does not wish to expose the exact means as to why the request has been refused, or when no other response is available.

405 Method Not Allowed

The code is delivered when the method specified in the Request-Line is not permitted for the resource discovered by the Request-URI. The response is required to include an Allow header pertaining a list of valid methods for the requested resource.

406 Not Acceptable

This resource code is used to identify by the request and is only capable of generating response submissions which have content characteristics that do not meet requirements according to the accept headers sent in the request.
Unless it was a HEAD request, the response most likely will include an entity containing a list of readily available entities characters and location(s) from where the user or user agent can select the one most fitting for use. The entity format is selected by the media type given in the Content-Type header field. However, depending upon the layout and the abilities of the user agent, selection of the best fitting choice can be performed automatically. However, this specification does not define any standard for such automatic selection.
Please Make Note: HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of an incoming response to determine if it is acceptable.
If the response could be not approved, a user agent will most likely fill a temporary stop receipt of more data and request the user for a confirmation of further action needed.

407 Proxy Authentication Required

The 407 Proxy Authentication Required code is very similar to a 401 (Unauthorized). It determines that the client must first confirm itself with the proxy. The proxy then is required to return a Proxy-Authenticate header field that contains a challenge applicable to the proxy for the requested information. The client can then repeat the inquiry with a suitable Proxy-Authorization header area.

408 Request Timeout

This code means that the client did not provide an inquiry within the allotted time that a server was ready to wait. The client can then repeat the request without alterations at any later time.

409 Conflict

This code means the request could not be fulfilled due to an error with the current state of the resource. This code is only permitted in situations where it is agreed that the user might be able to resolve the issue and submit the request again. The response body would be best to include enough data for the user to be familiar with the source of the issue. It would be best if the response entity would also include enough details for the user or user agent to repair the problem; yet, this scenario might not be possible and is not required to move past.
Issues are most likely to happen in response to a PUT inquiry. As an example, if version determination was being used and the entity being PUT included alterations to a resource which issue with those made by a previous (third-party) inquiry, then the server may use the 409 response to determine that it can not fulfill the request. In this case, the response entity would most likely include a list of the differences between the two versions in a format set forth by the response Content-Type.

410 Gone

When receiving this code, it means the requested resource is no longer available at the server and no forwarding address is known. This outcome is expected to be considered permanent. Clients with link editing capabilities find it best to delete any references to the Request-URI after user approval. If the server does not know, or has no ability to confirm whether or not the situation is permanent, the status code 404 (Not Found) is best to be used in lieu. This response is cacheable unless determined by other means.
The 410 response is mainly focused to assist the task of web server repair or maintenance by notifying the recipient that the resource is not available and the responsible party is aware and that the server owners desire that remote links to that resource be replaced or removed. Events like this are common for promotional campaigns and for resources belonging to those no longer working at the server's site. It is not necessary to acknowledge all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the option of the server owner.

411 Length Required

The server denies to accept the request without a specified Content- Length. The client can repeat the request if it adds a valid Content-Length header area containing the length of the message-body in the requested message.

412 Precondition Failed

This code sets preconditions given in one or more of the request-header areas determined to be false when it was tested on the server. The response code of this nature allows the client to place preconditions on the current resource meta data and thus stop the requested method from being entered onto a resource other than the one intended for receipt.

413 Request Entity Too Large

The server is denying to move forward on a request because the request entity is larger than the server is willing or able to process. The server cam close the connection to stop the client from continuing the request.
If the condition is temporary, the server usually includes a Retry- After the header field to determine that it is temporary and after what time the client cam try again.

414 Request-URI Too Long

The server is denying to service the request because the Request-URI is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present in some servers using fixed-length buffers for reading or altering the Request-URI.

415 Unsupported Media Type

The server is denying to service the inquiry because the entity of the request is in a layout not supported by the requested resource for the chosen method.

416 Requested Range Not Satisfiable

With the 416 Requested Range Not Satisfiable error code, the server most likely will return a response with this status code if a request included a Range request-header field, and none of the range-specifier values in this field overlap the current extent of the selected item, and the inquiry did not include an If-Range request-header field. (For byte-ranges, this means that the first- byte-pos of all of the byte-range-spec values were larger than the current length of the selected resource.)
When this status code is returned for a byte-range inquiry, the response most likely will include a Content-Range entity-header field declaring the current length of the selected resource. This response is required not to use the multipart/byteranges content- type.

417 Expectation Failed

This code means the expectation given in an Expect request-header field could not be determined by this server, or, if the server is a proxy, the server has enough evidence that the request could not be met by the next-hop server.

Server Error 5xx

This code shows a response status code beginning with the digit "5" to indicate in cases where the server is familiar that an error has happened, or is not capable of performing another request. Except when answering a HEAD request, the server will most likely include an entity that contains a description of the error situation, and whether it is a temporary or permanent condition. User agents will most likely display any included entity to the user. These response codes are applicable to any request method.

500 Internal Server Error

This code states that the server encountered an unexpected situation which prevented it from fulfilling the request.

501 Not Implemented

The server does not support the ability required to fulfill the request. This is the most appropriate response when the server is not familiar with the request method and is not capable of supporting it for any resource.

502 Bad Gateway

This code is received when the server, while serving as a gateway or proxy, received a non-valid response from the upstream server it accessed in attempting to fulfill the inquiry.

503 Service Unavailable

The server is currently unable to process a request due to a temporary server overloading or maintenance situation. The assumption is that this is a temporary condition which will be alleviated after short time delay. The length of the delay can be indicated in a Retry-After header. If no Retry-After is given, the client will most likely handle the response as it would for a 500 response.
Please Make Note: The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish to simply refuse the connection.

504 Gateway Timeout

When the 504 Gateway Timeout server code is received while acting as a gateway or proxy, it means that it did not receive an adequate response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (like DNS) that it needed to access in order to complete the request.
Please Make Note: Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out.

505 HTTP Version Not Supported

This means the server does not support, or will not support, the HTTP protocol version that was used in the request. The server is also indicating that it is unable or unwilling to complete the transaction using the same major version as the client requesting it other than with this error message. The response will most likely contain an entity describing why that version is not supported and what other protocols are supported by the server.
Read more ►

domingo, 12 de febrero de 2017

Imagenes a PDF [Debian way]

0 comentarios
Si tenemos una carpeta con imágenes y queremos hacer un archivo PDF con ellas, basta con instalar imagemagick con apt de la siguiente forma:

# apt-get install imagemagick

Luego, con el comando convert, ya como usuario sin privilegios de root:

$ convert *.jpg miAlbum.pdf

La forma "debian way" es por el instalador propio de los sistemas "Debian-like" que se hace con apt, quien tenga una distro basada en Fedora podría utilizar el comando rpm que también debería funcionar.

Si tenemos una serie de archivos numerados, por ejemplo: 01.jpg ... 25.jpg al lanzar el comando convert aparecerán en ese orden. Otra forma puede ser utilizando expresiones regulares:

$ convert [01-12].jpg miAlbum1-12.pdf

También es una alternativa.
Read more ►

lunes, 18 de abril de 2016

Actualizar la versión de Mutillidae que viene en Metasploitable2

0 comentarios
Esto respecta a cómo actualizar mutillidae en metasploitable2 a la última versión de OWASP Mutillidae II que es la 2.5.18

Metasploitable2 viene preinstalado con una versión antigua de mutillidae, la versión 2.1.19.

OWASP Mutillidae II es una aplicación web libre, Open Source, deliverada e intencionalmente muy vulnerable. Viene con 35 vulnerabilidades y desafíos, su última versión es una roca sólida.













Credito y agradecimientos a su autor  Jeremy Druin (webpwnized) creador de Mutillidae la sugerencia y actualización de Mutillidae en Metasploitable2.

Aquí está lo que se hace

1. Configurar el adaptador de red de virtualbox en modo NAT

2. Iniciar la máquina virtual Metasploitable2

3. Esto pide tener privilegios de root así que, sudo root (luego: msfadmin)

4. cd /var/www

5. ls

6. Aquí se puede ver la carpeta de mutillidae, así que debe cambiarse el nombre para mantener el contenido

    mv mutillidae mutillidae.bak

7. Se utiliza SVN para instalar el reemplazo, ir al sitio SVN de sourceforge pestaña subversion

   Digitar lo siguiente en la consola de Metasploitable2:

   svn checkout http://svn.code.sf.net/p/mutillidae/mutillidae/ mutillidae-mutillidae /var/www

8. Se descargará la versión en la carpeta mutillidae

9. Si se desea, se puede eliminar la carpeta con la versión previa

Eso es todo, cuando se dirija vía web hacia Mutillidae hacer clic en "reset database"
 
Regards
skorpinok.

Fuente: Foros de hak5.org
Read more ►

Como arreglar el problema login de Mutillidae en Metasploitable2

1 comentarios
Si alguien se ha encontrado con el siguiente problema al intentar hacer un SQLi para saltarse el login en Mutillidae en Metasploitable2:


Eso no significa que la inyección esté mala o algo ande mal con la instalación/configuración de Mutillidae, el problema de acceso radica en el nombre de la base de datos del fichero /var/www/mutillidae/config.inc

El nombre de la base de datos que tiene es 'metasploit'

Y el que debería tener es 'owasp10'

Alguien que esté jugando con ese tipo de 'jueguetes' ya debe saber que para modificar el fichero en mención debe hacerlo con privilegio de usuario root (), y para guardar las modificaciones con nano en una máquina virtual de virtualbox debe presionar ALT+CTRL+o y para salir del editor nano presionar ALT+CTRL+x

Debe ser en ese orden, teniendo presionada primero la tecla ALT, después presionar la tecla CTRL y de último la letra o (si es para guardar, Overwrite, x para salir, eXit).

Realizado los cambios y habiendo guardado ya está listo Mutillidae para jugar sin dañar a nadie.

Referencia: ColeSec.

Bytes.
Read more ►

miércoles, 6 de abril de 2016

Ejecutar Wireshark sin ser root

0 comentarios
Ya sea que nos encontremos en cualquier distribución GNU/Linux y necesitamos utilizar Wireshark para realizar alguna tarea de la materia de redes, o nos queremos involucrar en el ámbito de la seguridad informática, o sin ser tan paranoico, queremos detectar problemas que puedan estar surgiendo en NUESTRA red, Wireshark es la herramienta que necesitamos.

Así que, si estamos utilizando una distribución GNU/Linux basada en Debian solamente tenemos que hacer en línea de comandos:

apt-get install wireshark

(obviamente tiene que estar logueado como root, o si no, en su defecto, anteponga la palabra sudo antes de apt-get)

Para poder ejecutar Wireshark debemos tener permisos de root para que pueda estar la tarjeta en modo promíscuo y proseguir con la captura de paquetes, trabaja con Raw Sockets y otras lindezas de las que no entraré en detalle.

Luego de instalarlo tenemos que crear un grupo de usuarios para que un usuario sin privilegios de root (que se encuentre dentro de ese grupo) pueda ejecutar Wireshark sin problemas. Creamos el grupo:

groupadd wireshark

(El nombre del grupo, está demás decirlo, puede ser cualquier otro nombre, pero para este ejemplo y simplicidad de ubicación de las característeicas de uso sobre un programa que ofrecerá este grupo, he decidido ponerle el mismo nombre)

Ahora procedemos a agregar al usuario sin privilegios a este grupo, si por ej, el usuario a añardir a este grupo se llama "usuario07", la orden para agregarlo sería:

adduser -a -G wireshark usuario07

Ahora procedemos a cambiar de grupo y los permisos al fichero /usr/bin/dumpcap que según la información de la página del manual (man 1 dumpcap) sirve para capturar paquetes "en vivo" en el tráfico de una red y volcarlos a un fichero. Procedemos al cambio de permisos y de grupo con estas órdenes:

chmod 750 /usr/bin/dumpcap && chgrp wireshark /usr/bon/dumpcap

Ahora se le "asignarán capacidades" a dumpcap para que haga uso de las capacidades de raw sockets y pueda ser por usuarios distintos a root:

setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap

Respondiéndonos con:

#eip == Effective, Inheritable, Permitted

Para consultar lo que hace el comando setcap: man 8 setcap

Comprobamos que las características fueron otorgadas de forma satisfactoria:

getcap /usr/bin/dumpcap

Respondiéndonos con:

/usr/bin/dumpcap = cap_net_admin,cap_net_raw+eip

Para consultar lo que hace el comando getcap: man 8 getcap

Y eso es todo, ya solo basta que un usuario sin privilegios ejecute wireshark desde línea de comandos o cree un acceso directo en el menú principal.

Espero que a alguien le ayude esta información.
--Bytes
Read more ►
 

Copyright © El igloo de Tux Design by O Pregador | Blogger Theme by Blogger Template de luxo | Powered by Blogger