Leaderboard

GitHub Reinstates Youtube-DL and Puts $1M in Takedown Defense Fund November 16, 2020 by Ernesto Van der Sar GitHub has reinstated the youtube-dl repository after it concluded that the code doesn't violate the DMCA's anti-circumvention provisions. The company believes that developers should have the freedom to tinker, whether the RIAA likes it or not, and has placed $1 million into a takedown defense fund. Last month, the RIAA pulled the popular open source tool youtube-mp3 from GitHub. The music group sent a takedown notice arguing that the software violated section 1201 of the DMCA, which prevents people from bypassing technical protection measures. This enforcement action wasn’t well-received by the developer community. This included GitHub CEO Nat Friedman, who was ‘annoyed’ and personally offered his help to get the repository reinstated. This wasn’t a false promise, as youtube-dl returned today. GitHub Reinstates Youtube-dl “We are taking a stand for developers and have reinstated the youtube-dl repo. Section 1201 of the DMCA is broken and needs to be fixed. Developers should have the freedom to tinker. That’s how you get great tools like youtube-dl,” Friedman says. GitHub has reinstated the repository after some changes were made. These changes include referrals to copyrighted music, which RIAA pointed out in its claim. However, the software still allows people to download files, including music tracks, from YouTube. After a careful look at the “circumvention” allegations, GitHub now concludes that they are not valid. The company explains that it “received additional information” that allowed it “to reverse” the takedown. No DMCA Anti-Circumvention Violations “[O]ur reinstatement, based on new information that showed the project was not circumventing a technical protection measure (TPM), was inline with our values of putting developers first,” GitHub notes. This new information comes from the Electronic Frontier Foundation (EFF), which responded to the RIAA’s takedown request on behalf of the youtube-dl developers. The EFF’s letter explains in detail how the software works and stresses that there is no advanced decryption involved, as we highlighted earlier. “Youtube-dl stands in place of a Web browser and performs a similar function with respect to user-uploaded videos. Importantly, youtube-dl does not decrypt video streams that are encrypted with commercial DRM technologies, such as Widevine, that are used by subscription video sites, such as Netflix,” the letter reads. The letter helped to convince GitHub that it wrongly granted the takedown request. And since other copyright issues pointed out by the RIAA were addressed as well, the company decided to reinstate the repository. Developers First In addition, the revolt from the developer community was a clear reminder that developers should come first. As such, GitHub also announced that it will overhaul the way it handles DMCA section 1201 claims. One key change is that content won’t always be removed right away. This change doesn’t apply to regular DMCA takedown notices but to ‘circumvention’ claims specifically. From now on, these will all be manually reviewed and scrutinized by experts. “When we see it is possible to modify a project to remove allegedly infringing content, we give the owners a chance to fix problems before we take content down. If not, they can always respond to the notification disabling the repository and offer to make changes, or file a counter notice,” GitHub explains. $1M in Defense Fund The developer platform will aid developers financially as well. The company announced that it will put $1 million into a defense fund to help open source developers on GitHub protect themselves from overbroad or unwarranted DMCA Section 1201 takedown requests. In addition, it will also get more involved in the political side of things. Every three years the US Copyright Office reviews its DMCA anti-circumvention exceptions and GitHub will have its voice heard there as well. “We are also advocating specifically on the anti-circumvention provisions of the DMCA to promote developers’ freedom to build socially beneficial tools like youtube-dl,” the company notes. All in all, it’s safe to say that the RIAA’s takedown attempt has completely backfired. We previously reached out to the music group for comment on related youtube-dl issues, but this request remains unanswered. The RIAA continues to issue similar DMCA circumvention requests to other companies, including Google. These argue that YouTube rippers violate the DMCA as they bypass YouTube’s “rolling cipher.” At GitHub, those won’t work anymore. Youtube-dl Devs Are Happy Sergey, one of the youtube-dl developers, tells us that he is happy with all the support they have received from the EFF, GitHub, as well as the public at large. “EFF’s help was invaluable. We’d like to thank EFF and Mitch Stoltz personally for their incredible support and dedication. We’d also like to thank GitHub for standing up for youtube-dl and taking potential legal risks by allowing youtube-dl to keep the rolling cipher code,” he says. “We’re also grateful to all the tremendous amount of support and offers received lately (we physically were not able to respond to everyone) and all youtube-dl users,” Sergey adds. Sursa: https://torrentfreak.com/github-reinstates-youtube-dl-and-puts-1m-in-takedown-defense-fund-201116/?fbclid=IwAR0a6KNjcUtqxmGcq3wby9rV9sxoDHnwgSB83P17UhQ2fOgrPT1mFXVabnI

Poliţiştii specializaţi în combaterea criminalităţii informatice şi procurorii DIICOT efectuează, joi, patru percheziţii domiciliare la hackeri români, acuzaţi că au creat şi vândut servicii informatice de tipul "crypter", care oferă posibilitatea utilizatorilor de a modifica fişiere de tip malware, astfel încât acestea să nu fie detectate de către aplicaţiile de tip antivirus. În urma colaborării dintre Poliţia Română şi Bitdefender, au fost descoperite 3.000 de fişiere malware modificate, fişiere folosite pentru lansarea unor atacuri informatice în întreaga lume, inclusiv în România. Percheziţiile au loc în cadrul Operaţiunii "Invoke" - o investigaţie transnaţională, desfăşurată în colaborare cu FBI, cu sprijin din partea Europol şi Eurojust. Potrivit unui comunicat al DIICOT, investigaţia vizează cetăţeni români responsabili de crearea, dezvoltarea şi comercializarea unor servicii informatice de tipul "crypter". Serviciile cunoscute în mediul online sub denumirea "CyberSeal" şi "Data Protector" oferă posibilitatea utilizatorilor de a modifica fişiere de tip malware, astfel încât acestea să nu fie detectate de către aplicaţiile de tip antivirus. Cele două servicii de tip "crypter" erau comercializare în mediul online cu preţuri cuprinse între 40 şi 150 de dolari în funcţie de perioada de licenţiere. Totodată, dezvoltatorii promovau serviciile intens în mediul online şi pe platforme dedicate criminalităţii informatice, oferind utilizatorilor chiar şi tutoriale video privind funcţionalităţile acestora pentru modificarea diverselor fişiere de tip malware. În urma investigaţiilor efectuate, au putut fi identificate un număr total de aproximativ 3.000 de fişiere malware modificate prin folosirea serviciilor ilegale "CyberSeal" şi "Data Protector". Serviciile de tip "crypter" înlesnesc propagarea şi desfăşurarea atacurilor informatice, devenind astfel unelte foarte periculoase şi uşor de folosit atât pentru infractori cibernetici cu experienţă şi cunoştinţe tehnice, cât şi pentru persoane tinere ce se află la stadiul de experimente în mediul online. Activităţile de cooperare internaţională au fost desfăşurate prin intermediul programului EMPACT Cybercrime Attacks Against Information System şi cu suportul Join Action Crime Task Force (J-CAT). AGERPRES/(AS - autor: Eusebi Manolache, editor: Claudia Stănescu, editor online: Andreea Lăzăroiu) Sursa: https://www.agerpres.ro/justitie/2020/11/19/perchezitii-la-hackeri-romani-in-cadrul-operatiunii-invoke-cu-sprijinul-fbi--612643 Ce cacat? Sunt curios daca se intampla la fel daca acele programe nu erau vandute ci erau open-source. Exista o gramada de solutii publice si gratuite pentru asa ceva.

Image cisa.gov On September 30, 2020, the Cybersecurity and Infrastructure Security Agency (CISA) and the Multi-State Information Sharing and Analysis Center released a joint Ransomware Guide, which is a customer centered, one-stop resource with best practices and ways to prevent, protect and/or respond to a ransomware attack. CISA and MS-ISAC are distributing this guide to inform and enhance network defense and reduce exposure to a ransomware attack: This Ransomware Guide includes two resources: Part 1: Ransomware Prevention Best Practices Part 2: Ransomware Response Checklist Download: https://www.cisa.gov/sites/default/files/publications/CISA_MS-ISAC_Ransomware%20Guide_S508C.pdf Source

AM luat si a am citi articolul mi se pare ciudat rau deci efectiv si tu @Nytro cum ai facut SSL ripper te-ai cam incadra acolo

In teorie daca faci, vinzi, cumperi, primesti gratis un exploit care targeteaza un anumit sistem informatc, risti sa ajungi la inchisoare. De aia exista bug bounties, ca sa ai dreptul sa produci exploitul. E complicata probleama, depinde de ce parere are judecatorul de tine si de ce intentii ai avut. (în scopul săvârșirii uneia dintre infracțiunile prevăzute la art. 42-45)

Ma poate ajuta cineva va rog? am incercat sa o rezolv dar este cam grea si nu prea reusesc. Cerință Se dă un șir de N numere întregi asupra căruia se fac următoarele operații: eliminarea ultimului element din șir (pop) și adăugarea unui element X la finalul șirului (push X). Să se afișeze șirul după aplicarea operațiilor date. Structura de date introdusă mai sus, asupra căreia se pot executa doar operații de tip push X și pop, se numește stivă. Stiva este o structură de date des utilizată în informatică și se spune că are tipul last in, first out datorită felului în care accesăm date salvate în ea. Aceasta este folosită atât la implementarea recursivității în limbajele de programare, cât și ca structură auxiliară la traversarea unor structuri de date mai complicate, cum sunt arborii și grafurile. Date de intrare Se citește numărul natural N, reprezentând numărul de elemente ale șirului inițial și N numere întregi, reprezentând elementele șirului. Apoi se citesc M valori de k unde k poate avea valoarea 1 sau 2. Dacă k are valoarea 1, se va citi imediat după acesta un număr întreg X şi se va efectua operaţia push X. Dacă kare valoarea 2 se va efectua operaţia pop. Date de ieșire Se va afișa pe ecran șirul de numere obținut în urma aplicării operațiilor date asupra șirului inițial. Pe prima linie se va afișa numărul T, reprezentând numărul de elemente ale noului șir, iar pe cea de a doua linie se vor afișa cele T elementele ale șirului, separate prin spații. Restricții şi precizări N și M sunt numere naturale cuprinse în intervalul [1, 10.000]. Fiecare element din șir este cuprins în intervalul [-2.000.000.000, +2.000.000.000]. k va avea întotdeauna valoarea 1 sau 2. X are valori cuprinse în intervalul [-2.000.000.000, +2.000.000.000]. Nu vor fi operatii de tipul 2 cand stiva e goala. Exemplu Date de intrare 7 5 -4 0 -7 7 7 2 5 2 1 100 2 1 0 1 3 Date de iesire 8 5 -4 0 -7 7 7 0 3

Daca vrei sa mergi in continuare pe structura pe care o ai in prezent, poti folosi regex sa-ti extragi datele si dupa sa lucrezi cu ele, spre exemplu <?php $mysql = mysqli_connect("localhost","ips","8hLXKFoFBuLld9LW","tests") or die("connection failure"); $q = $mysql->query("select val from ips"); $ips = array(); while($v = $q->fetch_row()) { preg_match('/((?:[0-9]{1,3}\.){3}[0-9]{1,3}) ([0-2]?[0-9]:[0-5]?[0-9]:[0-5]?[0-9]) ([0-2]?[0-9]\/[0-5]?[0-9]\/[0-9][0-9][0-9][0-9])/', $v[0], $matches); // scoatem prin regex IP-ul, ora si data din randul de mysql // echo $matches[1]; // IP // echo $matches[2]; // Ora // echo $matches[3]; // Data $ips[] = $matches[1]; // pusham IP-ul din randul de mysql in array-ul de IPs } print_r(array_count_values($ips)); // afisam de cate ori apare fiecare IP Cu valorile urmatoare in baza de date 127.0.0.1 13:29:05 13/08/2020 123.123.123.123 13:29:05 13/08/2020 127.0.0.1 13:29:05 13/08/2020 scriptul returneaza Array ( [127.0.0.1] => 2 [123.123.123.123] => 1 )

NOVEMBER 7, 2020 BY QW Facebook DOM Based XSS using postMessage The first bug could have allowed a malicious user to send cross-origin messages via postMessage method from facebook.com domain. The vulnerable endpoint would accept user controlled content in the request parameters and construct an object with the data supplied to be send with postMessage to opener window. Then, another bug was found and then linked with the previous, this bug was that a script was unsafely constructing and submitting a form based on the data received in messages via an Eventlistener. 1) Sending messages via postMessage from facebook.com origin The vulnerable endpoint was https://www.facebook.com/payments/redirect.php . The response of this endpoint could be controlled by many parameters. I found an interesting one which is “type”. This parameter if changed from normally “i” to “rp” it would use postMessage for communication with the opener window ( for “i” it would use window.parent.PaymentsFlows.processIFrame). Attacker controls what being sent with postMessage method. Notice that the target origin was set to our.intern.facebook.com. From this i knew that the postMessage method was there to target or only be used by Facebook employees since our.intern.facebook.com domain is only “fully” accessible to them and for no-employees, it would redirect to www.facebook.com. I tried to bypass this for future usage by accessing the same endpoint in another domain which is our.alpha.facebook.com. In case of our.alpha.facebook.com/payments/redirect.php, it would return our.alpha.facebook.com as the targetOrigin of the postMessage. In the contrary of our.intern , our.alpha would not redirect to www. Notice that our.alpha.facebook.com domain has the same content as www.facebook.com. This would allow messages to opener window to pass-through since the targetOrigin condition would be fulfilled and messages would be sent to our.alpha.facebook.com. At this point, i knew that i should exploit this by looking for pages where interesting message EventListeners exists and which would only accept facebook.com subdomains in the message origin. Only accepting Facebook domains is a big hint that the data received in the message would be used to do something serious. I found a couple of interesting ones but i’ll only mention the one that got me DOM XSS. 2) The XSS Facebook Canvas Apps are served under apps.facebook.com. If you visit an app being served there, you’ll notice that Facebook would load an URL ( previously selected by the app owner ) inside an iframe and then a POST message would be sent to this URL with parameters like “signed_request”. Tracing what originated this request, i found that the page was loading “https://www.facebook.com/platform/page_proxy/?version=X” in an iframe too and then sending messages to it with postMessage ( I later found out that this endpoint was used before by another researcher to achieve a serious bug too). The page_proxy page contained this code: page_proxy source code This code would do two things. It would send a message with frameName via postMessage to any origin (This was used by Amol but now fixed by checking the frameName). The second thing is it would setup an EventListener and wait for messages. If a message is received and all conditions are fulfilled, it would submit a form after setting its attributes based on the data inside the message. What’s interesting about the form construction (submitForm method), is that the action attribute of the form is directly set to “a.data.params.appTabUrl” which is received in the message. The URL inside “appTabUrl” string wasn’t checked if it starts with http/https, for that we can use other schemes like javascript to achieve XSS! A payload that would construct an object that would fulfill all conditions in the page_proxy script would be something like this: https://our.alpha.facebook.com/payments/redirect.php?type=rp&name=_self&params[appTabUrl]=javascript:alert(1);&params[signedRequest]=SIGNED_X&platformAppControllerGetFrameParamsResponse=1 OBJ: {“type”:”rp”,”name”:”_self”,”params”:{“appTabUrl”:”javascript:alert(1);”,”signedRequest”:”SIGNED_X”},”platformAppControllerGetFrameParamsResponse”:”1″} Exploit The victim should visit the attacker website which would have the following code. This would open another page in the attacker website and the current window would be the opener window. <html> <button class="button" onClick="window.open('https://attacker/page2.html', '_blank');document.location.href = 'https://our.alpha.facebook.com/platform/page_proxy/?version=X#_self';"> <span class="icon">Start Attack</span> </button> </html> Here we won’t redirect directly to page_proxy endpoint since we need to set a timeout to ensure that https://www.facebook.com/platform/page_proxy/ was loaded. page2.html: <html> <script> setTimeout(function(){ window.location.href = 'https://our.alpha.facebook.com/payments/redirect.php?type=rp&merchant_group=86&name=_self&params[appTabUrl]=javascript:alert(1);&params[signedRequest]=SIGNED_X&platformAppControllerGetFrameParamsResponse=1';} ,3000); </script> </html> Here we redirect to the vulnerable endpoint after the timeout. This would only execute alert(1) however the POC i sent would steal a first-party access_token which could be used to takeover the Facebook account. This was easy since we can simply read , for example, the response of an oauth flow to authorize a first-party Facebook application. Fix Facebook fixed this bug by completely removing the usage of postMessage in payments redirects ( /payments/redirect.php). Also, appTabUrl is now checked if it starts with https[ /^https:/.test(a.data.params.appTabUrl) ] Timeline Oct 10, 2020— Report Sent  Oct 10, 2020—  Acknowledged by Facebook Oct 10, 2020 — $25K in total including bonuses Awarded by Facebook (During BountyCon2020) Oct 28, 2020— Fixed by Facebook Sursa: https://ysamm.com/?p=493